This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: introduce configure --with-sysroot
On Oct 24, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
> First of all, I must say I'm impressed. All it took to get most of a
> working compilation environment was:
> drow@nevyn:/big/fsf/bib% cat ../wrap/ld
> #!/bin/sh
> exec /usr/bin/ld -rpath-link /opt/hardhat/devkit/x86/pentium2/target/lib:/opt/hardhat/devkit/x86/pentium2/target/usr/lib "$@"
We may have to add -rpath-link with %R to more targets that people are
likely to build cross toolchains for. See LIB_SPEC in
gcc/config/sh/linux.h for an example.
> We can figure out later if there's any advantage to GCC passing these
> options; probably I should just finish --with-sysroot for binutils and
> let it apply it to all absolute paths in SEARCH_DIR. That's pretty
> easy.
That works too. There's no reason to not do it in both, though.
> if [ -f /usr/include/limits.h ] ; then \
> That's using SYSTEM_HEADER_DIR, I think.
Hmm... Where is this? The only relevant reference to limits.h I see
in gcc/Makefile.in is:
LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ]
and this uses SYSTEM_HEADER_DIR, indeed.
> /bin/sh ./fixinc.sh `${PWDCMD-pwd}`/include /usr/include ; \
> The problem there should be obvious, too :)
$(SHELL) ./fixinc.sh `${PWD}`/include $(SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS); \
Also SYSTEM_HEADER_DIR, that should have been defined as
$(CROSS_SYSTEM_HEADER_DIR) by configure.in. Has it not?
SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)' AC_SUBST(SYSTEM_HEADER_DIR)
if test x$host != x$target
then
CROSS="-DCROSS_COMPILE"
ALL=all.cross
SYSTEM_HEADER_DIR='$(CROSS_SYSTEM_HEADER_DIR)'
> There were some other problems with finding the wrong headers, and
> files being built against /usr/include. I don't see how this patch is
> supposed to change the search dirs for headers. Would you mind
> enlightening me, so that I can figure out why it isn't working? :)
See above. Perhaps you had local changes in place that canceled the
effect of overriding SYSTEM_HEADER_DIR?
> [Also, in these circumstances make_relative_prefix behaves very
> oddly...
> progname=0xbffff557 "/nevyn/big/fsf/bib/gcc/xgcc"
> bin_prefix=0x80564c8 "/big/fsf/bibinst/bin/"
> prefix=0x8054560 "/opt/hardhat/devkit/x86/pentium2/target"
Hmm... I'd thought make_relative_prefix would have failed in this
case, since the prefixes are clearly unrelated. This deserves some
additional thought, indeed. Having a random pathname outside the
build tree interfere with the build process was definitely not
intended.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer