This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Build automation


> autoconf tests work poorly with a compiler that can not fully link
> executables.  autoconf relies on link failures to detect required
> functions.  When all links fail, autoconf becomes useless.

This reminds me of my experience when porting gcc and other tools to
BeOS.  Currently the only way to link BeOS executables is using the
Metrowerks linker, which is only available native on BeOS.

What I ended up doing was creating a file with just stubs for all
functions like "printf" that are normally resolved by the linker from
the BeOS runtime, compiling that into a single object module that I
substituted for crt0.o in the cross environment, and then autoconf
worked correctly with regards to detecting which functions were
available and which were not.  I did the substitution for crt0.o at
configure time via a special hack that used an environment variable.
Something like:

  $ CRT0=beos-hack.o CC=ppc-beos-gcc configure -v ...

I guess my point is that autoconf doesn't have to be able to generate
executables that are capable of being run in order for the
configuration process to be successful.  I wouldn't necessarily promote
the method I used to achieve this.

-Fred


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]