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
