Re: Re-adding *startfile_prefix_spec
Dan Nicholson wrote: In the adjustment, though, he uses `gcc -dumpmachine`, though. This is probably wise since you don't know what MACHTYPE is from the host's bash. In fact, this might be a good idea for both adjustments. I don't know how reliable MACHTYPE is, but I'm speculating since I don't know how it's determined. Well, the standard solution to this (e.g. on non-bash/non-gcc systems) is to use the output of the GNU config.guess script. AFAIK that's what both bash and gcc do to generate that string. However, they may use different versions of the script, so they may end up with different values, and if we compare the host's bash or gcc to the /tools one, they may also be different (for instance, Mandrake systems used to do this; I don't know whether they still do). signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
On 1/29/06, Jeremy Huntwork [EMAIL PROTECTED] wrote: So. Exepect a commit in ~ 5 minutes. Sorry, one more nit, though this has to do with Binutils-Pass 1 2. I didn't notice it until it was rendered today. Currently, the make command on the rebuild has make LDFLAGS=-s LIB_PATH=/new/path The LDFLAGS=-s won't hurt anything since it's the strip all symbols input parameter for ld. From ld --help: -s, --strip-all Strip all symbols Anyway, since we're not passing -s anywhere else in the book, then it shouldn't be passed here for consistency. Or, it should be added to everything and we can drop the Stripping section :-) -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
Dan Nicholson wrote: The LDFLAGS=-s won't hurt anything since it's the strip all symbols input parameter for ld. From ld --help: -s, --strip-all Strip all symbols Oh, duh. Good catch, Dan. Since I started working with this I kept seeing it and remembering it as the option for '-static'. Which is really a dumb brain hiccup because I use both '-static' and '-s' in various places on the LiveCD build. I think I have some text to fix up in the book due to that... *sigh* I suppose the right thing to do here is pick myself up and try again. But I'm getting pretty bruised. :/ -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
On 1/30/06, Jeremy Huntwork [EMAIL PROTECTED] wrote: *sigh* I suppose the right thing to do here is pick myself up and try again. But I'm getting pretty bruised. :/ I'm issuing a standing 8 count. How many fingers am I holding up? Maybe you could use one of those Hang in there, kitty posters right now. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
Dan Nicholson wrote: I'm issuing a standing 8 count. How many fingers am I holding up? How did you get 23 fingers? Maybe you could use one of those Hang in there, kitty posters right now. Hehe. Um, no thanks. This email was good enough. ;) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
Dan Nicholson wrote: On 1/29/06, Jeremy Huntwork [EMAIL PROTECTED] wrote: So. Exepect a commit in ~ 5 minutes. Anyway, since we're not passing -s anywhere else in the book, then it shouldn't be passed here for consistency. Or, it should be added to everything and we can drop the Stripping section :-) I'll just drop these from the two sections. It will essentially be like it was, but with the cp of the binary. Thanks again, Dan. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
Jeremy Huntwork wrote: Dan Nicholson wrote: On 1/29/06, Jeremy Huntwork [EMAIL PROTECTED] wrote: So. Exepect a commit in ~ 5 minutes. Anyway, since we're not passing -s anywhere else in the book, then it shouldn't be passed here for consistency. Or, it should be added to everything and we can drop the Stripping section :-) I'll just drop these from the two sections. It will essentially be like it was, but with the cp of the binary. Perhaps its not the right place, but passing the -s or --strip-all flag to ld seems to be an interesting educational example. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Ryan Oliver wrote: [snip] Which method do you want to use to link in the correct startfiles 1: misuse the -B flag, overriding GCC_EXEC_PREFIX and setting isystem et al 2: set the location of the startfiles in the spec provided just for this purpose. Thank you Ryan. When I asked you several times before to give technical reasons why we should use the *startfile_prefix_spec, *this* is what I was after. Nothing so concise existed in previous threads. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Greg Schafer wrote: Personally, I don't believe in it and will never use it because: - the spec is faulty. It doesn't work when placed into an external file for use by gcc -specs=... (luckily LFS is not using it externally). Every other spec I've tried works properly when placed externally. (maybe someone can fix this bug in gcc.c ?) - the spec has been slated for removal by GCC devs. When that will happen (if ever) is anyone's guess. - nobody else in the entire world uses this spec. Google for it and see. - the way it's currently used by LFS is an abuse. This thing is for *startfiles*, yet LFS uses it to find libs also. Why do you think the extra libgcc_s.so symlink became necessary? - I do not buy into the argument that it should be used because CLFS uses it. Quite frankly, IMHO CLFS is bizarre.. All the sane cross toolchain build recipes available today do not resort to such hackery. The sane ones all use `--with-sysroot'. But I'm getting off-topic now so I'll save this for another forum/discussion. Oh, and one other important point I forgot: - the spec is undocumented. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
On 1/28/06, Ryan Oliver [EMAIL PROTECTED] wrote: On Sat, 2006-01-28 at 14:36 -0800, Dan Nicholson wrote: Um, the decision might be made for us: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00507.html Yup, and its still there 1 year later. Oops, sorry. I thought that post was from 2 weeks ago, not a YEAR and 2 weeks ago. Sorry for the noise. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Ryan Oliver wrote:
When you are doing an old style cross-toolchain build
Nobody sane uses old style cross-toolchain build procedures these days :-)
(ie: not using a sysroot, all target libraries and includes installed
under /prefix/target/lib /prefix/target/lib64
/prefix/target/{include,sys-include} )
the above -B/prefix/target/lib generates an interesting error when
multilib, the 32bit startfiles get linked into the 64bit libgcc.
You could possibly label its use a bug, especially as it does not
need to be specified ( standard lib search path )
We actually patch that out in cross-lfs.
...which suggests that CLFS build procedures are questionable. I'd be
asking myself the question why nobody else needs to do this? The answer of
course is that modern GCC conveniently provides `--with-sysroot' for
folks to base their cross-toolchain build procedures on... but we're
getting off-topic again.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
On 1/29/06, Jeremy Huntwork [EMAIL PROTECTED] wrote: I have given some major thought to this. And I waited to hear comments. I think at this point, everyone that wanted to, or is able to comment, has done so. The way I see it, both ways achieve the desired effect of finding the startfiles and libraries in /usr/lib. It's out of mine (and most people's) jurisdiction to say which one is technically more accurate although both Greg and Ryan have done some nice education here. I say, let's just pick one or the other and go with it, so long as it achieves the desired effect. Then we can me on to addressing some simpler issues. One of these issues is, how do we start the chroot section without further altering /tools. In other words, how can you tar up /tools at the end of Ch. 5 and reliably unpack and use it down the road. This is the one knock I have against startfile_prefix_spec: it must be placed into the default specs location, which is on /tools. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
Dan Nicholson wrote: The way I see it, both ways achieve the desired effect of finding the startfiles and libraries in /usr/lib. It's out of mine (and most people's) jurisdiction to say which one is technically more accurate although both Greg and Ryan have done some nice education here. I say, let's just pick one or the other and go with it, so long as it achieves the desired effect. Then we can me on to addressing some simpler issues. Right. And, again, we're familiar with the spec. We have used it; *are* using it in stable and cross-lfs. Our tests and experience are based on it. To introduce a new method now would also mean we're introducing a whole new thing to test. So. Exepect a commit in ~ 5 minutes. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
Jeremy Huntwork wrote these words on 01/29/06 18:47 CST: Right. And, again, we're familiar with the spec. We have used it; *are* using it in stable and cross-lfs. Our tests and experience are based on it. To introduce a new method now would also mean we're introducing a whole new thing to test. So. Exepect a commit in ~ 5 minutes. Should we not wait until there is *some* sort of explanation by somebody about Greg's points? Jeremy, since you've taken it upon yourself to take lead in this, could you address some of Greg's points, please? Are we in some sort of hurry to make commits? Especially to something as critical as toolchain packages. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 18:50:01 up 127 days, 4:14, 3 users, load average: 0.62, 0.21, 0.18 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
Randy McMurchy wrote: Should we not wait until there is *some* sort of explanation by somebody about Greg's points? Jeremy, since you've taken it upon yourself to take lead in this, could you address some of Greg's points, please? Ryan did that already. Or haven't you read what he said? Personally, like most everyone else around here, I can't judge which method is technically better. Perhaps some third party that has done both methods and an analysis on each can report back with results. What is *currently* in trunk is an untested (but hopefully working) build. All I'm going to be putting in is a *known* method and what we have been using; what should have been there since September. Surely, you can appreciate that. If, later, we find more compelling reasons to switch to -B, we can. Are we in some sort of hurry to make commits? Especially to something as critical as toolchain packages. I *have* waited for three days on this. We've gotten nowhere. Putting our original method back for now gives us what we had before. To leave it as it is now would mean there is an unknown entity concerning the toolchain in trunk. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
Jeremy Huntwork wrote these words on 01/29/06 19:13 CST: Ryan did that already. Could you point me to that post where Ryan refuted some of Greg's points? I saw a post where Ryan described why a particular method was good, but from the best I could tell, didn't address any of Greg's points why a method was bad. I am not starting an argument, and will not post again. After all, I promised you. :-) I was just hoping that there could be a good discussion. And when someone (especially one of Greg's stature in the toolchain foodchain ladder) says something is bad, and gives what sounds like good reasons (I am not qualified to agree or refute them) for his assertions, and they go unanswered, I feel those assertions are simply being dismissed. I *have* waited for three days on this. We've gotten nowhere. To me, and just an opinion from one guy, three days is not long enough, especially when the guy making the decision is self-admittedly not as technically strong as he should be. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 19:17:01 up 127 days, 4:41, 3 users, load average: 1.11, 1.03, 0.76 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
On 1/29/06, Jeremy Huntwork [EMAIL PROTECTED] wrote: So. Exepect a commit in ~ 5 minutes. Hey, Jeremy, just a little nit. The new specs readjustment will fail because we're piping input to perl, but then using the -i parameter to work on the `dirname ...`/specs file. This fails if that file doesn't exist. Probably, we should drop -i and redirect the output: gcc -dumpspecs | \ perl -p -e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED];' \ -e '[EMAIL PROTECTED]:[EMAIL PROTECTED]/usr/lib/ @g;' gt; \ `dirname $(gcc --print-libgcc-file-name)`/specs Or do the -dumpspecs first, using SPECFILE=... like before. In fact, it might not be a bad idea to leave the SPECFILE=... stuff in there anyway so we can use the variable. That command is getting to be quite a handful, and we don't want the noobs re-running the perl command. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
On 1/29/06, Dan Nicholson [EMAIL PROTECTED] wrote:
On 1/29/06, Jeremy Huntwork [EMAIL PROTECTED] wrote:
So. Exepect a commit in ~ 5 minutes.
Hey, Jeremy, just a little nit.
And another. We're trying to make a symbolic link at
/tools/$MACHTYPE/bin/ld, but a file already exists there. It seems
we'd need to add -f to the ln statement:
ln -svf /tools/bin/ld /tools/${MACHTYPE}/bin/ld
or it'll fail with a File exists error.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
On 1/29/06, Dan Nicholson [EMAIL PROTECTED] wrote: On 1/29/06, Jeremy Huntwork [EMAIL PROTECTED] wrote: So. Exepect a commit in ~ 5 minutes. Probably, we should drop -i and redirect the output: Now that I think about this more, the pipe and redirect *without* -i is much better. This way, you're always editing starting from the default -dumpspecs instead of editing the existing file. Then you can run the command as many times as you want. You don't have to worry about what's in the $SPECFILE file since you're always going to overwrite it. This can also be applied to CLFS where there's a big warning about not re-running the specs adjustment command in Ch. 10.6 (in the x86 book). This is my suggestion: SPECFILE=`dirname $(gcc --print-libgcc-file-name)`/specs gcc -dumpspecs | \ perl -p -e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED];' \ -e '[EMAIL PROTECTED]:[EMAIL PROTECTED]/usr/lib/ @g;' gt; \ $SPECFILE unset SPECFILE -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
Dan Nicholson wrote: Now that I think about this more, the pipe and redirect *without* -i is much better. This way, you're always editing starting from the default -dumpspecs instead of editing the existing file. Then you can run the command as many times as you want. You don't have to worry about what's in the $SPECFILE file since you're always going to overwrite it. This can also be applied to CLFS where there's a big warning about not re-running the specs adjustment command in Ch. 10.6 (in the x86 book). Look at the command again. We're already always overwriting it. Also, with gcc-4, the specs file doesn't exist unless you dump it there first. Technically, when piping it, I guess we don't need -i. But it doesn't seem to be hurting anything, either. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
Dan Nicholson wrote: My fault, I missed the gt in the xml. It works as you say, even running it repeatedly. It would make sense to drop the -i anyway, though. We're not actually supplying perl with a file for the -i. Yep, agreed. I think the -i is a leftover from stable where we *are* editing a file in place. Probably the same for that flashing red note in Cross-LFS about not running the command more than once. I think that's bogus because you always get a new specs file. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Jeremy Huntwork wrote:
+screenuserinputmv -v /tools/bin/{ld,ld-old}
+mv -v /tools/$MACHTYPE/bin/{ld,ld-old}
+mv -v /tools/bin{ld-new,ld}
+ln -v /tools/bin/ld /tools/$MACHTYPE/bin/ld/userinput/screen
Any reason why something similar can't be done for the first pass of
binutils? I forgot about that one.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
On 1/29/06, Jeremy Huntwork [EMAIL PROTECTED] wrote:
Jeremy Huntwork wrote:
+screenuserinputmv -v /tools/bin/{ld,ld-old}
+mv -v /tools/$MACHTYPE/bin/{ld,ld-old}
+mv -v /tools/bin{ld-new,ld}
+ln -v /tools/bin/ld /tools/$MACHTYPE/bin/ld/userinput/screen
Any reason why something similar can't be done for the first pass of
binutils? I forgot about that one.
No, that's essentially what Greg's doing.
http://www.diy-linux.org/x86-reference-build/temptools.html#tt-adjust-toolchain
cp -v ld/ld-new ${TT_PFX}/bin
at the end of Binutils-1 after the make LIB_PATH=/tools/lib
In the adjustment, though, he uses `gcc -dumpmachine`, though. This
is probably wise since you don't know what MACHTYPE is from the host's
bash. In fact, this might be a good idea for both adjustments. I
don't know how reliable MACHTYPE is, but I'm speculating since I don't
know how it's determined.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Dan Nicholson wrote: In the adjustment, though, he uses `gcc -dumpmachine`, though. This is probably wise since you don't know what MACHTYPE is from the host's bash. In fact, this might be a good idea for both adjustments. I don't know how reliable MACHTYPE is, but I'm speculating since I don't know how it's determined. Yes, it's probably better to use what gcc will find. Anyway, here's what man bash says about MACHTYPE: MACHTYPE Automatically set to a string that fully describes the system type on which bash is executing, in the standard GNU cpu-company-system format. The default is system-dependent. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [SUMMARY] Re-adding *startfile_prefix_spec
On Sun, 2006-01-29 at 19:25 -0600, Randy McMurchy wrote: I was just hoping that there could be a good discussion. And when someone (especially one of Greg's stature in the toolchain foodchain ladder) says something is bad, and gives what sounds like good reasons (I am not qualified to agree or refute them) for his assertions, and they go unanswered, I feel those assertions are simply being dismissed. All that was given were the facts for both and some of the history behind why the methods were chosen. I am not going to comment on the goodness or badness of any suggestion, they are loaded terms not conducive to a technical discussion in this forum. Both ways work for an LFS style build. Only one method works for all LFS, LFS multilib, Cross LFS multilib and standard old-style cross-toolchain builds (sysroot builds not included in this list, they dont need these shenannigans) Read what was written, read the gcc info file, look at how the -B option is used during a gcc build (preferably a bootstrap build, so you understand its purpose, why it exists and why you will barely ever see it used anywhere else), then make up your mind based upon the facts. Best Regards Ryan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Jeremy Huntwork wrote: Obviously '-B' works for you, and obviously, Ryan's methods work for him. Is there a 'best for LFS' in all of that? In the interests of getting this issue off your/our plates I'd say we choose whatever method is most suited to LFS as it is now. That is, whichever works on x86 native compilations and is officially supported/documented upstream. Yes, I understand people's desires to keep LFS' CLFS' instructions as close as possible, but given the very different purposes of the two toolchains between those books I'd say this is one point at which it's reasonable to expect the instructions to differ. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Greg Schafer wrote: IMHO multilib is quite complicated. I cannot say anything authoritative about it because I personally haven't had a need for it and therefore haven't researched or tested it. That'll change if someone sends me an AMD64 box :-) Get a free (but slow) x86_64 box either from http://bochs.sf.net/ or (buggy, crashes on 32-bit code) from http://fabrice.bellard.free.fr/qemu/ Both Bochs and QEMU can boot the official x86_64 LFS LiveCD on a regular x86 box, and Bochs can even run /lib/libc.so.6. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Matthew Burgess wrote: In the interests of getting this issue off your/our plates I'd say we choose whatever method is most suited to LFS as it is now. That is, whichever works on x86 native compilations and is officially supported/documented upstream. Yes, I understand people's desires to keep LFS' CLFS' instructions as close as possible, but given the very different purposes of the two toolchains between those books I'd say this is one point at which it's reasonable to expect the instructions to differ. And the more this is discussed, the more I'm inclined to agree. That being said, what is currently in trunk agrees with this standpoint. From all I can tell from the documentation '-B' will give us what we need, and it's only used for two packages, binutils and gcc in chapter 6. The only things in trunk currently that might need changing, then, are: 1) Don't use a wrapper for gcc as seen in the readjusting section. I'm not sure about this one. The alternative to that would be to use 'CC=gcc -B/usr/lib/ -B/usr/bin/' on the sanity test, the binutils configure, and the gcc configure. 2) The libgcc_s.so symlink shouldn't be necessary if we're not using the *startfile_prefix_spec. 3) We could replace the ld's as per the instructions in my patch instead of making a symlink as is in the current book. Advantage is that there is no possibility of the old ld being used and that we shouldn't have to insert a '-L/usr/lib' in the specs file. Disadvantage is that it possibly corrupts /tools again, and we'd have to deal with that. Otherwise, we could leave trunk as it currently is, get some major testing done on it, and see how things progress. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
On Sat, 2006-01-28 at 13:07 +1100, Greg Schafer wrote: Jeremy Huntwork wrote: Isn't using -B to find libraries an abuse as well? Huh? Using a documented switch for a documented purpose? RTFM :-) The purpose of the -B flag is to override GCC_EXEC_PREFIX, the path the gcc driver uses to find its own components. From the info file `-BPREFIX' This option specifies where to find the executables, libraries, include files, and data files __of_the_compiler_itself__ . The compiler driver program runs one or more of the subprograms `cpp', `cc1', `as' and `ld'. It tries PREFIX as a prefix for each program it tries to run, both with and without `MACHINE/VERSION/' (*note Target Options::). When set it will 1: change the options passed to the c pre-procesor ( adds -isystem PATH/include ) so it can find reqd gcc headers (and the fixed includes) 2: use cc1, collect2 etc if found under PATH instead of the ones the gcc driver would normally invoke 3: sets the location gcc will use for pulling in gcc startfiles (crtbegin.o crtend.o) 4: Prepends PATH to the library search order (doesn't add PATH/lib ) so, if the flag was used for its stated purpose, it will pull in libgcc from that location. As stated before, the -B flag causes issues for multilib builds because it does not get modified by the multilib spec. This is perfectly understandable, gcc only installs 1 set of binaries regardless of whether it is multilib or not, and applying multilib path changes to a _binary_ search path is plain wrong. -B isn't meant to be used for setting library search path (that is -L's job), though it performs this task soley because when used for its documented purpose it needs to find libgcc. Used in the case of LFS, all the above changes to standard compilation do not affect the build, 1: we have no includes in /usr/lib/include, so the added -isystem /usr/lib/include wont affect the the c pre-processor 2: gcc will use the binaries it was built with, as we have no gcc component binaries installed under /usr/lib/ 3: gcc will pull in the correct c-library startfiles, more by accident than anything else as gcc would normally be using this set path to find ITS startfiles (crtbegin.o and crtend.o) 4: and of course adds the path to the start of the library search path (where the compiler would normally expect to find libgcc) Consider the fact that the only thing that we want to accomplish is use the correct startfiles. If you look into the history of this issue, it is this problem that needed to be solved. -B/PATH was chosen by DIY as using -L/PATH, while causing the correct libraries to be found during the link, did not set the location used to retrieve the correct startfiles. (these were pulled in from /tools as gcc uses the first set found following its standard search pattern) The startfile_prefix_spec is provided to tell gcc where the c-library startfiles live If startfile_prefix_spec is set 1: if the c-library startfiles exist under the set directory, the startfiles are linked in using the full path to the startfiles, and the path is appended to the end of the library search order to find the libraries associated with those startfiles (ie: the c-libraries) 2: if there are no c-library startfiles under the location, the startfiles are specified to the linker without a path specified and no additional library search path is added NOTE: the only gcc behaviour altered is linking, as opposed to -B which alters include search paths, binary search paths ... Using -B/PATH to set a library search path and the path to the c-libraries startfiles is like driving a nail with the back of an axe. It can do the job (in this case), but it is not its stated purpose, nor the right tool for the job. So the question to lfs-dev is Which method do you want to use to link in the correct startfiles 1: misuse the -B flag, overriding GCC_EXEC_PREFIX and setting isystem et al 2: set the location of the startfiles in the spec provided just for this purpose. Thoughts? Best Regards Ryan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
On Sat, 2006-01-28 at 08:32 -0800, Dan Nicholson wrote:
On 1/27/06, Greg Schafer [EMAIL PROTECTED] wrote:
Ever looked at a build log of GCC itself? Guess what? -B.
/tools/src/build/gcc-build/gcc/xgcc -B/tools/src/build/gcc-build/gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ ...
Seems gcc thinks it's OK to search for libraries with -B. This came
from the line to compile libgcc_s.so in chroot.
Not meaning to fan flames, but -B doesn't look so evil.
You've picked a good example here.
When you are doing an old style cross-toolchain build
(ie: not using a sysroot, all target libraries and includes installed
under /prefix/target/lib /prefix/target/lib64
/prefix/target/{include,sys-include} )
the above -B/prefix/target/lib generates an interesting error when
multilib, the 32bit startfiles get linked into the 64bit libgcc.
You could possibly label its use a bug, especially as it does not
need to be specified ( standard lib search path )
We actually patch that out in cross-lfs.
Best regards
Ryan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
On Sat, 2006-01-28 at 14:36 -0800, Dan Nicholson wrote: On 1/27/06, Jeremy Huntwork [EMAIL PROTECTED] wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353 Our longtime Toolchain Maintainer, Ryan Oliver, still prefers to use this method. Um, the decision might be made for us: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00507.html Specifically: This patch removes STARTFILE_PREFIX_SPEC and I will close PR 19353 as willnotfix. OK? Bootstrapped and tested on powerpc-darwin. Guess what bug that is? Yup, and its still there 1 year later. If the gcc devs actually do decide to remove the only way to sanely override which directory gcc searches for startfiles (and its utility far outweighs its removal) and don't provide an alternative mechanism, I will happily maintain the (miniscule) patch required to put it back in. Best Regards Ryan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re-adding *startfile_prefix_spec
Hello Everyone
As I mentioned in another thread, my intention is to re-add this method
into the LFS book. I've done a test build using this, and everything
works as expected. Using Greg's extended tests, we know for certain that
binutils and gcc will be linking against the right Glibc in chapter 6.
There is a bug open to remove this feature from gcc. But, it is a year
old now and still open.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353
Our longtime Toolchain Maintainer, Ryan Oliver, still prefers to use
this method. His comments are in the above bug link, as well. I'm
inclined to follow his recommendations, if only because it's what is in
our stable book and Cross-LFS. So we have consistency and a tried
method. If GCC devs do ever decide to remove it and close that bug, then
perhaps we can re-consider our options.
I would at this time like to open this up to comments or suggestions
before I apply the changes to trunk. If there is a major reason why we
*shouldn't* use this feature of GCC, it should be brought up now.
Attached is the patch I propose to the book. Note that I could also add
(perhaps in the cleaning up section) to move the original ld files back
in /tools so that if /tools wasn't kept or tarred up before, it's in a
useful state.
--
JH
Index: chapter06/gcc.xml
===
--- chapter06/gcc.xml (revision 7307)
+++ chapter06/gcc.xml (working copy)
@@ -99,6 +99,11 @@
screenuserinputln -sv ../usr/bin/cpp /lib/userinput/screen
+paraMany packages use the name commandcc/command to call the C
+compiler. To satisfy those packages, create a symlink:/para
+
+screenuserinputln -sv gcc /usr/bin/cc/userinput/screen
+
noteparaAt this point, it is strongly recommended to repeat the
sanity check performed earlier in this chapter. Refer back to xref
linkend=ch-system-readjusting role=,/ and repeat the check. If the results
Index: chapter06/readjusting.xml
===
--- chapter06/readjusting.xml (revision 7308)
+++ chapter06/readjusting.xml (working copy)
@@ -19,18 +19,24 @@
directory to the LFS filename class=directory/{,usr/}lib/filename
directories./para
-paraFirst, create a symlink to the adjusted linker we created in chapter 5./para
+paraFirst, backup the filename class=directory/tools/filename linker, and
+replace it with the adjusted linker we made in chapter 5. We'll also create a
+hard link to its counterpart in filename class=directory/tools/$MACHTYPE/bin/filename/para
-screenuserinputln -sv /tools/bin/ld-new /usr/bin/ld/userinput/screen
+screenuserinputmv -v /tools/bin/{ld,ld-old}
+mv -v /tools/$MACHTYPE/bin/{ld,ld-old}
+mv -v /tools/bin{ld-new,ld}
+ln -v /tools/bin/ld /tools/$MACHTYPE/bin/ld/userinput/screen
paraNext, amend the GCC specs file so that it points to the new
-dynamic linker. A commandsed/command command accomplishes this:/para
+dynamic linker, and so that GCC knows where to find its start files.
+A commandperl/command command accomplishes this:/para
-screenuserinputSPECFILE=`dirname $(gcc -print-libgcc-file-name)`/specs amp;amp;
-gcc -dumpspecs $SPECFILE amp;amp;
-sed -i -e '/^\*link:$/{n;s,$, -L/usr/lib,}' \
- -e '[EMAIL PROTECTED]/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED]' $SPECFILE amp;amp;
-unset SPECFILE/userinput/screen
+screenuserinputgcc -dumpspecs | \
+perl -pi -e 's@/tools/lib/ld-linux-so.2@/lib/[EMAIL PROTECTED];' \
+ -e '[EMAIL PROTECTED]:[EMAIL PROTECTED]/usr/lib/ @g;' gt; \
+ `dirname $(gcc --print-libgcc-file-name)`/specs
+/userinput/screen
paraIt is a good idea to visually inspect the specs file to verify the intended
change was actually made./para
@@ -43,18 +49,6 @@
linkend=ch-tools-toolchaintechnotes role=,/ if
necessary./para/important
-paraNow create a temporary wrapper script for filenamegcc/filename.
-This script will point to the real filenamegcc/filename
-in filename class=directory/tools/filename but with adjusted parameters
-to ensure that GCC in the next section links to our newly installed Glibc./para
-
-screenuserinputcat gt; /usr/bin/gcc lt;lt; EOF
-#!/bin/bash
-/tools/bin/gcc -B/usr/lib/ -B/usr/bin/ $@
-EOF
-chmod 755 /usr/bin/gcc
-ln -s gcc /usr/bin/cc/userinput/screen
-
cautionparaIt is imperative at this point to stop and ensure that
the basic functions (compiling and linking) of the adjusted toolchain
are working as expected. To do this, perform a sanity
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Jeremy Huntwork wrote:
Couple of typos in the attached patch. Just letting you know that I've
noticed them, will fix them, and will also render/validate these changes
before I commit. I've made several careless mistakes recently, and I'm
going to be putting much more care into my work in the future. Nothing I
do will go in without discussion/validation/rendering.
+mv -v /tools/bin{ld-new,ld}
^
+perl -pi -e 's@/tools/lib/ld-linux-so.2@/lib/[EMAIL PROTECTED];' \
^
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Jeremy Huntwork wrote: There is a bug open to remove this feature from gcc. But, it is a year old now and still open. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353 Not exactly. That bug report is about startfile_prefix_spec being a faulty spec. It coincidentally highlighted the fact that GCC devs want it removed. I would at this time like to open this up to comments or suggestions before I apply the changes to trunk. If there is a major reason why we *shouldn't* use this feature of GCC, it should be brought up now. It's there in the current stable book and doing the job. Putting it back in unstable now would definitely be better than what you currently have. Personally, I don't believe in it and will never use it because: - the spec is faulty. It doesn't work when placed into an external file for use by gcc -specs=... (luckily LFS is not using it externally). Every other spec I've tried works properly when placed externally. (maybe someone can fix this bug in gcc.c ?) - the spec has been slated for removal by GCC devs. When that will happen (if ever) is anyone's guess. - nobody else in the entire world uses this spec. Google for it and see. - the way it's currently used by LFS is an abuse. This thing is for *startfiles*, yet LFS uses it to find libs also. Why do you think the extra libgcc_s.so symlink became necessary? - I do not buy into the argument that it should be used because CLFS uses it. Quite frankly, IMHO CLFS is bizarre.. All the sane cross toolchain build recipes available today do not resort to such hackery. The sane ones all use `--with-sysroot'. But I'm getting off-topic now so I'll save this for another forum/discussion. We'll also create a hard link to its counterpart in Believe it or not, I've had reports from folks who place /tools on a separate partition. It'd be more robust if you used a symlink instead. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Greg Schafer wrote: Jeremy Huntwork wrote: Isn't using -B to find libraries an abuse as well? Huh? Using a documented switch for a documented purpose? RTFM :-) :/ I have read the man pages on gcc. I was asking for a bit more, if you have it. The problem comes in the form that we have two 'experts' saying two different things. Ryan so positively says that -B shouldn't be used that way, you use it happily. So I'm trying to figure out, between the two toolchain people we have here, where reality lies. Obviously '-B' works for you, and obviously, Ryan's methods work for him. Is there a 'best for LFS' in all of that? If the only technical reason is that -B doesn't work for multilib then we need to ask ourselves: Will LFS ever support mulitlib or non-x86 archs? If so, another method is necessary. If not, then we should again ask ourselves, why use a component of gcc that isn't even officially there? I really don't care what the technical solution is, I don't have any personal feelings attached to this. I just want the best one for LFS. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Re-adding *startfile_prefix_spec
Jeremy Huntwork wrote: Obviously '-B' works for you, and obviously, Ryan's methods work for him. Is there a 'best for LFS' in all of that? When in doubt, play the multilib card! :-) But seriously, I dunno. I fail to see how you can equate the 2. Comparing cross compilation to native compilation is useless. They're rather different beasts. IMHO multilib is quite complicated. I cannot say anything authoritative about it because I personally haven't had a need for it and therefore haven't researched or tested it. That'll change if someone sends me an AMD64 box :-) But I will say this: -B is all about search paths. My gut instincts tell me that -B could be wedged *somewhere* into multilib builds if needed. Ever looked at a build log of GCC itself? Guess what? -B. But I suspect -B might not be needed at all when proper `--with-sysroot' style procedures are used. Anyhoo, I won't know anything for sure until I do the work. Sorry. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
