Greg Schafer wrote: > Ryan Oliver wrote: > > >> We all know what sysroot is for. >> >> All sysroot does is shift the search paths underneath the sysroot, no >> more, no less. >> > > Well, yes. But Sysroot is specifically for *root* file systems. Here's > another data point from the GCC man/info/web docs: >
> "--sysroot=dir > *Use dir as the logical root directory for headers and libraries*. _For_ > _example_, *if* the compiler would *normally* search for headers in > /usr/include and libraries in /usr/lib, it will instead search > dir/usr/include and dir/usr/lib*" > <Emphasis is mine>. Don't mix up explanation with example. This merely re-enforces the point I made above. > You're using sysroot on a non-root file system. You obviously don't understand the meaning of _logical root directory_. FHS standard under the _logical root directory_ is not implied. > Which is why you are > forced to hack the source to make it search only the dirs that you want. > > Exactly as was done for plfs, lfs and DIY. Hell, you are already hacking *_THE EXACT SAME MACROS_*. > I repeat - You're abusing the sysroot feature and setting a poor example. > > Repeating a statement does not make it true. I am using the sysroot feature for a target system root. I am then overriding the standard macros for specifying where to search for includes and startfiles, which is a completely separate thing. ... And here I thought changing the documented macros for default include and library search path handling instead of using an undocumented (if you dont count the source) spec and CROSS_INCLUDE_DIR would stop the FUD storm. Methinks the difference between "l337 super new mega clfs-killing second-coming toolchain build method !!!11!!1!" and "GAH OH NOES gcc source edits, sysroot misuse, FUD FUD unsubstantiated FUD" is merely that the author was not Greg Schafer. I put this build together *solely to prove a point* after attempting to give *you* some subtle guides on how *you* could improve *your* build. http://linuxfromscratch.org/pipermail/lfs-dev/2008-December/062469.html and your response http://linuxfromscratch.org/pipermail/lfs-dev/2008-December/062472.html Hell, I even "fixed" up your "-B binary search path doesn't use multilibs" problem for you. I've offered to even "fix" up the "broken gcc -specs switch handling "bug"" for you (even easier "fix" than the -B multilib handling). It is astounding that you have for so long been complaining about multilib -B handling (it is unnecessary and is quite frankly wrong) and that "startfile specs are broken because I can't override them from a custom specs file in a non standard directory" and not bothered to read and *understand* the code you are dealing with (ie: the real documentation) and not once come up with *any* "fix". Then through selective quotes from the written documentation (which has not kept up with the code and is in several places quite frankly wrong) with misplaced emphasis attempt to disingenuously silence and/or bamboozle your critics/audience without any substantive *technical* arguments. You even blustered through the *--prefix is king* argument when you require your own hack to gcc.c itself to actually make --prefix do what you assumed it was doing. (I must say a far more heinous hack than anything I have done. I adjust macros (thats what they are there for or they wouldn't be macros, they would be hard coded strings). you blindly hacked a needless patch adding unneeded functionality upstream explicitly removed). You have had 4 years of clfs to look at and yet did not in that time manage to understand anything enough to come up with the obvious response considering all the FUD you espoused, or even a reasonably working toolchain for yourself. Why the hell should anyone take any credence in what *your opinion* is of how the toolchain is supposed to work when you can't fix your own perceived problems, produce horrible unneeded fixes for functionality which the code already provides (if you read and understand it)... and then we look over to the abortion you use for your initial cross-toolchain. *That* is setting a bad example. If you are going to use a full on old-school cross-compiler, at least do THAT properly... Hell at the very least use some symlinks such as $prefix/$target_triple/sys-include -> /tools/include $prefix/$target_triple/lib -> /tools/lib $prefix/$target_triple/lib64 -> /tools/lib64 so the damn thing uses the intended search paths and can at least produce an executable and find its libraries and includes. (you will have to excise some -B from the gcc build itself though for that to work multilib... see clfs 1.0 for the sed) Now note the above. Technical rebuttal, with a side order of derision. No FUD as such. I dont need it. >> See clfs sysroot for a 1 pass build. If you want one for native builds, >> can post it. >> > > I've already said the CLFS Sysroot build is closest in spirit to how > sysroot is meant to work. But > > 1) it's cross compilation and therefore useless as a mainstream build > 2) it fails ICA verification dismally > > What is this "mainstream build" of which you speak. Do you take your audience for idiots. I thought we were here to teach them something. So you in one breath deride the "proper Greg endorsed" method of using sysroot (which it appears you have never used in anger), then bitch about the proposed LFS use of sysroot. And you are then saying you are going to try with a NATIVE sysroot build. /me gazes into his crystal ball /me sees glibc symbol and version mismatch errors in your future Think AC_RUN checks, locale generation (if you don't set BUILD_CC in the glibc build to the hosts compiler... hell you'll need the patch anyway)... basically anything that is compiled as part of a package build which is used for generating/building components of the package. The packages you are building dont know of sysroot, all they know is that they are being built native. Glibc is backward compatible... your hosts glibc may or may not be forward compatible to the version you are building, hence may be quite unhappy when it has to run a binary compiled and linked against a newer version of glibc. Should be a fun challenge for you, try it from an lfs6 era host (or even better RH6.2)... You'll probably have to use all the techniques from cross-lfs sysroot but with additional hacks, and then use a /host-tools directory (you know, that horrible clfs hack /cross-tools) to compile current versions of all the packages you are migrating to for the host into. You may as well just use a cross-toolchain... [R] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
