[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

["gschafer at zip dot com dot au" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #5 from gschafer at zip dot com dot au  2008-03-12 11:26 -------
(In reply to comment #4)
> 
> The example you describe looks an awful lot like a cross-compile.

No, it's definitely native. See below.

> Is there
> anything preventing you from configuring with --enable-build-sysroot=/tmp/foo?

Sysroot options are only for cross-compiles. GCC docs are quite clear on this.
I tried it anyway and no, it doesn't help.

> Could you also describe your original build process in detail?

The build process is the same old process that has been is use for years at
http://www.linuxfromscratch.org/ and my project at http://www.diy-linux.org/
It's a *native* build process for a reason. Carlos, what you must keep in mind
is that these build procedures are aimed at relatively mere mortals and not
toolchain gurus like yourself. The goal is to natively bootstrap a complete
Linux system from source and the basic theory of operation is summarized here:

http://www.diy-linux.org/reference-build/introduction.html#buildmethod

Because the first phase is installed into a non-standard prefix, say
/temptools, the --prefix plays a pivotal role in the process. Up until 4.3, GCC
has always (mostly) respected $prefix. I say "mostly" because a few tweaks are
required for the native toolchain to function correctly when installed in
/temptools, including some hacks to prevent the toolchain from searching the
host. With your patch, GCC no longer treats $prefix like it used to. But it's
only during the GCC_FOR_TARGET stage of the GCC build. Once GCC is installed
into /temptools, everything works fine! But your patch breaks the assumption
about $prefix that these procedures have relied upon for years. In particular,
building a 64-bit system from a 32-bit host breaks horribly (ie: build a
cross-toolchain, cross-compile Glibc, cross-compile a 64-bit kernel, reboot
into it, carry on as 64-bit native).

> Please don't think of this as an issue between a relocated or un-relocated
> compiler.

But it clearly *is*, I don't understand how you can say this. gcc_exec_prefix
is key AFAICT,

> By building gcc you become a gcc developer, not a user,

Sorry, but that's nonsense.

> and there is no guarantee that the gcc build
> process will not change over time.

Of course. But may I draw your attention to this snippet from the GCC
installation docs:

"GCC automatically searches for ordinary libraries using GCC_EXEC_PREFIX. Thus,
when the same installation prefix is used for both GCC and packages, GCC will
automatically search for both headers and libraries. This provides a
configuration that is easy to use. GCC behaves in a manner similar to that when
it is installed as a system compiler in /usr."

The above now seems at odds with GCC's current behaviour.

Anyhow, if you can help me work around the problem and/or come up with a better
build procedure for the "mere mortals" target audience, I'd appreciate it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532