------- 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
