* Tiny GCC: Pure, Unadulterated, Object Code @ 2008-01-24 12:21 Michael Witten 2008-01-24 14:29 ` Ian Lance Taylor ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Michael Witten @ 2008-01-24 12:21 UTC (permalink / raw) To: gcc-help Dear GCC developers, I would like to use distcc in a compile-farm comprised of various and sundry computing architectures. Consequently, I need cross-compilers on many of these machines. Consider first how distcc works (as described by (http://en.wikipedia.org/wiki/Distcc): distcc works as an agent for the compiler. A distcc daemon has to run on each of the participating mach- ines. The originating machine invokes a preprocessor to handle header files, preprocessing directives (such as #ifdef) and the source files and sends the preprocessed source to other machines over the net- work via TCP either unencrypted or using SSH. Remote machines compile those source files without any local dependencies (such as libraries, header files or macro definitions) to object files and send them back to the originator for further compilation. That "further compilation" really just means linking. Therefore, the gcc cross-compilers I want to build need only produce object code in the correct format using already pre- processed code. That means: These cross-compilers don't need access to any kind of libraries or headers. They don't need C libraries, or libstdc++, or libobjc, or anything that has absolutely nothing to do whatsoever with compilation. Can I build gcc in this way? I've been trying for quite some time now to achieve such a stripped down gcc, but it would seem that the gcc build process insists on building these libraries, which I think is wholly unnecessary. I would like to ask further that if my understandings are incorrect, could somebody please disabuse me. Sincerely, Michael Witten ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-24 12:21 Tiny GCC: Pure, Unadulterated, Object Code Michael Witten @ 2008-01-24 14:29 ` Ian Lance Taylor 2008-01-25 4:23 ` Brian Dessent 2008-01-29 14:22 ` John Carter 2 siblings, 0 replies; 22+ messages in thread From: Ian Lance Taylor @ 2008-01-24 14:29 UTC (permalink / raw) To: Michael Witten; +Cc: gcc-help Michael Witten <mfwitten@MIT.EDU> writes: > Therefore, the gcc cross-compilers I want to build need only > produce object code in the correct format using already pre- > processed code. That means: > > These cross-compilers don't need access to any kind of > libraries or headers. > > They don't need C libraries, or libstdc++, or libobjc, > or anything that has absolutely nothing to do whatsoever > with compilation. > > > Can I build gcc in this way? Sure, but you'll have to hack at it manually. There is no supported configure option for this, or anything like that. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-24 12:21 Tiny GCC: Pure, Unadulterated, Object Code Michael Witten 2008-01-24 14:29 ` Ian Lance Taylor @ 2008-01-25 4:23 ` Brian Dessent 2008-01-26 2:47 ` Michael Witten 2008-01-29 14:22 ` John Carter 2 siblings, 1 reply; 22+ messages in thread From: Brian Dessent @ 2008-01-25 4:23 UTC (permalink / raw) To: Michael Witten; +Cc: gcc-help Michael Witten wrote: > Can I build gcc in this way? > > I've been trying for quite some time now to achieve such a > stripped down gcc, but it would seem that the gcc build > process insists on building these libraries, which I think > is wholly unnecessary. You might be able to approximate this by "make all-gcc" and then "make install-gcc" (or just manually copying the xgcc to the destination.) Brian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-25 4:23 ` Brian Dessent @ 2008-01-26 2:47 ` Michael Witten 2008-01-26 16:17 ` [Progress] " Michael Witten 2008-01-27 8:45 ` Brian Dessent 0 siblings, 2 replies; 22+ messages in thread From: Michael Witten @ 2008-01-26 2:47 UTC (permalink / raw) To: Brian Dessent; +Cc: gcc-help On 24 Jan 2008, at 7:20 AM, Brian Dessent wrote: > Michael Witten wrote: > >> Can I build gcc in this way? >> >> I've been trying for quite some time now to achieve such a >> stripped down gcc, but it would seem that the gcc build >> process insists on building these libraries, which I think >> is wholly unnecessary. > > You might be able to approximate this by "make all-gcc" and then "make > install-gcc" (or just manually copying the xgcc to the destination.) I'm a little uncomfortable just taking the xgcc that's left over when the build fails. In any case, it would seem I can't even build a so called 'naked' C compiler, as would be desired for (hobbyist) kernel building, without having the presence of some kind of library like newlib (I recall that such library interferences wasn't always a problem). I still don't understand why gcc imposes these libraries, when they have nothing to do with compilation. It just seems like bad design. Perhaps it is just the monolithic, rigid, inadequate build process that covers up a more elegant design. Then again, I'm not really well versed in these things, so please correct me if my understanding is wanting. Michael Witten ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Progress] Tiny GCC: Pure, Unadulterated, Object Code 2008-01-26 2:47 ` Michael Witten @ 2008-01-26 16:17 ` Michael Witten 2008-01-26 22:16 ` Michael Witten 2008-01-27 13:07 ` Michael Witten 2008-01-27 8:45 ` Brian Dessent 1 sibling, 2 replies; 22+ messages in thread From: Michael Witten @ 2008-01-26 16:17 UTC (permalink / raw) To: Brian Dessent; +Cc: gcc-help On 25 Jan 2008, at 8:16 AM, Michael Witten wrote: > On 24 Jan 2008, at 7:20 AM, Brian Dessent wrote: > >> Michael Witten wrote: >> >>> Can I build gcc in this way? >>> >>> I've been trying for quite some time now to achieve such a >>> stripped down gcc, but it would seem that the gcc build >>> process insists on building these libraries, which I think >>> is wholly unnecessary. >> >> You might be able to approximate this by "make all-gcc" and then >> "make >> install-gcc" (or just manually copying the xgcc to the destination.) > > I'm a little uncomfortable just taking the xgcc that's left over when > the build fails. I apologize. For some reason, when I tried make all-gcc the build failed. After getting a good night's rest and starting afresh, I was able to build a 'naked' gcc using --without-headers, a non-linux target, and your above suggestion. That being said, part of the problem is that the build process is neither well-documented nor intuitive--at least to me. While I would love to contribute by improving this factor of gcc, I would rather encourage somebody, who has an intimate familiarity with the project, to take the time over a couple of weekends to clarify the nuances and produce step-by-step (shell) instructions for not only common tasks, but also the uncommon tasks; there's no reason that this information should be hosted by other websites: http://www.osdev.org/wiki/GCC_Cross-Compiler That kind of documentation could go a long way in encouraging new developers to get involved, because it would allow them to avoid a first impression wrought with frustration. Sincerely, Michael Witten ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Progress] Tiny GCC: Pure, Unadulterated, Object Code 2008-01-26 16:17 ` [Progress] " Michael Witten @ 2008-01-26 22:16 ` Michael Witten 2008-01-28 0:46 ` Andrew Haley 2008-01-27 13:07 ` Michael Witten 1 sibling, 1 reply; 22+ messages in thread From: Michael Witten @ 2008-01-26 22:16 UTC (permalink / raw) To: gcc-help On 25 Jan 2008, at 6:11 PM, Michael Witten wrote: > That kind of documentation could go a long way in encouraging new > developers to get involved, because it would allow them to avoid > a first impression wrought with frustration. I just stumbled across this website, which looks quite inviting: http://kernelnewbies.org Something as abstruse and magical as gcc could benefit from a similar initiative. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Progress] Tiny GCC: Pure, Unadulterated, Object Code 2008-01-26 22:16 ` Michael Witten @ 2008-01-28 0:46 ` Andrew Haley 0 siblings, 0 replies; 22+ messages in thread From: Andrew Haley @ 2008-01-28 0:46 UTC (permalink / raw) To: Michael Witten; +Cc: gcc-help Michael Witten wrote: > > On 25 Jan 2008, at 6:11 PM, Michael Witten wrote: > >> That kind of documentation could go a long way in encouraging new >> developers to get involved, because it would allow them to avoid >> a first impression wrought with frustration. > > I just stumbled across this website, which looks quite inviting: > http://kernelnewbies.org > > Something as abstruse and magical as gcc could benefit from > a similar initiative. What's to stop people who want to do this from writing to the gcc Wiki instead? http://gcc.gnu.org/wiki/HomePage Andrew. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Progress] Tiny GCC: Pure, Unadulterated, Object Code 2008-01-26 16:17 ` [Progress] " Michael Witten 2008-01-26 22:16 ` Michael Witten @ 2008-01-27 13:07 ` Michael Witten 1 sibling, 0 replies; 22+ messages in thread From: Michael Witten @ 2008-01-27 13:07 UTC (permalink / raw) To: gcc-help, gcc; +Cc: Brian Dessent On 25 Jan 2008, at 6:11 PM, Michael Witten wrote: > On 25 Jan 2008, at 8:16 AM, Michael Witten wrote: > >> On 24 Jan 2008, at 7:20 AM, Brian Dessent wrote: >> >>> Michael Witten wrote: >>> >>>> Can I build gcc in this way? >>>> >>>> I've been trying for quite some time now to achieve such a >>>> stripped down gcc, but it would seem that the gcc build >>>> process insists on building these libraries, which I think >>>> is wholly unnecessary. >>> >>> You might be able to approximate this by "make all-gcc" and then >>> "make >>> install-gcc" (or just manually copying the xgcc to the destination.) >> >> I'm a little uncomfortable just taking the xgcc that's left over when >> the build fails. > > I apologize. > > > For some reason, when I tried > > make all-gcc > > the build failed. Aha! Apparently the build DOES FAIL when building on Mac OS X 10.5 (darwin 9.1.0) for the PowerPC (there is no problem with the x86 version): cc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno- variadic-macros -Wold-style-definition -Wmissing-format-attribute - DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/ gcc/../include -I../../src/gcc/../libcpp/include -I. -I. -I../../ src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/ gcc/../libcpp/include ../../src/gcc/config/rs6000/host-darwin.c -o host-ppc-darwin.o ../../src/gcc/config/rs6000/host-darwin.c:38: warning: ‘struct sigaltstack’ declared inside parameter list ../../src/gcc/config/rs6000/host-darwin.c:38: warning: its scope is only this definition or declaration, which is probably not what you want ../../src/gcc/config/rs6000/host-darwin.c:38: error: conflicting types for ‘sigaltstack’ /usr/include/signal.h:89: error: previous declaration of ‘sigaltstack’ was here ../../src/gcc/config/rs6000/host-darwin.c: In function ‘segv_handler’: ../../src/gcc/config/rs6000/host-darwin.c:71: error: ‘struct __darwin_mcontext’ has no member named ‘ss’ ../../src/gcc/config/rs6000/host-darwin.c:120: error: ‘struct __darwin_mcontext’ has no member named ‘es’ ../../src/gcc/config/rs6000/host-darwin.c:120: error: ‘struct __darwin_mcontext’ has no member named ‘ss’ ../../src/gcc/config/rs6000/host-darwin.c: In function ‘darwin_rs6000_extra_signals’: ../../src/gcc/config/rs6000/host-darwin.c:134: warning: passing argument 1 of ‘sigaltstack’ from incompatible pointer type make[1]: *** [host-ppc-darwin.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all-gcc] Error 2 It can be compiled thusly: MACOSX_DEPLOYMENT_TARGET=10.4 make all-gcc ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-26 2:47 ` Michael Witten 2008-01-26 16:17 ` [Progress] " Michael Witten @ 2008-01-27 8:45 ` Brian Dessent 2008-01-29 1:36 ` Scott Moore 2008-01-29 15:55 ` Michael Witten 1 sibling, 2 replies; 22+ messages in thread From: Brian Dessent @ 2008-01-27 8:45 UTC (permalink / raw) To: Michael Witten; +Cc: gcc-help Michael Witten wrote: > I still don't understand why gcc imposes these libraries, when they > have nothing to do with compilation. It just seems like bad design. You can't divorce a compiler from the target. The target's ABI specifies a great number of details that are very much relevant to the compiler, such as: - calling conventions - how assembler names are decorated - size of pointers - how SIMD and floating registers are passed and saved/restored - alignment of the stack - struct and bitfield padding - register used for PIC and how PIC code is generated - how TLS variables are created and accessed - method for unwinding the stack for exception handling - accessing shared variables and calling into shared libraries - etc. As an example I present Linux (ELF) and Windows (PE). These both run on identical ia32 and x64 hardware. But they could not be more different in a number of the above. For example ELF uses PLT/GOT for indirection for shared libraries, PE uses dllimport/dllexport. ELF requires PIC for shared libraries, PE does not have a real notion of PIC. Linux x86_64 is lp64 whereas Windows x64 is p64 (long is 32 bit.) Windows uses SEH for EH, Linux uses DWARF2 for EH. The differences continue on and on. These two compilers are nothing alike, though the target the identical hardware. So you can't just make some kind of generic "386" gcc and expect it to have any kind of useful ability, unless you are only ever doing to compile 100% freestanding code like a kernel or a OS-less bare metal system. Otherwise it must be targeted to a specific platform, i.e. i386-pc-linux or i386-pc-mingw. Brian ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-27 8:45 ` Brian Dessent @ 2008-01-29 1:36 ` Scott Moore 2008-01-29 15:55 ` Michael Witten 1 sibling, 0 replies; 22+ messages in thread From: Scott Moore @ 2008-01-29 1:36 UTC (permalink / raw) To: gcc-help, Michael Witten > You can't divorce a compiler from the target. The target's ABI specifies a great number of details that are > very >much relevant to the compiler, such as: > ... > So you can't just make some kind of generic "386" gcc and expect it to have any kind of useful ability, unless > you are only ever doing to compile 100% freestanding code like a kernel or a OS-less bare metal system. > Otherwise it must be targeted to a specific platform, i.e. > i386-pc-linux or i386-pc-mingw. > Brian Just a nit, this is true of GCC certainly, but not compilers in general. It is in fact quite possible and compilers exist that target x386 in general. In fact, I don't think it makes a lot of sense in many cases to build the calling convention of the operating system into the compiler. For example, the Windows calling convention for system calls is a very inefficient calling convention for general use, because it comes from the days that Microsoft C didn't perform register passed parameters. Microsoft themselves don't use the convention for calls between routines, the system calls must be marked and coded separately. Both GCC and Microsoft C build both passing conventions into the compiler, but there is no particular reason the system calls cannot be done by a thunk layer, and in fact there are x386 compilers that work that way. Scott Moore --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-27 8:45 ` Brian Dessent 2008-01-29 1:36 ` Scott Moore @ 2008-01-29 15:55 ` Michael Witten 2008-01-29 16:56 ` Brian Dessent 1 sibling, 1 reply; 22+ messages in thread From: Michael Witten @ 2008-01-29 15:55 UTC (permalink / raw) To: Brian Dessent; +Cc: gcc-help On 25 Jan 2008, at 11:48 PM, Brian Dessent wrote: > Michael Witten wrote: > >> I still don't understand why gcc imposes these libraries, when they >> have nothing to do with compilation. It just seems like bad design. > > You can't divorce a compiler from the target. The target's ABI > specifies a great number of details that are very much relevant to the > compiler, such as: > > - calling conventions > - how assembler names are decorated > - size of pointers > - how SIMD and floating registers are passed and saved/restored > - alignment of the stack > - struct and bitfield padding > - register used for PIC and how PIC code is generated > - how TLS variables are created and accessed > - method for unwinding the stack for exception handling > - accessing shared variables and calling into shared libraries > - etc. > > As an example I present Linux (ELF) and Windows (PE). These both > run on > identical ia32 and x64 hardware. But they could not be more different > in a number of the above. What you describe is not related to compilation to an intermediate language, which is all distcc really requires. However, you seem to have an impressive breadth of knowledge--one that I'd like to have! ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-29 15:55 ` Michael Witten @ 2008-01-29 16:56 ` Brian Dessent 2008-01-29 18:16 ` Michael Witten 0 siblings, 1 reply; 22+ messages in thread From: Brian Dessent @ 2008-01-29 16:56 UTC (permalink / raw) To: Michael Witten; +Cc: gcc-help Michael Witten wrote: > What you describe is not related to compilation to an intermediate > language, which is all distcc really requires. It still very much matters, because the intermediate language depends on all those aspects of the target ABI. (And even then, the IL is not what gcc writes out; it's the generated assembly.) They are fundamental to how the code is parsed, optimized, and generated. A linux targeted gcc would have no idea how to even parse __declspec((dllimport)) just as the PE gcc would not be able to make any sense of __attribute__((visibility, "hidden")). They would simply choke and die because the code to handle those features just wasn't physically compiled in. And that is only one blatant example, but all of those things on that list directly affect code generation in a way that cannot be ignored. Even the basic assembler directives for ELF and PE are different. There is just no way to make a "generic i386 gcc". Brian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-29 16:56 ` Brian Dessent @ 2008-01-29 18:16 ` Michael Witten 2008-01-29 18:36 ` Brian Dessent ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Michael Witten @ 2008-01-29 18:16 UTC (permalink / raw) To: gcc-help On 29 Jan 2008, at 12:05 AM, Brian Dessent wrote: > Michael Witten wrote: > >> What you describe is not related to compilation to an intermediate >> language, which is all distcc really requires. > > It still very much matters, because the intermediate language > depends on > all those aspects of the target ABI. (And even then, the IL is not > what > gcc writes out; it's the generated assembly.) That's true for GCC; however, I think everybody agrees GCC is FUBAR. That being stated, I want to stress that I was replying in theory (as much as I can), as your original posting strayed from the particular case of GCC to the general. > They are fundamental to how the code is parsed, optimized, and > generated. > A linux targeted gcc would have no idea how to even parse > __declspec((dllimport)) > just as the PE gcc would not be able to make any sense of > __attribute__((visibility, > "hidden")). They would simply choke and die because the code to > handle those > features just wasn't physically compiled in. Indeed! This is because GCC doesn't do the right thing. It does something very stupid by translating the code directly into a mishmash of low- and high-level, platform specific, object code. Moreover, it emits this cruft that it expects to find in libraries. It all reeks of a hackish and just-get-it-done mentality. I haven't looked too much into it, but the guys at LLVM seem to know what they're about. No doubt, many GCC developers are super knowledgeable, but they're left with this kludge to maintain. I encourage developers here to jump ship and start furthering LLVM instead (though, there is little doubt Apple will force you to work on LLVM eventually: http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html (I have not read the thread, so excuse me if I'm talking out of my arse). > And that is only one blatant example, > but all of those things on that list directly affect code generation > in a way that > cannot be ignored. Yes, they affect final code generation. The GCC isn't fine grained enough. Hell, the configuration process isn't fine grained enough! > Even the basic assembler directives for ELF and PE are different. Obviously then, these two should not be considered the same thing. This betrays an inadequate design in GCC's compilation process. > There is just no way to make a "generic i386 gcc". Sure there is: Pure binary. What you mean to say: There's just no way to make one final meta- binary (object code); however, I'm sure a more generic meta-binary level above ELF and PE could be used. Nevertheless, gcc can be instructed to stop before linking. This is what distcc has it do. Therefore, GCC should be configurable not to produce any libraries when it is built, because they will never be used. In fact, I was able to make a libc- less gcc (C/C++) that works great with distcc; even though no linking ever occurs on the servers, libgcc was still built for every cross-compiler. In fact, with any --target involving 'linux', the gcc build process REQUIRES a libc, because it tries unnecessarily to obviate what would become link time incompatibilities; in order to use distcc, I had to build gcc with --target=i686-elf but mangle the name to i686-pc-linux-gnu, which should be wholly unnecessary. These --target names should really just be convention. Sincerely, Michael Witten ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-29 18:16 ` Michael Witten @ 2008-01-29 18:36 ` Brian Dessent 2008-01-29 20:31 ` Michael Witten 2008-01-30 1:14 ` NightStrike 2008-01-30 10:20 ` Ian Lance Taylor 2 siblings, 1 reply; 22+ messages in thread From: Brian Dessent @ 2008-01-29 18:36 UTC (permalink / raw) To: Michael Witten; +Cc: gcc-help Michael Witten wrote: > > They are fundamental to how the code is parsed, optimized, and > > generated. > > A linux targeted gcc would have no idea how to even parse > > __declspec((dllimport)) > > just as the PE gcc would not be able to make any sense of > > __attribute__((visibility, > > "hidden")). They would simply choke and die because the code to > > handle those > > features just wasn't physically compiled in. > > Indeed! This is because GCC doesn't do the right thing. It does > something very stupid by > translating the code directly into a mishmash of low- and high-level, > platform specific, > object code. But it doesn't matter! Say that gcc could understand all of ELF and PE semantics in one binary. You would still require a switch to tell it which personality to use to interpret the code. And this switch would be mandatory for every compilation, because otherwise it would have no idea what you want. So how is invoking "gcc -mtarget=linux" any different than just invoking "i686-pc-linux-gcc"? It's not. You haven't solved anything or changed anything. In fact I can do this with no changes to gcc at all, just write a gcc shell wrapper script that if it sees -mtarget=linux it invokes i686-pc-linux-gcc, if it sees -mtarget=mingw it invokes i686-pc-mingw32-gcc, if it sees -mtarget=freebsd5 it invokes i686-pc-freebsd5-gcc, and so on. Whether you have them as separate binaries or all in one, it *still* *doesn't* *matter*. The details of the target cannot just be abstracted away into something that you can ignore, they are vital to the context in which the code executes. They matter at every point of the process, from the highest level on down to the very lowest level. Brian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-29 18:36 ` Brian Dessent @ 2008-01-29 20:31 ` Michael Witten 0 siblings, 0 replies; 22+ messages in thread From: Michael Witten @ 2008-01-29 20:31 UTC (permalink / raw) To: gcc-help On 29 Jan 2008, at 1:54 AM, Brian Dessent wrote: > Whether > you have them as separate binaries or all in one, it *still* *doesn't* > *matter*. The details of the target cannot just be abstracted away > into > something that you can ignore, they are vital to the context in which > the code executes. They matter at every point of the process, from > the > highest level on down to the very lowest level. My main point was not the naming scheme or the distribution of binaries. As you stated before, often these radically different meta-binaries are are targeting the same interpreter, namely the hardware. Consequently, the evaluations and optimizations throughout the compilation process should be the same. The only difference is in how they are packaged, namely which meta-binary is used. That's what seems natural to me. Then again, I must admit that I cannot take you full on in battle, for I have a limited understanding of the subject; I'll take your word that there are some real reasons why GCC has been developed the way it has, but I'll point to things like LLVM, JITs, Java, and .Net that seem to follow the conceptual basis I propose. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-29 18:16 ` Michael Witten 2008-01-29 18:36 ` Brian Dessent @ 2008-01-30 1:14 ` NightStrike 2008-01-30 7:09 ` Michael Witten 2008-01-30 10:20 ` Ian Lance Taylor 2 siblings, 1 reply; 22+ messages in thread From: NightStrike @ 2008-01-30 1:14 UTC (permalink / raw) To: Michael Witten; +Cc: gcc-help On 1/29/08, Michael Witten <mfwitten@mit.edu> wrote: > enough. Hell, the > configuration process isn't fine grained enough! You've mentioned on several occassions recently that the gcc build process is lacking, even moreso when handling cross compilers. Do you have any proposals for a better build system? ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-30 1:14 ` NightStrike @ 2008-01-30 7:09 ` Michael Witten 0 siblings, 0 replies; 22+ messages in thread From: Michael Witten @ 2008-01-30 7:09 UTC (permalink / raw) To: NightStrike; +Cc: gcc-help On 29 Jan 2008, at 9:22 AM, NightStrike wrote: > On 1/29/08, Michael Witten <mfwitten@mit.edu> wrote: >> enough. Hell, the >> configuration process isn't fine grained enough! > > > You've mentioned on several occassions recently that the gcc build > process is lacking, even moreso when handling cross compilers. Do you > have any proposals for a better build system? Unfortunately, I have nothing concrete to offer, not only because I haven't put a great deal of thought into a better system, but also because I believe the problems are more systemic. In particular, the entire GCC project seems to be founded upon an unnecessary number of assumptions about its environments and its purposes, and the build process reflects the resulting rigidity and inconsistencies. Indeed, the GCC is the GNU Compiler Collection; it is a conglomerate, and the build process should reflect this fact by exposing as much configurability between the parts as possible, while more mainstream configurations could be set with a single switch. Michael Witten ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-29 18:16 ` Michael Witten 2008-01-29 18:36 ` Brian Dessent 2008-01-30 1:14 ` NightStrike @ 2008-01-30 10:20 ` Ian Lance Taylor 2008-01-30 10:54 ` Michael Witten 2 siblings, 1 reply; 22+ messages in thread From: Ian Lance Taylor @ 2008-01-30 10:20 UTC (permalink / raw) To: Michael Witten; +Cc: gcc-help Michael Witten <mfwitten@MIT.EDU> writes: > > There is just no way to make a "generic i386 gcc". > > Sure there is: Pure binary. That makes no sense in the context you are discussing. There is no pure binary which will run on both a GNU/Linux system and a Windows system. Even on a bare embedded board, which is very different from a GNU/Linux or Windows system, different devices must be handled in different ways. I think you need to understand why this makes no sense before you can proceed to understanding why the rest of your posting makes no sense. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-30 10:20 ` Ian Lance Taylor @ 2008-01-30 10:54 ` Michael Witten 2008-01-30 12:09 ` Ian Lance Taylor 0 siblings, 1 reply; 22+ messages in thread From: Michael Witten @ 2008-01-30 10:54 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: gcc-help On 29 Jan 2008, at 10:54 AM, Ian Lance Taylor wrote: > Michael Witten <mfwitten@MIT.EDU> writes: > >>> There is just no way to make a "generic i386 gcc". >> >> Sure there is: Pure binary. > > That makes no sense in the context you are discussing. There is no > pure binary which will run on both a GNU/Linux system and a Windows > system. Even on a bare embedded board, which is very different from a > GNU/Linux or Windows system, different devices must be handled in > different ways. That was more of a jest. Why not take that quote in context: >> There is just no way to make a "generic i386 gcc". > > Sure there is: Pure binary. > > What you mean to say: There's just no way to make one final meta- > binary (object code); > however, I'm sure a more generic meta-binary level above ELF and PE > could be used > [before translation to either]. So yes, it did make sense in the context I am discussing. > I think you need to understand why this makes no sense before you can > proceed to understanding why the rest of your posting makes no sense. I think you need to understand all of one's posting before you proceed to reply. That being stated, I have consistently admitted that I have a limited knowledge. Furthermore, I would like to add that no reply I have received thus far has contributed to improving said knowledge. Sincerely, Michael Witten ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-30 10:54 ` Michael Witten @ 2008-01-30 12:09 ` Ian Lance Taylor 0 siblings, 0 replies; 22+ messages in thread From: Ian Lance Taylor @ 2008-01-30 12:09 UTC (permalink / raw) To: Michael Witten; +Cc: gcc-help Michael Witten <mfwitten@MIT.EDU> writes: > >> There is just no way to make a "generic i386 gcc". > > > > Sure there is: Pure binary. > > > > What you mean to say: There's just no way to make one final meta- > > binary (object code); > > however, I'm sure a more generic meta-binary level above ELF and PE > > could be used > > [before translation to either]. > > So yes, it did make sense in the context I am discussing. That statement--the one about the generic meta-binary--is also incorrect. This is sometimes known as the "UNCOL trap." However, I apologize for taking your statement too much out of context. > That being stated, I have consistently admitted that I have a limited > knowledge. Furthermore, I would like to add that no reply I have > received > thus far has contributed to improving said knowledge. As far as I can see, you are disregarding the answers to your questions because they do not take the form of the answer you desire. Reality is not what you want it to be. However, if you ask again, without the comments about how awful gcc is, I will endeavor to give you a serious answer. Ian ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-24 12:21 Tiny GCC: Pure, Unadulterated, Object Code Michael Witten 2008-01-24 14:29 ` Ian Lance Taylor 2008-01-25 4:23 ` Brian Dessent @ 2008-01-29 14:22 ` John Carter 2008-01-29 15:40 ` Michael Witten 2 siblings, 1 reply; 22+ messages in thread From: John Carter @ 2008-01-29 14:22 UTC (permalink / raw) To: Michael Witten; +Cc: gcc-help On Wed, 23 Jan 2008, Michael Witten wrote: > These cross-compilers don't need access to any kind of > libraries or headers. > > They don't need C libraries, or libstdc++, or libobjc, > or anything that has absolutely nothing to do whatsoever > with compilation. > > > Can I build gcc in this way? Build gcc with the libc that goes into the target. Compile your code with one or more of..... `-nostartfiles' Do not use the standard system startup files when linking. The standard system libraries are used normally, unless `-nostdlib' or `-nodefaultlibs' is used. `-nodefaultlibs' Do not use the standard system libraries when linking. Only the libraries you specify will be passed to the linker. The standard startup files are used normally, unless `-nostartfiles' is used. The compiler may generate calls to `memcmp', `memset', `memcpy' and `memmove'. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified. `-nostdlib' Do not use the standard system startup files or libraries when linking. No startup files and only the libraries you specify will be passed to the linker. The compiler may generate calls to `memcmp', `memset', `memcpy' and `memmove'. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified. One of the standard libraries bypassed by `-nostdlib' and `-nodefaultlibs' is `libgcc.a', a library of internal subroutines that GCC uses to overcome shortcomings of particular machines, or special needs for some languages. (*Note Interfacing to GCC Output: (gccint)Interface, for more discussion of `libgcc.a'.) In most cases, you need `libgcc.a' even when you want to avoid other standard libraries. In other words, when you specify `-nostdlib' or `-nodefaultlibs' you should usually specify `-lgcc' as well. This ensures that you have no unresolved references to internal GCC library subroutines. (For example, `__main', used to ensure C++ constructors will be called; *note `collect2': (gccint)Collect2.) John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@tait.co.nz New Zealand ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Tiny GCC: Pure, Unadulterated, Object Code 2008-01-29 14:22 ` John Carter @ 2008-01-29 15:40 ` Michael Witten 0 siblings, 0 replies; 22+ messages in thread From: Michael Witten @ 2008-01-29 15:40 UTC (permalink / raw) To: John Carter; +Cc: gcc-help On 28 Jan 2008, at 8:36 PM, John Carter wrote: > Build gcc with the libc that goes into the target. Thanks for the idea, but I was able to bypass libc; I was going to email the list with my solution as soon as I ironed out some kind of incompatibility I'm getting in object code between C++ compilers (of the same version). Though I haven't figured it out, this is the simple solution derived from http://www.osdev.org/wiki/GCC_Cross-Compiler tar xjf binutils-2.17.tar.bz2 mv binutils-2.17 src mkdir build cd build export PREFIX=/usr/local/xgcc export TARGET=i686-elf ../src/configure --target=$TARGET --prefix=$PREFIX --disable-nls make sudo make install -------------------------------- tar xjf gcc-core-4.1.2.tar.bz2 && tar xjf gcc-g++-4.1.2.tar.bz2 mv gcc-4.1.2 src mkdir build cd build export PATH=$PATH:$PREFIX/bin ../src/configure --target=$TARGET --prefix=$PREFIX --disable-nls -- enable-languages=c,c++ --without-headers MACOSX_DEPLOYMENT_TARGET=10.4 make all-gcc sudo make install-gcc That MACOSX_DEPLOYMENT_TARGET=10.4 is necessary on Mac OS X 10.5 In any case, I wish that the configuration process/switches were cleaned up and documented more. Sincerely, Michael Witten ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2008-01-29 18:16 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-01-24 12:21 Tiny GCC: Pure, Unadulterated, Object Code Michael Witten 2008-01-24 14:29 ` Ian Lance Taylor 2008-01-25 4:23 ` Brian Dessent 2008-01-26 2:47 ` Michael Witten 2008-01-26 16:17 ` [Progress] " Michael Witten 2008-01-26 22:16 ` Michael Witten 2008-01-28 0:46 ` Andrew Haley 2008-01-27 13:07 ` Michael Witten 2008-01-27 8:45 ` Brian Dessent 2008-01-29 1:36 ` Scott Moore 2008-01-29 15:55 ` Michael Witten 2008-01-29 16:56 ` Brian Dessent 2008-01-29 18:16 ` Michael Witten 2008-01-29 18:36 ` Brian Dessent 2008-01-29 20:31 ` Michael Witten 2008-01-30 1:14 ` NightStrike 2008-01-30 7:09 ` Michael Witten 2008-01-30 10:20 ` Ian Lance Taylor 2008-01-30 10:54 ` Michael Witten 2008-01-30 12:09 ` Ian Lance Taylor 2008-01-29 14:22 ` John Carter 2008-01-29 15:40 ` Michael Witten
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).