Tiny GCC: Pure, Unadulterated, Object Code

Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Ian Lance Taylor]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Brian Dessent]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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

Re: [Progress] Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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

Re: [Progress] Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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.

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Brian Dessent]

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

Re: [Progress] Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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

Re: [Progress] Tiny GCC: Pure, Unadulterated, Object Code

[Andrew Haley]

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.

RE: Tiny GCC: Pure, Unadulterated, Object Code

[Scott Moore]

> 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
 

Re: Tiny GCC: Pure, Unadulterated, Object Code

[John Carter]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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!

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Brian Dessent]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Brian Dessent]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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.

Re: Tiny GCC: Pure, Unadulterated, Object Code

[NightStrike]

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?

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Ian Lance Taylor]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Michael Witten]

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

Re: Tiny GCC: Pure, Unadulterated, Object Code

[Ian Lance Taylor]

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