Re: [lfs-dev] glibc and rpc headers
On Mon, 27 Aug 2012 05:20:39 +0100, Jasmine Iwanek wrote: I'll have a poke at building glibc with no host headers shortly to see what other headers get pulled in, if nothing else it'll keep Greg quiet Fat chance of that :-) Anyway, my immediate concerns have been allayed because it turns out that the host gcc is getting invoked in that part of the build. Regards Greg -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Possible problem with current glibc (LFS 7.2 cant recompile LFS 7.2)
On Sat, 25 Aug 2012 21:59:04 +0100, Jasmine Iwanek wrote: Actually, when I copied in rpc/types.h, I put it in /usr/include/rpc and that made the ch5-glibc build happy Um, doesn't anyone see the obvious problem here? The cross toolchain is apparently finding stuff on the host. The whole point of the cross toolchain is to avoid the host. I'll put money on the fact that the introduction of --sysroot into the build has caused this regression. If true, this is my worst fear realised. Regards Greg -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On Fri, 16 Mar 2012 22:29:29 -0400, Jeremy Huntwork wrote: Greg, there's no need to make this personal. No worries dude. Not trying to cause trouble so my apologies if you've taken any offence. I just tend to get passionate about build method matters. It was mostly reading those (and bits of the source) as well as the tests/experimentation that convinced me that the proposed method is solid. OK. I'm about to go off line for a little while so realistically it'll be months before I'm fully up-to-speed and able to test and analyse changes with authority. I still reckon the proposed changes are: - ugly - unnecessary - overcomplicate the build even more than it already is - reduce overall educational value But if you firmly believe they are solid and you are willing to support through thick and thin and actually document the logic competently, go for it. Catch up with you soon. Regards Greg -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On Wed, 14 Mar 2012 20:32:36 -0700, Bryan Kadzban wrote: It seems that Greg never got the time to comment any more thoroughly on the modifications, either. I'd kinda like to hear what he has to say, Well, I've been doing a lot of reading in order to get back up-to-speed. One of the reasons I haven't commented yet is that nothing has really changed since the last time Ryan and myself debated this back in 2009. And this is one of the big objections I have - the proposed changes are not even based on Jeremy's work, but Ryan's. It's like Jeremy has been waiting around for a few years for me to go away so that he can quietly drop it in. Is Ryan still around to pick up the pieces if things fall apart? AFAIK he hasn't been spotted in the wild for a few years, but then again, I don't hang around in IRC circles so I wouldn't know... And let's be clear. We are not talking about a sysroot per se. It's simply configuring the Pass 1 Cross Toolchain with the sysroot option then (ab)using the functionality it provides. This whole thing came about because Jeremy has doggedly latched onto comments by a toolchain dev back in 2008 when I raised this PR against GCC: http://gcc.gnu.org/PR35532 We are not toolchain developers! It should be obvious to everyone that the needs of the LFS build process are not the same as a GCC dev! There is quite a bit of detail in that PR so I encourage interested folks to analyse it. I repeat, the sysroot configuration options as proposed by Jeremy are a complete abomination IMNSHO. In no way is it upstream intention, in no way is it educational. The sysroot infrastructure is clearly designed for a $SYSROOT/usr layout which we DO NOT HAVE in the temporary phase! Here is an earlier posting/thread which explains it in a lot more detail: http://linuxfromscratch.org/pipermail/lfs-dev/2009-January/062541.html I agree that the current startfiles patch should not be necessary. In fact, I'm sure I had my build working without it at one point in my dev builds but unfortunately I can't find it now.. Sigh.. It looks like I'm going to have to get back on the horse and do the hard work yet again! And while we are on the subject of getting up-to-speed with toolchain matters, it looks like GCC 4.7 is the start of the transition to build GCC with g++. This could have massive implications for us considering we dropped the GCC bootstrap when we brought in the cross stuff: http://gcc.gnu.org/ml/gcc/2012-03/msg00117.html http://gcc.gnu.org/ml/gcc/2012-03/msg00125.html This, and the increasing momentum for the gold linker to become the default, means we are looking at a C++ future for bootstrapping an LFS system. I suspect we are going to need a major overhaul of our build method which is going to be fun to work on.. On the plus side, there is a stack of work going into Glibc at the moment. A lot of it appears to have originated in the eGlibc project to ease cross building and bootstrapping etc. I'm not sure how it happened, but it seems Ulrich doesn't exert the same control he once had. Regards Greg -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On Thu, 01 Mar 2012 16:27:31 -0500, Jeremy Huntwork wrote: And that's it. It's cleaner, more direct, and more closely tracks what upstream has provided. I'm sorry to say this but your whole premise is based on hearsay and personal opinion. Instead of vague assertions about upstream intentions and the like, I'd really appreciate it (if you are going to meddle with the toolchain build method) that you at least do what I have done for years and offer detailed analysis and testing and full explanation so the rest of us can decipher what the hell you're up to. So far you haven't quite demonstrated you fully understand the changes you are proposing. It's been clear over the years that not many folks within LFS have the interest, knowledge, skills etc to do the heavy lifting when it comes to build method matters. This needs to change and there needs to be more experienced eyeballs on these kinds of proposed changes so that they don't sneak through without proper scrutiny. I'm way out of date, out of form, and short on time but I'll try to debunk some of your incorrect assertions as soon as I get the chance. Regards Greg -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On Mon, 27 Feb 2012 22:49:07 -0500, Jeremy Huntwork wrote: The main differences (I'll outline all of them shortly) are the pre-adjusting of gcc in pass 1 along with the use of sysroot and newlib. I'm so far out of touch I don't have the energy to shoot this down. For the record, I don't agree with the changes. Seems to include a lot of the elements I argued strongly against some years ago. IMHO sysroot is fine for real cross compilation sysroot not fine for hybrid cross/native scenarios a'la current LFS There seems to be a lot of additional hacks required to prevent stuff being found on the host (check the diff). BTW, you might want to check your facts re the newlib switch. This sentence is clearly wrong: This enables a very small standard C library that is included with GCC. Good luck Greg -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Directions
On Tue, 02 Feb 2010 07:15:38 +, Greg Schafer wrote: On Mon, 01 Feb 2010 23:00:57 +, Matthew Burgess wrote: What's your recommendation then? Pass '-j1' on the command line for all 'make install' invocations? That's probably overkill. All I know is I've previously been burnt by both GCC and Glibc with `-j3' on 2 cores. It seems other folks have noticed too: http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01236.html 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: GAWK Test report LFS-6.6-rc1
On Thu, 04 Feb 2010 20:46:58 -0600, Bruce Dubbs wrote: FAIL: stackoverflow2 === 1 of 5 tests failed === I've determined that this is a kernel problem. I was using lfs-6.5 and the kernel was 2.6.30.2. After booting to 2.6.32.7, this failure went away. The addition of libsigsegv in gawk-3.1.7 is purely for enhanced core dumping and is therefore optional. Just sidestep the problem by not using libsigsegv i.e. pass `--disable-libsigsegv' to configure. It's what Fedora does. 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: LFS Directions
On Mon, 01 Feb 2010 23:00:41 +0100, Mark Rosenstand wrote: Much more clever would be to mention MAKEFLAGS in the intro somewhere, and add -j1 as needed for the packages that don't support parallel make. Exactly as currently done in DIY Linux. This is what I do in my build scripts, and out of 1300 source packages, I've only had to enforce -j1 for 15 or so. The hidden gotcha is installation. Setting MAKEFLAGS globally like this also affects `make install' and this can really screw you if you're not careful i.e. files that should have been installed were not. 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: LFS Directions
On Mon, 01 Feb 2010 23:00:57 +, Matthew Burgess wrote: What's your recommendation then? Pass '-j1' on the command line for all 'make install' invocations? That's probably overkill. All I know is I've previously been burnt by both GCC and Glibc with `-j3' on 2 cores. And considering the importance of these packages, I take no chances and just add the `-j1'. Note the comment in followup to this: http://gcc.gnu.org/ml/gcc/2006-03/msg0.html I guess for everything else, if breakage is discovered, fix the Makefile :-) Failing that, then add the`-j1'. I've only had 4 cores for a short while and with 6 cores entering the mainstream who knows.. 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: Proposing a new LFS release
On Mon, 25 Jan 2010 01:39:13 +0100, Jean-Philippe MENGUAL wrote: what kind of buildings can do a user exactly with this stable (6.6)? From 64 to 64 bits? From 32 to 32? Or 32 to 64? Actually, the underlying build method supports all combinations: 32-32 64-64 32-64 64-32[*] (* the last one really surprised me as I never designed the method for this. It just requires some judicious use of `setarch') And it even works on hybrid hosts ie: those running a 64-bit kernel with a 32-bit userland. However, as currently implemented by LFS, the full capabilities of the build method are not being exploited. But that's OK, because the LFS target audience probably doesn't need all the possibilities. 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: GRUB-1.97
On Thu, 29 Oct 2009 00:48:05 -0500, Bruce Dubbs wrote: I have updated the book to GRUB-1.97. Grub2 appears to have a major regression in that installing into the PBR no longer works. Note - I'm talking about non-MBR installs, ie: installing Grub into a Partition Boot Record. I haven't looked into this in any depth yet, as I only discovered it while testing out Ubuntu 9.10 which has moved to Grub2. Background - I tend to have a zillion OS's installed (both Linux and non- Linux) and use a thing called Smart Boot Manager to manage the MBR. For example, if I install Ubuntu 9.04 on sda9, installing the Grub that comes with Ubuntu 9.04 into the PBR of sda9 keeps things quite tidy and self- contained. This scenario has worked well for years... I'd be interested in hearing about the Grub2 escapades of others who are accustomed to installing Grub into a PBR. 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: GRUB-1.97
On Mon, 09 Nov 2009 17:36:53 -0600, Bruce Dubbs wrote: I don't know for sure, but I think that install into a PBR is a configuration issue. No, it's definitely a bug (and a regression at that). See these links: http://ubuntuforums.org/showthread.php?t=1284914 http://grml.org/grml2usb/#mbr-vs-pbr For instance, I can put GRUB-0.97 (GRUB Legacy) on the mbr and then boot GRUB2 (1.97.1) from there by specifying /boot/grub/core.img as the kernel. Yes. I found that info on the Grub2 wiki and it allowed me to tailor a solution that boots into Ubuntu 9.10. Anyway, after some research it appears that the Grub2 devs are concerned that PBR installs can trash some filesystems, eg: XFS. But they do allow the use of a `--force' override for those that know what they're doing. All I know is that the Ubuntu installer supports the configuration I'm trying to use and it doesn't work. I'll take it up with Grub2 upstream once I've confirmed the problem exists outside Ubuntu. 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: LFS Directions
On Thu, 17 Sep 2009 15:31:41 -0600, Matthew Burgess wrote: On Thu, 17 Sep 2009 16:18:16 -0500, Bruce Dubbs bruce.du...@gmail.com wrote: #2412 Add more rationale to Toolchain Technical Notes Who do we get to advise us on this one? I'd appreciate it if Greg could help contribute on this I'm horribly behind in my DIY work at the moment. But I'm about to get hold of some quad core grunt so the plan is to get back up to speed asap. (Sidenote: Any plans for LFS to incorporate parallel make into the build? Seems like a gaping omission in this day and age of commonplace multicore cpu's. At the very minimum, Glibc, GCC and Binutils should be given the option of `make -jX' with the appropriate explanation...) Anyway, keep an eye on the DIY Refbuild. Once I've beaten it back into shape, I should be able to offer some advice on the toolchain/build method rationale stuff.. 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: LFS Directions
On Thu, 17 Sep 2009 16:12:43 -0700, Nathan Coulson wrote: I have been experimenting with a multilib LFS System (where /lib, /usr/lib are used for 64bit, and /lib/32, and /usr/lib/32 are used for 32bit). I advise against this. Not FHS compliant and not what the big distros do. The toolchain I use for compiling the system is based on our previous work, I could not make the current directions build a multilib capable gcc toolchain. Current LFS build is not multilib ready. Modification will be neccessary. I have a GCC patch in the DIY Refbuild but it is not the long term solution. I'll be fixing this up soon.. 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: New e2fsprogs
On Wed, 26 Aug 2009 18:58:53 -0500, Bruce Dubbs wrote: bdu...@lfs6:/usr/sbin$ ldd grub linux-gate.so.1 = (0xe000) libncurses.so.5 = /lib/libncurses.so.5 (0xb7efd000) libc.so.6 = /lib/libc.so.6 (0xb7ddc000) /lib/ld-linux.so.2 (0xb7f59000) Looks like it needs it to me. Not quite. It'll happily build without it. One can even configure the build `--without-curses' to force the issue. However, I'm not sure what is actually gained or lost by not linking against ncurses. A quick grep of the source suggests not much. 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: New e2fsprogs
On Wed, 26 Aug 2009 17:27:56 -0500, Bruce Dubbs wrote: From a 64 bit system, we'd need to use cross compile techniques for these files so they don't try to use 64-bit addresses. Umm, what's wrong with installing a 32-bit libc? It's 1 extra package, it solves the grub problem, and it allows for further 32-bit possibilities. IMHO it's a no brainer. 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: New e2fsprogs
On Wed, 26 Aug 2009 18:23:53 -0500, Bruce Dubbs wrote: A 32-bit libc is a consideration. I don't know how to do that yet. I lied. It's actually 2 extra packages :-/ One needs to build a 32-bit libc in Ch 5 too (so that GCC can be multilib) This is all covered in the DIY Refbuild (packages are out of date but the build method is current). Looking at grub-0.97, it also uses ncurses, so I think we'd need a 32bit version of that too. Really? Not when I last looked. 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: New e2fsprogs
On Wed, 26 Aug 2009 18:32:28 -0500, William Immendorf wrote: This has got me thinking: If we are going to build a 32-bit Glibc for multilib LFS, why don't we do a fully multilib system for 64-bit, like how CLFS does it? Because that way lies madness (as has been discussed many times before). IMHO, a saner solution is a 32-bit build chroot and a package manger. 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: LFS-6.5 RC2 plans
On Wed, 29 Jul 2009 04:07:58 -0600, Matthew Burgess wrote: On Wed, 29 Jul 2009 01:29:31 -0800, Rabbit rabbit8...@gmail.com wrote: but I think we should use just only use i686-pc-linux-gnu because I think it doesn't make sense to use i686-pc-lfs-gnu. The 'i686-lfs-linux-gnu' came in through the move across to DIY's build method [0]. This is described at [1]: Hi Guys, Yeah, sorry. Somewhat out of the loop lately (but still reading the lists). I intend getting back up to speed before too long. Matt is correct in that this aspect of the pass 1 cross toolchain is pivotal. ie: not to be messed with. 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: inetutils before perl
On Wed, 15 Apr 2009 14:50:10 -0600, Archaic wrote: +#define PHOSTNAME /usr/bin/hostname /* How to get the host name */ Side note - FHS says hostname should be /bin/hostname i.e. it's a bug. 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
m4 badness
Hi, Just stumbled across this. You will likely want to fix it: http://lists.gnu.org/archive/html/m4-patches/2009-02/msg00010.html 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: Adapting LFS SVN for multilib
Jim Gifford wrote: Again Greg provide us more information about the ICA, it seems to be your own creation? 1. Read this post from Dan Nicholson: http://article.gmane.org/gmane.linux.lfs.devel/8120 2. Look at the comments in the gsbuild scripts from DIY 3. Look at the jhalfs implementation (Note: I haven't) 4. Ask Ryan to explain it to you 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: Adapting LFS SVN for multilib
Matthew Burgess wrote: In which case, all I can suggest is you follow the process yourself: 1) Compile CLFS from a non-CLFS host 2) Use the newly built CLFS to build a second CLFS system (obviously using exactly the same commands and package versions) No, that's not quite right. The second system is done without all the temporary bootstrapping stuff ie: 1. make a copy of the end product (system 1) 2. remove /temp-system from PATH 3. use system 1 to rebuild itself and overwrite as you go (this produces system 2) 4. make a copy of system 2 5. use system 2 to rebuild itself and overwrite as you go (this produces system 3) 6. make a copy of system 3 7. diff copy of system 1 with copy of system 2 8. diff copy of system 2 with copy of system 3 9. analyse the diffs, explain them 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: LFS Toolchain
Jeremy Huntwork wrote:
It
is a new approach compared to earlier versions of LFS in that the the
first pass of binutils and gcc we are creating cross compilers and the
chapter 5 glibc is cross compiled. It is a native build from that point
forward.
Some weeks ago, Ryan proposed a somewhat alternative method
Huh? Not quite.
It's still the same basic method that *I* developed. Cross toolchain for
Pass 1, cross compile temp Glibc, native thereafter. Please don't lose
sight of the fact that I developed the basic concept *[1]. I did the
testing. I got it working. Ryan has introduced some adjustments to the
method. Some good, some not so good.
The irony is, Ryan's appearance here and jumping on board of the basic
idea actually *vindicates* what I've been saying for years - that CLFS is
massive overkill for those wanting a 64-bit multiarch toolchain. I
actually did something about it. Now folks are taking notice. Remember way
back when CLFS fanboys were promoting CLFS as the next best thing? Where
are they now? :-)
that does not require any adjustment of the toolchain in chapter 5
I think this is a regression, actually, at least from an educational POV.
and does not
depend on using -B/tools/lib/, by the cross compiler in order to get it
to find the new startfiles. There is also a patch that DIY and current
trunk uses for GCC pass 2 which reverts GCC to old functionality so that
it will use prefix to find the startfiles. Ryan's approach also does not
require the use of this patch.
Agreed. Those are warts. I've fixed them in my dev build and you should
continue with your current Pass 2 toolchain.
This method uses sysroot functionality in GCC and Binutils to help
'mask' off the host system further.
Huh? No! It's quite the opposite! This clearly demonstrates you don't
understand the sysroot feature at all. I'm surprised that I have to
explain this to you in detail, but I will anyway. And also keep in mind
you are using the sysroot feature in pass 1 only.
Look at the source of gcc.c. Grep for `add_sysrooted_prefix' and note that
every call (bar one *[2]) occurs within the the block:
if (*cross_compile == '0' || target_system_root)
ie: if native build or sysrooted build
In other words, by using the sysroot feature in pass 1, you're bringing in
all the *native* host dirs into the equation! Hence your hacking of
STANDARD_STARTFILE_PREFIX_{1,2} in pass 1.
The *whole* point of me using a non-sysroot cross compiler is to avoid
searching the host *at all*. Not only that, by using the sysroot feature,
you fall afoul of the `inhibit_libc' configure logic. Therefore you're
forced to add even more configure switches
--with-newlib
--without-headers
Not to mention how ridiculous `--with-newlib' is when you're not even
using newlib! Yet *another* blatant GCC docs violation!
The sole reason Ryan chooses to abuse the sysroot feature is because it's
the only way he can make multilib work (without using the already beaten
to death startfile_prefix_spec) ie: it allows him to (ab)use the *native*
STANDARD_STARTFILE_PREFIX_1
In essence, what you gain on the swings, you lose on the roundabout.
Greg says we're 'hacking the source' in the first pass of GCC, but if
you actually look at the changes being done, it's the same modification
of config/linux.h that the specs patch has always done
You're making the changes in *both* passes. Unnecessary hackery and you
know it. Stop blurring the truth.
In summary, the evidence against the use of sysroot in pass 1 is mounting.
You choose to ignore it, your problem.
Regards
Greg
*[1]. Alexander Patrakov deserves some credit for sparking the concept by
suggesting the possibility of:
a) dropping the GCC bootstrap and
b) using a cross toolchain for Pass 1
*[2]. The other one is of course startfile_prefix_spec. But that's a whole
separate discussion, and one already beaten to death.
--
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: Adapting LFS SVN for multilib
Ryan Oliver wrote:
Don't mix up explanation with example.
This merely re-enforces the point I made above.
What? That you're using sysroot incorrectly?
FHS standard under the _logical root directory_ is not implied.
Huh? It's written in black and white. You're ignoring reality.
Exactly as was done for plfs, lfs and DIY.
Hell, you are already hacking *_THE EXACT SAME MACROS_*.
Huh? plfs or lfs has never tinkered with STANDARD_STARTFILE_PREFIX_{1,2}
up until now. I first started using them about a year ago to prevent host
searching. You're making stuff up.
I am using the sysroot feature for a target system root.
Yes, but for a *non-root* filesystem, in violation of the docs.
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.
Wow, man, you're starting to lose it. Stay focused!
I put this build together *solely to prove a point*
No, you put this build together solely because someone finally came up
with something better then your beloved CLFS. Face it! You would never
have showed up here to share your knowledge had we not dented your pride.
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).
Ok, now we've heard everything. Ryan has become a GCC developer! Looking
forward to you submitting patches!
You have had 4 years of clfs to look at
You have had 4 years of clfs to try and get a new build into LFS. You
failed.
Why the hell should anyone take any credence in what *your opinion*
Well, at least I don't disappear for years on end.
Hell at the very least use some symlinks such as
Good idea.
What is this mainstream build of which you speak.
Mainstream, as in your typical Joe Sixpack who simply wants to build his
own system ie: typical LFS reader. Not your uber power tech nerd who
enjoys pulling teeth by wanting to bootstrap from Solaris.
sysroot (which it appears you have never used in anger),
Now you look real stupid. My sysroot testing was done years ago and is
archived at DIY. Where is your IRC development archived?
And you are then saying you are going to try with a NATIVE sysroot build.
Huh? I actually said it likely wasn't viable. Recall?
Anyway, we're now starting to go round in circles. I've made my points.
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: LFS Toolchain
Ryan Oliver wrote: Look back into the clfs-lite that was proposed 4 years ago in the lfs wiki. Referenced here http://linuxfromscratch.org/pipermail/lfs-dev/2005-April/051171.html Vapour. 4 years ago your opinion was markedly different with regards to using cross-compilers for any part of the lfs toolchain. Yes. This is true. But I now leverage cross compilation where it's actually useful. You entirely miss the point of cross-lfs Nobody here wants to bootstrap from Solaris. if (*cross_compile == '0' || target_system_root) ie: if native build or sysrooted build *HEH* Man you cant even understand simple code... and here I am having technical arguments with you... You are posting late at night. This probably explains your confusion and ranting. I'll try to say it again in different words so you can understand. - The paths inside that conditional block take effect when a native compiler. - The paths inside that conditional block take effect when a sysrooted compiler (cross or not cross). Now, who is it that doesn't understand the code? Remember, for a sysrooted cross-compiler cross_compile == 1 AND target_system_root *IS* defined Yes, which means the above referenced block of code will take effect because it's a sysrooted compiler. Get it? Please also keep in mind a sysrooted compiler doesn't have to be cross! Remainder of embarrassing drivel deleted Now. Let's all sit back, and enjoy the show while you explain your way out of this one! 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: LFS Toolchain
Jeremy Huntwork wrote: For those unfamiliar see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 For those not interested in reading the entire bug history, the last comment by a dev was: Using the sysroot flags is the solution for Greg's scenario. In fact I would say it makes his job easier. Umm, that bug report is about Pass 2. Your using the sysroot feature in Pass 1. See a problem? 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: LFS Toolchain
Jeremy Huntwork wrote: No, sorry, I don't. In the comments of that bug report the dev suggests using sysroot for pass 1 of gcc. Yeah, and he also says create $sysroot/usr/include. If you're going to hang your hat on the word of 1 junior GCC dev... Also, haven't you noticed that making use of sysroot in pass one eliminates the scenario that is causing you trouble in pass 2, thereby removing the need for the patch? Huh? Not at all. Please, JH, explain how this is so. And like I said earlier, the patch is already gone in my dev build - no sysroot in sight. 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: Adapting LFS SVN for multilib
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 You're using sysroot on a non-root file system. Which is why you are forced to hack the source to make it search only the dirs that you want. I repeat - You're abusing the sysroot feature and setting a poor example. 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 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: Adapting LFS SVN for multilib
Ryan Oliver wrote:
The sysroot build is misused in pretty much the same way the original
native plfs toolchain was misused.
Just another data point for the record.
Here, a senior toolchain person confirms how sysroot is meant to be used
(read the whole bug report for context):
http://lists.gnu.org/archive/html/bug-binutils/2007-08/msg00110.html
I quote:
You should use --prefix=/usr and install it with install_root=${sysroot}.
The whole point of the sysroot feature is that it establishes a chroot
style environment.
Note, the chroot style environment that he's referring to is the
equivalent of LFS Ch 6, not Ch 5.
I stand by my claim that you're abusing the sysroot option and setting a
very poor example of its use.
Sidenote: Now that some toolchain devs are apparently using *native*
sysroot builds, there is a temptation to pursue a whole new build method
that bypasses most of Ch 5. However, we would most certainly lose a lot of
the advantages of the current 2-phase approach, so gut instinct tells me
this won't be viable. Obviously, ICA verification would be *critical* to
such a build method.
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: Adapting LFS SVN for multilib
Ryan Oliver wrote: Except you then are placing tools compiled and linked against the host in the directory that is supposed to be clean. Huh? I'm grouping *temporary* tools together in the one dir. It's not the dir that's supposed to be clean. It's the build method. You unnecessarily complicate the build. I keep it simple. Incorrect. The initial point of installing into a separate directory (for myself, the choice was my home directory) was to be able to a) re-use the toolchain.(so as to use distcc when building on slow systems) b) ensure that /tools never sees any pollution from binaries, libraries or includes of packages compiled against the host system c) Allow for easy restarting of the build. All completely irrelevant in a mainstream build method. And like I said, current DIY/LFS doesn't overwrite anything and is therefore restartable. You solve problems that don't exist. I keep it simple. Except $prefix is not used in a non-sysroot cross-compiler. At present your cross-toolchain neither locates includes anywhere (you would have to set CROSS_INCLUDE_DIR via editing CROSS_SYSTEM_HEADER DIR in makefile.in for that to happen without resorting to a specs edit), or locates libraries or startfiles (which you misuse -B for). Huh? I don't have to set anything. I follow the *man page* and use the convenient command line switches provided *exactly* for includes, startup files and libs. The more you say I misuse -B, the sillier you look. From http://gcc.gnu.org/onlinedocs/gccint/Driver.html#Driver Here is the order of prefixes tried for startfiles: 1. Any prefixes specified by the user with `-B'. 2. snip etc, etc. You hack the source. I keep things simple by using the provided *user* *interface* wherever possible. It isn't exactly finding libraries directly via $prefix either (it calculates it from gcc's location in the filesystem via gcc_exec_prefix, which relocates with the toolchain) Thats what your forward ported patch from the 2.95.3 days is there for (make it search $prefix). Wrong. The patch is from GCC-4.2. Please get your facts straight. Directly altering the macros which define include and library search paths allows you to install the toolchain into any prefix you want (or relocate it anywhere you want after install), Honestly, nobody here gives a rats arse about relocating a toolchain. We don't do it. We never relocate anything. These completely irrelevant tangents you keep flying off on are astonishing. Again, you solve problems that don't exist. I keep it simple. No I am not. You can continue to install the updated ld-new with the search path in the linker scripts set /lib and /usr/lib etc -rpath-link accomplishes the same thing by altering ld's default search No one's disputing how -rpath-link works. It's just unnecessary, ugly and error prone. Just look at the current CLFS mess. You uglify your build unnecessarily. I keep things simple. Setting the fully documented LIBRARY_PATH env var and using it for its documented purpose does not in any way upset the build even if you forget to unset it later either.. Again, no disputing how LIBRARY_PATH works. Again, toolchain altering env vars are error prone, fragile, and not suitable for mainstream. You said it yourself years ago. And never will. If it did it would totally break the gcc and glibc builds (the only places you will ever find it used). Test it yourself, its a one character edit in gcc.c to make it multilib aware. Welcome to 10 months ago! It happened while you were MIA. Read the GCC thread and especially this post (from someone who actually knows what he's talking about): http://gcc.gnu.org/ml/gcc/2008-03/msg00767.html It is there for educational value. You have the choice to build either 32bit or 64bit, whatever floats your boat. It takes no extra time or effort to do the job properly.. Educational? I hope you're joking. Folks want a simple build that does the job and is easy to understand. Complicating the build unnecessarily is just silly. An analogy is in order: We both want to get from London to Paris. We both get there in the end. You make life hard for yourself by going via New York. I fly directly over the channel. Sysroot build method apart from the obvious advantages, frankly, has the added advantage of deflecting FUD. Sysroot build for LFS-style build method is needless complication. Just look at how many extra build commands you need. That's a fact. 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: Adapting LFS SVN for multilib
Ryan Oliver wrote: No, I solve problems for which you have not catered for yet. CLFS deals with building from non-linux hosts. Off topic Isn't your supposed goal technical perfection that us mere LFS mortals can only aspire to? Not at all. Get the job done as quickly and efficiently as possible. And be easy to comprehend. I've proven that the path to a fully functional multiarch Ch6 toolchain does not require your levels of technical perfection. WTF are you talking about, looks like theres a fair amount of hacking the source in your build.. Note the where possible in my statement. It would take 5 minutes to generate a simple patch to do this (even by Yep, of course. But even blind Freddie can see it won't be accepted by upstream. Feel free to try. Which reminds me, why has CLFS been carrying around the Binutils Multilib Patch for years without ever submitting upstream? Don't have the balls? Why hasn't anybody else needed it? Maybe the functionality isn't actually needed? It's disgraceful CLFS behavior. Please fix it. I'll change the analogy: I fly in first class without having to lift a finger on my comfortable ride to the destination You are in economy trying to hold your seat together I'll pay that one :-) Present build ensures our toolchain works by itself. DIY toolchain without command line switches and generating and sed'ing specs cannot find includes, libraries or produce a binary Irrelevant, as has been proven. You're *still* missing the point. Congrats, there is nearly a valid argument in there this time. It's been a good discussion. Has made me think about the build a bit more. I'll be getting rid of a few warts in the DIY build. 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: Adapting LFS SVN for multilib
Jeremy Huntwork wrote: I have been adapting Ryan's methods to LFS because I think that there are certain improvements over what is currently in trunk. Specifically: A quick glance shows you are bringing in one of CLFS's ugliest design faults - the bizarre `/cross-tools' prefix. Let me explain: By installing stuff into different prefixes, you are forced to butcher the GCC source to coax it into searching the right places. Why? Because many of the toolchain search paths are keyed off of $prefix. There is much less hackery involved if you install into a single prefix ie: /tools. One of the rationales for CLFS introducing the `/cross-tools' thing was apparently to prevent the over-writing of Pass 1 files with Pass 2. This no longer happens with current DIY/LFS because Pass 1 is now a cross toolchain. The other rationale was to keep some separation. Personally, I don't buy this argument. The whole thing is temporary anyway, and the cost of ugly hackery far outweighs any tidyness benefit. In summary, $prefix is king, and I refuse to mess with it. * No need for ever specifying '-B/tools/lib' Sure. But at what cost? It appears you haven't tackled Chapter 6 yet. Ryan appeared to be pushing `-rpath-link' and/or global toolchain ENV VARS such as LIBRARY_PATH. The hypocrisy here is that, back when Ryan and myself worked on the previous build method, we *both* ruled these out as unsuitable for the masses. I refuse to use arcane linker switches and global toolchain ENV VARS in any build recipe of mine. I might also remind folks that `-B' is the documented user interface to GCC search paths. It's true that it currently doesn't respect multilib os dirs ie: it doesn't search `../lib64', `../lib' etc. But guess what, IT DOESN'T MATTER! Folks here apparently haven't grasped that when building a 64-bit multiarch toolchain, a fully functional 32-bit toolchain is not needed until well after the Ch 6 toolchain is in place. The gcc devs have said that the sysroot methodology is the 'correct path forward' for cross compiling. Yes, but you're missing the point that the inhibit_libc mini GCC we build in GCC Pass 1 is not the typical cross compiler the gcc devs are talking about. And I can assure you, they are most definitely *NOT* talking about the kind of misused sysroot you're proposing here. I'm honestly surprised that Ryan has (ab)used sysroot in such a fashion. As much as it pains me to say, the CLFS Sysroot build is much closer to the mark as an example of a cross toolchain for typical embedded use. Also, I hope your not basing your sysroot justification on an off-handed comment from 1 junior GCC dev in a GCC bug report of mine. That would be rather foolish to say the least. To me, this is the way forward for 7.0. To me, you're completely off track. Good luck. 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: Adapting LFS SVN for multilib
Jeremy Huntwork wrote: As far as 'butchering the source' goes, there's nothing done in the first pass of GCC to the source that isn't done in pass 2. Essentially it's the same sort of stuff we've _always_ done in pass 2 to ensure that the compiler uses only the libs and headers in /tools. In fact, it's less, because we don't have to mess with a specs setting. Sorry, you're wrong and clearly not getting it. Meanwhile, it's apparent you've turned into a Ryan nut hugger, just like the rest of the CLFS crowd. God help LFS! I honestly don't care anymore. LFS is a project without direction, without leadership and apparently has lost sight of what made it popular back in the day. Good luck fellas! 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: Adapting LFS SVN for multilib
Ryan Oliver wrote: Incorrect. The initial point of installing into a separate directory And this is documented where? Another CLFS strong point! Dude, you can blather on all you like. But none of your rhetoric can hide the fact your builds are as ugly as sin and incomprehensible by mere mortals. I'll continue to champion the KISS principle, clean, simple, easy to understand. BTW, when was the last time you ICA verfied a CLFS build? What, you haven't? Oh dear.. 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: Sysroot based sane multilib toolchain build for LFS style builds [update]
Ryan Oliver wrote: # Sysroot based SANE multilib cross-compiler build for LFS style builds Heh, this is hilarious. A new and improved build method goes into LFS and CLFS folks awake from the dead :-) Feeling some pressure guys? :-) Sorry mate, but this whole thing looks of very poor quality and not at all suitable for a mainstream LFS build method. It looks like same old CLFS bodged up to imitate DIY/LFS! But the worst part is it comes complete with all the CLFS design flaws, crazy hackery, silly patches and unnecessary configure switches! Sorry dude, but if you're going to bob up here with attitude and put up shite on this list then I'm going to criticize it. And dude, it doesn't make it any saner the more times you write the word `sane' in caps. It's like you're trying to bamboozle everyone with how many toolchain buzzwords you can throw around. You might be able to impress your IRC wannabe cronies with this caper but you ain't fooling me. I've started tearing this apart piece by piece and will put up my finished notes when I return from holidays. A mainstream build method suitable for a project like LFS needs to be simple, clean, robust and (sorry to be blunt) reasonably idiot-proof. You fail on all counts IMNSHO. 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
CLFS antics
Author: jim Log: Creating of CLFS Native Structure Well, well, well. What have we here? What happened to the big `C' in CLFS guys? Changing your name to NLFS? I've seen some incredible stuff on the *LFS lists over the years but this appears to be the most breathtaking act of arrogance I've ever witnessed. Here it is folks, living proof CLFS are competing directly against their parent project. I'm utterly gobsmacked.. If the LFS project had any kind of leadership with any kind of backbone, there'd be serious consequences for this kind of divisive behavior. Regards Greg PS. Merry Christmas. -- 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: The new build method is in...
Ryan Oliver wrote: Couple of minor things 1: Chapter 6.15 - If you aren't bootstrapping the compiler, you wont be using the newly created binutils to build your new gcc. Correct. DIY takes care of this with the `-B/usr/bin/' thing. Whether it actually matters much is questionable. As per usual, there's only 1 way to find out - ICA. FWIW, I regularly ICA-verify the DIY build. AFAIK, no one has bothered to ICA LFS lately, even tho' the option is apparently right there in jhalfs. Either bootstrap or add CC=gcc -B/usr/bin to override GCC_EXEC_PREFIX. Bootstrap? No thanks. Lets not add to global warming by wasting unnecessary cycles. This is something easily proved by binary diffing 2 systems. Yes, I've done it. LFS isn't affected by the -specs handling bug as we do not pass -specs=/some/specfile on the gcc command line ??? Not affected? LFS doesn't have the clean split between the 2 phases like DIY does. I can simply wipe the chroot phase files and start clean with a pristine temptools system. This is a HUGE efficiency gain for testing purposes. 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: The new build method is in...
Jeremy Huntwork wrote: With revision 8755, the new build method from DIY is in place with the exception of support for multilib. (More on that in a second.) No. You've also omitted perhaps the most interesting feature of the whole thing - the ability to migrate from a 32-bit system to a 64-bit system. As it currently stands, you're forcing folks to start from a 64-bit system if they want 64-bit. Useless. All this `case $(uname -m) in' stuff you've added is bogus. You'll have to rethink how you're going to handle this aspect if you want it to work. The other thing you've omitted is proper attribution. A simple Thanks, me is not good enough for something this big. The LFS changelog is not perpetual. You of all people should know how much time and effort goes into engineering this stuff. Some extra words next to my existing entry on the Acknowledgments page will suffice. ... Technical Writer and Architect of the Next Generation 64-bit-enabling Build Method or similar. I would like to know people's thoughts on how to deal with multilib in LFS. It's a good question. It's easy for me in DIY because I actively target scripting. Because LFS targets the interactive command line, you'll have to be careful not to introduce too much awkwardness. But whatever you do, you *must* introduce a 32-bit Glibc in the 64-bit case. I'm even considering dropping pure 64-bit in DIY because its usefulness is limited. 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: The new build method is in...
Jeremy Huntwork wrote: Knock it off. I don't come to DIY and disparage your work. Huh? Get over yourself dude. You've *always* taken things so personally. Grow a thick skin. Remember I'm trying to support *you* implementing *my* work. Watch your tone and focus on the task at hand. Thanks. 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: Aiming for 7.0
Jeremy Huntwork wrote: What do you think is likely to happen in future versions and/or what is your plan? GCC is not going to revert back, clearly. Just continue to maintain the backport patch for future versions? Pretty much. It's similar in principle to the current specs handling ie: change the behaviour of the temporary phase GCC to suit our purposes. It's not such a big deal. 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: Aiming for 7.0
Jeremy Huntwork wrote: 1. Move to DIY's new build method in trunk. If we ignore multilib and any extra arch support for this step, the changes required aren't actually that many, and they all take place pretty early in chapter 5. I realize you say this step, but LFS is already too far behind, 64-bit should be top priority. Ignoring multilib is a big mistake. The whole point of the new method is multilib and 64-bit! To be clear, I'm *NOT* talking about full-blown development system CBLFS style, that way lies madness. Just basic addition of 32-bit Glibc when targeting 64-bit. Grub builds fine, some 32-bit proprietary binaries can run, potential for expansion. It's the most flexible approach. There are other, saner, ways to do full 32-bit development when running 64-bit (chroots, vms, etc.) NOTE: FYI, I haven't tested Binutils-2.19 in 64-bit scenarios yet. Looking at the diff, there is some potential there for linker problems with the build method. I'll start some test builds when I get time. 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: Aiming for 7.0
Jeremy Huntwork wrote: Greg, as I have your attention, I'm curious why the -fomit-frame-pointer change is still present in your second pass of gcc. I thought the purpose of this was to maintain compatibility between the first bootstrapped pass of gcc and the second pass? GCC is no longer bootstrapped. But you still want resulting GCC to be byte-for-byte identical as compared to what it would be if it were bootstrapped. 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: r8754 - in trunk/BOOK: chapter01 chapter05 chapter06
jhuntwork wrote:
Initial addition of support for x86_64
???
This is nothing like the new build method at all. It appears you've taken
stuff from the old jh branch, which is now completely outdated because
it's based on the old build method.. Ughh. Not sure where you're going
dude, but this is definitely the wrong way to do 64-bit. As stated
earlier, I'm not touching the old method with a 10 foot pole..
Modified: trunk/BOOK/chapter06/creatingdirs.xml
===
--- trunk/BOOK/chapter06/creatingdirs.xml 2008-12-03 22:04:18 UTC (rev
8753)
+++ trunk/BOOK/chapter06/creatingdirs.xml 2008-12-03 22:46:04 UTC (rev
8754)
@@ -24,6 +24,8 @@
for dir in /usr /usr/local; do
ln -sv share/{man,doc,info} $dir
done
+ln -sv lib /lib64
+ln -sv lib /usr/lib64
mkdir -v /var/{lock,log,mail,run,spool}
mkdir -pv /var/{opt,cache,lib/{misc,locate},local}/userinput/screen
I realize it's early days, but how are you going to distinguish between
32-bit and 64-bit builds? As it stands, you're creating 64-bit dirs even
in the 32-bit case.
Modified: trunk/BOOK/chapter06/readjusting.xml
===
--- trunk/BOOK/chapter06/readjusting.xml 2008-12-03 22:04:18 UTC (rev
8753)
+++ trunk/BOOK/chapter06/readjusting.xml 2008-12-03 22:46:04 UTC (rev
8754)
-screenuserinputgcc -dumpspecs | sed \
--e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED]' \
+screenuserinputgcc -dumpspecs | sed -e 's@/tools@@g' \
So you went ahead and snuck this in anyway?
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: Aiming for 7.0
Greg Schafer wrote: In a (native) sysroot scenario, anything and _everything_ can be found on the host. Here's a Binutils thread about a sysrooted ld which touches upon what I'm talking about: http://sourceware.org/ml/binutils/2008-08/msg00060.html 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: Aiming for 7.0
Jeremy Huntwork wrote: Upstream appears to think that using sysroot is the correct approach sysroot is a complete non-starter for us. Think about it. Have you ever tried a sysroot build? In our current build methods, we go to *great* lengths to prevent stuff from being found on the host. In a (native) sysroot scenario, anything and _everything_ can be found on the host. It's completely useless to us if we want to keep within the spirit of the current builds. 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: Readjusting toolchain nitpick
Jeremy Huntwork wrote: We can simplify the sed expression and get rid of the note entirely if we change it to: -e 's@/tools@@g' Anyone have any objections to this change? I'd just like to make the following points: 1. You're introducing a distinct lack of clarity about what is actually being performed. 2. The dynamic linker issue is such a critical aspect in the whole process that it warrants highlighting. 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: gmp required ABI=32
Ken Moffat wrote: My box built gmp and the first part of chapter 6 during the night without any apparent problem. The host system was LFS-6.3 with a current kernel. I just looked into this. It appears the bug only tickles when CFLAGS are set. ie: if CFLAGS are set in the environment, it guesses the wrong ABI when building 32-bit x86 on 64-bit AMD hardware (not sure about Intel). You can easily reproduce this by setting CFLAGS then running ./configure. Issue is exacerbated due to GMP's tricked up config.guess ie: $ ./config.guess athlon64-pc-linux-gnu $ /usr/share/libtool/config/config.guess i686-pc-linux-gnu $ /usr/share/automake-1.10/config.guess i686-pc-linux-gnu The CFLAGS aspect at least explains why everyone is not seeing this. This implies Tobias has both a compiler and libc in chroot that are able to handle -m64. No. See above. 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: gmp required ABI=32
Tobias Gasser wrote: i had to add ABI=32 as my system was identified ad 64bit. ./configure ABI=32 --prefix=/usr --enable-cxx --enable-mpbsd i'm using CFLAGS=-O3 -march=i486 as a global setting, overwritten for some special cases mentionned in the book. any idea why i have to add ABI=32 ??? You're on 64-bit capable hardware? I brought this up here about a month ago, and over 2 years ago on the GCC list. I'm surprised more people haven't hit it: http://article.gmane.org/gmane.linux.lfs.devel/7762 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: ICA/Farce
DJ Lucas wrote: Hey guys. Is there any recent documentation on the expectations of farce or ICA? Docs? What docs :-) Doing only 2 passes of chapter6 with both comparison methods checked. What are the advantages of 3 or more passes? Huh? ICA by definition is 3 passes. No ifs, buts or maybes. Any other number is meaningless and exposes a lack of understanding of what is being tested. I've never looked at jhalfs but I understand it implements my ICA algorithms. My own scripts have been getting exceptionally clean results lately now that the randomness in GCC builds has apparently gone as of GCC 4.3. I'll happily check any results you can post up. 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: ICA/Farce
Bruce Dubbs wrote: Umm, no. jhalfs parses the xml of the book and creates a Makefile that builds by the LFS book. Actually, it is quite convenient. Umm, yes. It's *VERY* convenient. I should know.. (Me wonders if Bruce realizes the whole build straight from the doc concept in jhalfs is based on my own practices in DIY? Which in turn was based on the old lfscmd from about 8 years ago? :-) But getting back on topic, I should really write up some proper docs on ICA some day, instead of relying on the random mailing list spatterings over the years. 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: glibc-2.8-20080929 build fails in Chapter 5
Em Wednesday 15 October 2008 16:42:37 Robert Connolly escreveu: When GCC 4.1 released libssp, Glibc copied all of libssp in to Glibc, for better performance. Sorry, but that's rubbish. Glibc has *support* for ssp. Big difference. 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: GMP and MPFR
Dan Nicholson wrote: Just for the record, I know guile can use an external libgmp: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=configure.in;h=e67e1d84;hb=HEAD#l820 Google shows that clamav and openswan use it, too. I don't know if that's compelling enough, but I thought it should be known. The next version (7.x) of Coreutils can link against libgmp if available. From the release notes: If the GNU MP library is available at configure time, factor and expr support arbitrarily large numbers. Pollard's rho algorithm is used to factor large numbers. Yet another reason for possibly separate gmp installation in the chroot. Keep in mind tho' there are some gotchas. Last time I checked, the problem pointed to below was still there ie: build failure for 32-bit x86 if the real hardware is 64-bit. http://gcc.gnu.org/ml/gcc/2006-10/msg00698.html 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: r8591 - in trunk/BOOK: . chapter01 chapter03 chapter06
Randy McMurchy wrote: Not sure why you're seeing it. In fact I had 0 (zero) failures on my testsuite run. :-) ext/Sys/Syslog/t/00-load..ok ext/Sys/Syslog/t/constantsok ext/Sys/Syslog/t/syslog...ok Ah, maybe something else (libc, kernel) has since been fixed. I'll also look into it. Thanks for your interest in our development and especially your comments. It is very nice of you to be helping out like this. No worries. Good to see you pitching in to get the LFS ball rolling. 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: GCC configure option --disable-decimal-float
Randy McMurchy wrote: I'm about to begin commits for package updates to LFS SVN. I'm reviewing things first and I noticed in DJ's book that the --disable-decimal-float parameter is passed in the GCC Pass1 configure command. This apparently is for the MPFR package which is built during GCC-Pass1. Um no. It's actually for GCC, tho' the switch also has meaning for MPFR. I guess DJ found reference to this switch in my GCC 4.3 notes. But I've since realized it's probably not necessary (for DIY at least. It was never applicable for the out-dated LFS build method). To clarify, in DIY I build a super minimal Pass 1 GCC ie: with none of the optional target libs, libmudflap, libssp, libgomp, etc. I initially thought libdecnumber was one of these target libs but it's actually a *host* lib in GCC parlance and doesn't get installed. Therefore the switch doesn't really do what I initially thought it did. But I'll probably keep it because it does result in a quicker build and a much smaller libgcc.a. But I guess you could drop it. 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: glibc-2.8 [was: Re: GCC-4.3.1, Linux-2.6.26.2]
Randy McMurchy wrote: And if you follow Greg's link, you'll see that his workaround is: cp -v ../glibc-$GLIBC_VER/iconvdata/gconv-modules iconvdata and for what it's worth, it didn't help me. I did this before running the tests and still got the iconv errors. Umm, you also need a patch in addition to above: http://www.diy-linux.org/downloads/patches/glibc-2.8-iconv-tests-1.patch 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: glibc-2.8 [was: Re: GCC-4.3.1, Linux-2.6.26.2]
Robert Connolly wrote: On Sunday September 7 2008 06:00:55 pm Greg Schafer wrote: Robert Connolly wrote: I got rid of the iconvdata/bug-iconv6, and iconvdata/tst-iconv7, errors by rebuilding Glibc a third time, without patches, after installing Binutils-2.18 and GCC-4.1 in chapter 6. I'm retrying with gcc-4.2. It looks like a PATH issue... the testsuite is looking in /usr or /lib and finding it empty, instead of looking in the glibc-build/ directory. Might be fixed in glibc-cvs. http://sourceware.org/ml/libc-alpha/2008-05/msg00065.html http://sourceware.org/ml/glibc-cvs/2008-q2/msg00271.html http://sourceware.org/ml/glibc-cvs/2008-q2/msg00272.html Regards Greg -- http://www.diy-linux.org/ When I use those patches I lose the two errors, and get a dozen more. Yeah, me too. Eventually, I discovered the cause and came up with a workaround: http://www.diy-linux.org/pipermail/diy-linux-dev/2008-September/001280.html 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: glibc-2.8 [was: Re: GCC-4.3.1, Linux-2.6.26.2]
Robert Connolly wrote: I got rid of the iconvdata/bug-iconv6, and iconvdata/tst-iconv7, errors by rebuilding Glibc a third time, without patches, after installing Binutils-2.18 and GCC-4.1 in chapter 6. I'm retrying with gcc-4.2. It looks like a PATH issue... the testsuite is looking in /usr or /lib and finding it empty, instead of looking in the glibc-build/ directory. Might be fixed in glibc-cvs. http://sourceware.org/ml/libc-alpha/2008-05/msg00065.html http://sourceware.org/ml/glibc-cvs/2008-q2/msg00271.html http://sourceware.org/ml/glibc-cvs/2008-q2/msg00272.html 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: GCC-4.3.1, Linux-2.6.26.2
Robert Connolly wrote: I'm curious if any of you have tried the Binutils test suite with gcc43. I get failures from binutils-2.18, and more failures from binutils-2.18.50.0.9. Saw these failures back in Feb'. Binutils CVS HEAD checkout from around that time resolved the failures. But I never did figure out which part of the diff did the trick. You might have better luck with 2.18.50.0.5. Haven't tried any recent HJL releases yet, 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
Re: GCC-4.3.1, Linux-2.6.26.2
Steve Crosby wrote: FYI: building them in the tools directory is going to be problematic. During the stage 1 build of gcc, the make system is unable to locate the libmpfr.so.1 library, and so aborts. Guys, this issue has already been solved. Just unpack the GMP and MPFR tarballs into the already unpacked GCC tree and *build them as part of the GCC build*. It solves most problems and is clearly the more robust approach. More info here: http://www.diy-linux.org/pipermail/diy-linux-dev/2008-February/001192.html 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: Choosing a boot loader for LFS 7.0
Alexander E. Patrakov wrote: as explained in http://wiki.linuxfromscratch.org/lfs/ticket/2161 (a blocker), due to recent changes in e2fsprogs, Grub-0.97 no longer works (cannot read any files from the resulting filesystem, cannot be installed into MBR, and the book is thus horribly broken). There are a couple of tickets about alternative boot loaders: Hi Alex, interesting. A couple of questions/observations. - Does the problem exist when Grub installation is run in its preferred native mode as per the Grub docs? ie: not run from within a running Linux kernel, but instead run from eg: a floppy before any OS is loaded? - There is nothing stopping folks from changing the default Inode size back to 128 via editing /etc/mke2fs.conf or via a command line switch. LFS could just warn, yes? That's not so horribly broken, is it? - LFS could change its install paradigm. There is no need to create the target partition immediately from the outset. For example, I intentionally changed this aspect in the DIY Refbuild in order to avoid the situation that's occurred in the past whereby creating a target fs with a too new E2fsprogs (think Fedora host) causes incompatibilities with the (older) version being installed. Did anyone investigate the boot loader options further? What should be done for LFS-7.0? What about Grub2? The time must be getting near.. Anyone use it? 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: Poll about package management
Alexander E. Patrakov wrote: 2008/3/4, Greg Schafer [EMAIL PROTECTED]: [x] file conflict detection -- essential feature [x] simple BLFS style dependencies -- essential feature [x] pre/post install scripts -- essential feature [x] ability to build the whole distro as non-root -- killer feature [x] meta package support (package groups) [x] knowledge of which packages are pulled in as dependencies and which are installed explicitly BTW, Pacman does all of the above. Yes, it does. I have a virtual machine with Arch, and its package manager really looks good. I have not tried to write my own build script for it yet, though. Since you know more about Pacman: does it allow running arbitrary scripts on the DESTDIR contents before actually creating a package? Um, I don't think so. However, while Pacman itself is written in C, the makepkg portion of the system is a Bash script which allows easy hackability. That's what allowed Alex Merry to write the fake_install() patch that I still use today. While I'm a Pacman fan, it is by no means a perfect PM. It uses an ASCII text package database which tends to slow down when you have a zillion packages installed. It probably won't do everything you want, like easy splitting off of -devel and runtime packages. The config file handling is allegedly based on the same algos as RPM. Having said all that, I'm still on 2.9.x. A Refbuild reader contacted me recently and said he was running the latest version successfully so I'll look at upgrading once I finish beating on GCC-4.3 and various toolchain/build method matters. You seem to be striving for perfection. When I want all the bells and whistles I run a mainstream distro. It is simply too labour intensive to have the lot on a self built system. I looked at the amount of effort Dan has apparently put into his RPM based system and weeped :-( Pacman is good enough for my meagre needs, but I wouldn't use it if, for example, I was trying to be the next Ubuntu. 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: proposal for inclusion of e2fsprogs in chapter 5
Bryan Kadzban wrote: Thomas Pegg wrote: since su'ing to root even from the lfs user the path does not carry over, /tools/bin is lost. It will carry over unless your shell login scripts explicitly reset it. Umm, not necessarily. It depends if the `su' comes from Coreutils or Shadow, as I once found out the hard way. The Shadow supplied `su' explicitly twiddles with PATH. Look at src/su.c for proof. More background here: http://www.diy-linux.org/pipermail/diy-linux-dev/2005-August/000610.html Sidenote: next Coreutils release will no longer install install `su' by default. 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
[ANNOUNCE] Next Generation build method
Hi, While we are talking about the evolution of LFS, now seems like a good time to announce to the wider LFS community the availability of a Next Generation build method. The main advantages of the new method are: - sane x86_64 bi-arch (aka Multilib) - no more weird host issues like those experienced recently by Alexander on Debian Lenny - when targeting x86_64, it doesn't matter whether the host is running 32-bit or 64-bit kernel or userland or combination of both, it just works. The new method is actually just a variation on the current build with these key differences: - Pass 1's of Binutils and GCC are built as cross tools to form a cross toolchain - Temptools Glibc is cross compiled using the cross toolchain, with everything after this built natively - GCC is no longer bootstrapped. We've been kidding ourselves for years on this issue. Detailed explanation later The new work is not yet finished, but I can say with good authority that folks wanting x86_64 bi-arch will soon no longer have to refer to CLFS. Some background mailing list posts: http://www.diy-linux.org/pipermail/diy-linux-dev/2007-October/001123.html http://www.diy-linux.org/pipermail/diy-linux-dev/2007-October/001125.html http://www.diy-linux.org/pipermail/diy-linux-dev/2007-November/001161.html The Work-In-Progress new method is published here. Please heed the warning, and note also that extra environment setup is required (detailed earlier in the document). http://www.diy-linux.org/reference-build/temptools2.html 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: [ANNOUNCE] Next Generation build method
Ken Moffat wrote:
On Tue, Dec 11, 2007 at 08:41:06AM +1100, Greg Schafer wrote:
- when targeting x86_64, it doesn't matter whether the host is running
32-bit or 64-bit kernel or userland or combination of both, it just
works.
In best /. fashion, I haven't read the links yet, but you're saying
it's ok to run 64-bit userspace on a 32-bit kernel ? I've used
linux32 to enforce a 32-bit personality, but I've never managed to
get it to work in the other direction.
Um, no. That's not possible. It's still essentially a native build method
which means we *must* be native by the time we start building the pass2
toolchain after the temp Glibc ie:
[[ $DIY_TARGET == x86_64* $(uname -m) == i?86 ]]
{ echo build a 64-bit kernel and reboot into it!; exit 1; }
In other words, if starting from a 32-bit host, one must use the pass1
cross toolchain to cross compile a 64-bit kernel (easy peasy) and reboot
into it.
Sidenote: the soon-to-be-released 2.6.24 kernel has merged the
i386 and x86_64 arches ie: it's now just x86 which makes creating a
compatible 64-bit .config a whole lot easier.
Greg, thanks for posting this. I look forward to reading the
references you've provided (and also to finally saying goodbye to
the testsuites on the initial toolchain builds which I assume will
go with a cross-compile).
Say what? Folks are still running testsuites in Ch 5? (checks current LFS)
Ughh, that's insane. Sensible folks stopped doing this years ago... it
should be ripped out entirely IMHO.
I thought you used to dislike bi-arch on x86_64 ? (/me likes both
pure64 _and_ bi-arch, but not at the same time ;-)
Not dislike, rather, I just feel it can be a whole lot of bother for the
average build-from-source person. But having said that, a basic 64-bit
bi-arch setup with just a 32-bit Glibc (minus the 32-bit versions of every
other lib in sight) can be quite useful as a 64-bit system with the
ability to compile and run occasional 32-bit code. Then, one has the
option to go further with the 32-bit stuff if desired.
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: ICA diff in cc1 and cc1plus
(dredging up an old thread) Dan Nicholson wrote: On 3/19/07, Dan Nicholson [EMAIL PROTECTED] wrote: So, it seems this difference is embedded in cc1 and can't be stripped out after the build. I'm assuming that the original difference is just debugging symbols like would normally be the case. I'll try to narrow that down further, but this may be a false positive ICA regression. I took a look at the diff of the `objdump -s' output from the unstripped cc1-dummy in each iteration. All the differences were in the .debug sections, so I think I can say that the difference in cc1 and cc1plus can be ignored as a result of the embedded checksum. I still don't know why this isn't the case in DIY. It's because I build GCC like this: make LDFLAGS=$LDFLAGS with LDFLAGS=-s I just hit this diff when ICA-verifying the new build method I'm working on where I'd ripped out the LDFLAGS. Back in they go... 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: Glibc: --enable=kernel=???
Alexander E. Patrakov wrote: The 2.6.24-rc2-mm1 kernel spams the log with messages like this: fork(): process `artsd' used deprecated clone flags 0x40 Thread starts here: http://lkml.org/lkml/2007/11/13/577 According to the upstream author of glibc (see http://lkml.org/lkml/2007/11/14/6), distributions should not compile glibc with such an old --enable-kernel as 2.6.0. Yes, time to up it for sure. Been on my todo for a while. Most experienced folks will probably be using --enable-kernel=current anyway... but, normal folks should be taught the significance of this switch by pointing to here: http://sourceware.org/ml/libc-announce/2001/msg0.html and also pointing to sysdeps/unix/sysv/linux/kernel-features.h 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: [LFS Trac] #2094: Add a new section for build results
Justin R. Knierim wrote: It is clear that supporting multiple arches is becoming more and more useful. CLFS is a sub project of LFS and already has working and tested implementations for so many arches, with 32bit, 64bit and multilib. These are not all useful at this time in the main LFS book. Umm, not sure why the CLFS guys are apparently getting their knickers in a knot. The issue is very plain and simple: - CLFS mostly uses *CROSS* compilation - LFS always uses *NATIVE* compilation If someone wants to build for ppc then why should they have to resort to cross compilation when native compilation works perfectly well, and is in fact preferred because it's less complicated? Same goes for pure x86_64, sparc, etc. Implying that non-x86 arches are somehow the sole domain of CLFS is patently absurd. Of course, multilib is another kettle of fish. LFS is a long way from supporting it and this is where CLFS knowledge can be learned from. But as I've said in the past, I personally think multilib x86_64 is far more trouble than its worth for your average Joe Sixpack which is why I haven't pursued it.. (yet). 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: --with-arch=i486 (was Re: Merging the jh branch to trunk)
Jeremy Huntwork wrote: echo CFLAGS += -march=i686 configparms snip Everything went smoothly, so unless anyone has any objections, this is the method I'll be dropping in, except using i486, of course. I won't commit for the next hour or so, however, so that will give at least some time for other comments or objections. One of the downsides of using `-march=' by itself is that it implies `-mtune='. Therefore you have just tuned your libc for i486. Not good. As mentioned previously, GCC-4.2.x tunes for `-mtune=generic' by default. That means, at least for the Ch 6 Glibc, you really should be using these CFLAGS -march=i486 -mtune=generic. I will be adding something similar to DIY soon (but slightly more complicated due to multiple version support). 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: 7.0 Goals (top level bootstrap)
Robert Connolly wrote: With HLFS I'm leaning towards bootstrapping the chroot toolchain. It's how the GCC developers would want it. You cannot speak for the GCC developers, so please don't. IMHO you are WAY off the mark anyway. I don't know if LFS has also considered the top level makefile build method being promoted by GCC/GNU, so that GCC and Binutils are built together in the same tree. The difference here is that Binutils is also bootstrapped like GCC. I have considered it, but ruled it out for obvious reasons. What's more, I don't know why you think this is something new. Building combined tree toolchains has been an integral part of the top level build system ever since the Cygnus Solutions days. What *is* new is the fact that the assembler and linker can now also be bootstrapped as part of the 3-stage GCC bootstrap process. You have apparently overlooked the obvious fact that combined tree builds are designed for *developers* working from svn trunk. They are clearly not suitable for builds based on tarballs which is what we as *consumers* are using. Just look at the hacks you have to use to create the combined tree. If the big distros ever start using a combined tree, that's when we should look at it IMHO. 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: r8374 - in trunk/BOOK: . chapter01 chapter03 chapter05 chapter06
Author: jhuntwork
Date: 2007-09-15 14:45:13 -0600 (Sat, 15 Sep 2007)
New Revision: 8374
+screenuserinputfor file in $(find gcc/config -name linux64.h -o -name
linux.h)
+do
+ cp -uv $file{,.orig}
+ sed -e 's@/lib\(64\)\?\(32\)\?/ld@/toolsamp;@g' \
+ -e 's@/usr@/[EMAIL PROTECTED]' $file.orig gt; $file
+ echo
+#undef STANDARD_INCLUDE_DIR
+#define STANDARD_INCLUDE_DIR 0 gt;gt; $file
+ touch $file.orig
+done/userinput/screen
Ughh, gotta say the above is horrid IMHO. I realize you're trying to get
rid of the specs patch.. but at the expense of your target audience? This
is a critical part of the build method and you've just *massively*
increased the chances of screwups IMNSHO.
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
--with-arch=i486 (was Re: Merging the jh branch to trunk)
Jeremy Huntwork wrote: On Fri, Aug 31, 2007 at 04:54:50PM -0500, Bruce Dubbs wrote: There also needs to be more explanation in the text interspersed with the instructions. For instance in 5.4. GCC-4.2.1 - Pass 1 we have: Also, the --with-arch flag is only necessary for x86 machines. The WITHARCH variable seems to be a configure option, but I can't find it in ./configure --help or with a grep of configure. In any case, I have Pentium 4 CPU. Why do I want to use --with-arch=i486 instead of --with-arch=pentium4. snip As Greg mentioned, by using --with-arch, we are effectively introducing optimization into the build. Much text in the book needs to be adjusted to show why we are using this and what is considered 'safe'. Also, AFAIK, you could conceivably use pentium4, or whatever fits your CPU - again, it's optimization. I want to go on record as saying `--with-arch=i486' is wrong for LFS. Note: I'm not against optimization in general. In fact, just the opposite. After all, if you're going to the trouble of building your own Linux system (and you are experienced) then you are in the perfect position to take advantage of any safe optimizations that are available. But having said that, LFS wisely does the right thing by not promoting optimization to its target audience. But getting back on topic, I personally don't buy any of the arguments for using `--with-arch=i486' listed in this ticket: http://wiki.linuxfromscratch.org/lfs/ticket/2018 coz Debian does it - this change is being proposed because of Glibc, and we all know defacto upstream Glibc is Red Hat/Fedora, and they do NOT do it this way. They use CFLAGS which is the proper Glibc way. See below. you can't copy code to real i386 anyway, so why lose by default - bogus argument. This kind of thing comes up on Fedora lists all the time. The expert's opinion is that `-mtune=' provides far more benefit than any `-march=' flag which is why they actually use `--with-cpu=' for gcc. it's a binary compatibility issue - bogus argument. The meaning of ABI is well defined. Please show any real life example of where mixing different -march= compiled x86 code makes a difference. It doesn't. I also don't buy the entire system is built consistently comments from the commit. The whole toolchain is actually an i686-pc-linux-gnu configured toolchain. I'm sorry, but that ain't consistent with i486. At least Debian *are* consistent because they configure their toolchain as i486-pc-linux-gnu. But the worst part IMHO has already been pinpointed by Bruce in that it will encourage novice users to play with `--with-arch=my-uber-cool-cpu'. This isn't bad in itself but it can lead to problems. For example, it has been well known for years that you cannot compile Glibc with a GCC that was configured as `--with-arch=i686' (unless you patch Glibc). It bombs out due to conflicts in GCC preprocessor macros with Glibc assembler code. This is arguably a bug in Glibc, but the fact that Glibc devs refuse to fix it indicates rather strongly that CFLAGS is the correct way to build Glibc. It also proves that CC=gcc -march=i?86 is wrong for Glibc. To clarify, if you give CFLAGS to Glibc configure, it will build .c files with those flags but it won't use them for .S files. In summary, it is MHO that configuring Glibc with CFLAGS=-march=xxx etc is the more technically correct way and less likely to encourage novice users to hose their system. BTW, on a side note. As is already well known GCC-4.2.x enables some interesting new options, namely `generic' and `native' ie: you can pass `-mtune=native' and gcc will automatically tune for your k8 if you happen to be running Athlon64 etc. `-mtune=generic' is now the default. ie: the defaults on i686-pc-linux-gnu have now changed like this: gcc-4.1.x -march=i386 -mtune=i686 gcc-4.2.x -march=i386 -mtune=generic However, the GCC docs say this about generic: Produce code optimized for the most common IA32/AMD64/EM64T processors. If you know the CPU on which your code will run, then you should use the corresponding -mtune option instead of -mtune=generic. But, if you do not know exactly what CPU users of your application will have, then you should use this option. Obviously, -mtune=generic is ideal for distros. But IMHO (and according to the above) -mtune=native is probably better suited for us folks. The upshot of all this is - if using GCC-4.2.x and including a `-march=' flag in the CFLAGS given to Glibc configure, it's probably best to also give an `-mtune=' flag, either generic or native. 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
SOLVED Debian Lenny issue (was Re: Bootstrap GCC Pass 1 or 2? (was Re: Resolution))
Alexander E. Patrakov wrote: All these Invalid argument errors indicate that either parameters are passed incorrectly to glibc functions, or the return codes of glibc functions are misinterpreted. The guess is that gcc stage1 doesn't understand Debian's multilib setup and picks up wrong files in /usr/include (and thus, stage2 is miscompiled). One more confirmation of this idea: if you don't add --disable-libmudflap, you get a compilation error about redeclaration of something with a different size. Conclusion: Debian Lenny x86 multilib setup (which is clearly a huge deviation from upstream gcc) is not going to be supported by any native build method. The fact that non-bootstrap of gcc pass1 works is pure luck. Ok, finally got around to looking at this problem. Indeed, it's a fscking nightmare. Allow me to explain.. The Invalid argument string can be traced back to the errno handling stuff in libiberty, then to gcc.c where the perror_with_name() function is called by the pfatal_with_name() function. pfatal_with_name() is called from within the load_specs() function here: /* Open and stat the file. */ desc = open (filename, O_RDONLY, 0); if (desc 0) pfatal_with_name (filename); if (stat (filename, statbuf) 0) pfatal_with_name (filename); A strace log shows what is happening: access(/temptools/src/gcc-build/gcc/specs, R_OK) = 0 open(/temptools/src/gcc-build/gcc/specs, O_RDONLY) = 3 write(2, xgcc: , 6) = 6 write(2, /temptools/src/gcc-build/gcc/spe..., 52) = 52 write(2, \n, 1) = 1 exit_group(1) But hang on, that makes no sense! The file is definitely there, but the open() call has failed for no apparent reason. WTF? Ok, it's clear something deep in the guts of libc is majorly broken here. Further investigation reveals Debian Lenny does some (possibly weird) stuff with the multilib Glibc include dirs. Essentially, it's a 32-bit host so the Glibc 32-bit headers are naturally in /usr/include. But then they've gone and stuck the 64-bit Glibc headers into /usr/include/x86_64-linux-gnu. With that information in hand, it now becomes clear why the build is so deeply screwed. Basically, the stage2 gcc was linked against a 64-bit libc but compiled against 32-bit libc headers. Arghhh! ie: the stage1 gcc (used to compile stage2 gcc) doesn't know to look in /usr/include/x86_64-linux-gnu for it's headers. I made the the build succeed by adding `-isystem /usr/include/x86_64-linux-gnu' to BOOT_CFLAGS. Therefore, I think Alex's analysis is mostly correct. ie: it's a Debian-only 32-bit host multilib issue. Specifically, it's the method they use to set up the include dirs on a 32-bit host. But frankly, I don't know enough about multilib to judge whether this obviously non-standard setup is kosher or not. However, it does make sense and I can see why they've done it. In a typical 64-bit multilib host setup, this kind of header arrangement is not needed because the 64-bit Glibc headers are 32-bit compatible (at least I think that's the case, not sure..) Anyhoo, at least we now understand the issue and have a workaround. I need to think more about the big picture and whether we need to worry about this unusual host scenario. BTW, some of the above core issues are touched upon here: http://www.lotterer.net/blog/en/78 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: Debian Lenny as host
Jeremy Huntwork wrote: On Fri, Aug 31, 2007 at 08:11:22AM +1000, Greg Schafer wrote: PS - This addition seems like overkill as most multilib setups default to m64. It appears Jeremy is catering to those unsupportable with current build method non-standard 32/64-bit setups such as Alex's Debian Lenny example. Yes, it was added originally to cover that scenario, but I'm no longer catering to that host. When it came time to commit a few necessary changes today, I decided to leave it in since it will always force binutils and gcc to build 64-bit on pass1. As you say it is probably unnecessary even there, but at least by including it, we know without doubt that we're getting 64-bit, even on multilib hosts. Thereafter, of course, it isn't necessary at all since we'll be using our 64-bit only compiler. If you think it's better to leave it out entirely, please explain why. Because it's *COMPLETELY* unnecessary. There is absolutely no need at all to force the pass1's to be 64-bit. It's irrelevant if they happen to be 32-bit binaries. What *is* relevant is whether they produce 64-bit code or not. Please see my other posting where I solved the Debian Lenny issue. My build worked perfectly even though binutils-pass1 and the stage1 gcc were themselves compiled as 32-bit binaries. The critical thing is the `target': checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking build system type... x86_64-unknown-linux-gnu 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: Debian Lenny as host
Dan Nicholson wrote: Except that you're still using the host grep, which may not have the -q option (don't remember when it was added). FWIW circa 2000 Red Hat 6.2 (grep-2.4) has it. PS - This addition seems like overkill as most multilib setups default to m64. It appears Jeremy is catering to those unsupportable with current build method non-standard 32/64-bit setups such as Alex's Debian Lenny example. 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: 7.0 Goals
Jeremy Huntwork wrote: So far, I've left it as is, meaning that all three builds of gcc are bootstrapped. Say what? Ugh, that's just unnecessary in the extreme! We covered this years ago.. This, certainly, is overkill, but as has been already mentioned elsewhere, the fact that bootstrapping is the default from upstream should say something. You misunderstand. You need to look at it in the context of the overall build method. GCC devs certainly want you to bootstrap.. and you already have.. once! Just step away for a moment and think about the true meaning of the word bootstrap. Perhaps we could do something like: * Bootstrap pass1 * Use '--disable-bootstrap' for pass2 * Bootstrap the final gcc Thoughts? Strongly disagree. That means your final Glibc (the most important lib in the whole system) was compiled with a non-bootstrapped GCC. That is not logical (and it's also what CLFS does IIRC). Please see the second last para in this posting for some more comments: http://linuxfromscratch.org/pipermail/lfs-dev/2005-August/052536.html The bottom line is this: the current build method works on the assumption that a non-bootstrapped GCC-Pass2 and Ch 6 GCC produce identical byte-for-byte compilers compared to what would have been produced had they been bootstrapped. This is a test I perform myself from time to time and it needs to be done every time we upgrade to a new major GCC version. 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: Bootstrap GCC Pass 1 or 2? (was Re: Resolution)
Jeremy Huntwork wrote: Does that not sound right? It all sounds good and well but that's not the point. what you are proposing is exactly how typical cross compilation scenarios work. Cross compilation schemes, by definition, cannot bootstrap. Thus, a *HUGE* advantage of a native build method is the luxury of bootstrapping GCC. Consider that GCC-4.2 changed the default of `make' to perform a bootstrap. Why do you think this is so? Yes, we could try moving the bootstrap to pass2, but there are lingering doubts about its viability. Also consider that during a bootstrap, stage 1 is compiled by the host compiler with no optimization. There is good reason for this. Under the proposal, this aspect is lost which I suspect will make the build *less* robust. The GCC docs even say something like when building a cross compiler, you should first build a native compiler (or something to that effect). Hopefully you can see the point I'm trying to make (and please don't suggest we build GCC pass1 with no optimization or I'll scream! :-) The bottom line is we still no don't know the cause of the issue you are seeing. Until we understand all the issues, I'm very reluctant to majorly alter a build method which has held us in good stead for approx' 4 years. This problem is so far confined to hosts with 64-bit kernel running mostly 32-bit userland and it's possible the only sane solution for this scenario is cross compilation. It might be worth trying a different host distro, Fedora maybe, to see how pervasive the problem is. Anyhoo, I'll try to reproduce and figure out the problem when I get time, but it won't be for a while yet. 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: Bootstrap GCC Pass 1 or 2? (was Re: Resolution)
Jeremy Huntwork wrote:
$ echo 'main(){}' | ./gcc/xgcc -xc -v -
You have to give it a -B arg so it can find the sub-tools like cc1 etc.
Just look at the build log for an example.
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: Bootstrap GCC Pass 1 or 2? (was Re: Resolution)
Jeremy Huntwork wrote:
$ echo 'main(){}' | ./gcc/xgcc -B./gcc/ -xc -v -
Reading specs from ./gcc/specs
xgcc: ./gcc/specs: Invalid argument
It appears there is something invalid in the specs. The trick will be
finding out what it is. Maybe you could hack the specs somehow.. sorta
like a binary search (bisection) to figure out which spec it's choking on?
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: Bootstrap GCC Pass 1 or 2? (was Re: Resolution)
Jeremy Huntwork wrote: Even after fixing this, there remains an issue with bootstrapping GCC pass 1 (the actual error appears to be related to a mis-generated spec file for stage 2 - I can set this up again if you need to see the exact error), and the root cause is probably connected to the multilib setup. Why can't you just figure out what the real problem is? ie: debug it. It would save me having to do it :-) If the problem is due to a multilib setup, then I would think we would want to account for it in our build method. It would allow us to build from a wider range of hosts. True. If skipping the bootstrap on pass1 allows it to build when before it didn't, it certainly adds weight to the proposal. But maybe there is a simple workaround? Like I said, we need to understand the root cause so we can make educated decisions. C'mon dude, show us what you're made of! 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: Bootstrap GCC Pass 1 or 2? (was Re: Resolution)
Jeremy Huntwork wrote: Alright, I've done some testing on this. (Greg, have you been able to look at anything related on your end?) No, sorry. Got busy (damn customers :-) Let me just say first of all, that the more I think about it, the saner it seems to save bootstrapping GCC until pass 2. Conversely, the more I think about it, the more I don't like it.. will say more after I've done some analysis. However, I haven't written it off yet.. The host that Alexander suggested, multilib Debian Lenny for x86_64 with 32-bit userspace makes a good testcase. I disagree. We're trying to keep it simple, no multilib, no mix of 32-bit/64-bit userland/kernel. The simplest test case we have is: pure x86_64 host comprised of gcc-4.2.1/glibc-2.6.1/hjl-binutils-2.17.50.0.18 targetting gcc-4.1.2/glibc/-2.5.1/fsf-binutils-2.17 We are trying to eliminate the target ld doesn't like host libc issue, aren't we? If so, the above test case tells us immediately because we know it doesn't work. Anyhoo, I'll follow up when I have some more facts. 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: An idea for a new development model
Alexander E. Patrakov wrote: The first step would be to convert everything to DESTDIR-style installation, and then adapt some existing (Slackware?) scripts to package the result. IMHO, RPM would be overkill here. Pacman rules!!! :-) Oops, sorry, back on topic. I guess Slackware scripts could be adapted judging by the content at Jaguar Linux: http://www.jaguarlinux.com/ 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: Resolution (was Re: jh-branch)
Greg Schafer wrote: The facts are, our current native build method relies on the ability to link against the host libc with the target ld. There is nothing inherently wrong with this approach because it should always work in typical LFS build scenarios (barring bugs of course). Yes, it would probably be better if we could avoid it somehow, but the build method would need to change radically in order to achieve this - cross compilation, gross hacks, whatever. Hmmm, thinking about this some more, there might actually be another option and that's the one already raised by Alex ie: don't bootstrap GCC pass1 (possibly move the bootstrap to pass2 as suggested by Jeremy). As it currently stands, the new tools start being used in combo with the host glibc during stage2 of the bootstrap. We could avoid this by dropping the bootstrap of pass1. That leaves the only exposed areas as kernel headers installation and glibc configure, but if they cause problems, we might be able to get away some PATH twiddling. There might be some merit here.. I'll chew on it for a while and maybe try some tests. 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: jh-branch
Greg Schafer wrote: I plan to start on x86_64 some time next week. Hopefully the problem is reproducible on non-Debian setups. Confirmed. I've just reproduced it here. I'll send a note upstream and try to get an explanation as to why it affects only x86_64. 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
Resolution (was Re: jh-branch)
Alexander E. Patrakov wrote: Greg Schafer wrote: Confirmed. I've just reproduced it here. I'll send a note upstream and try to get an explanation as to why it affects only x86_64. Many thanks. Could you please keep lfs-dev informed about your further communication with upstream? Sure. The thread starts here and is quite interesting and features input from the usual toolchain gurus: http://sourceware.org/ml/binutils/2007-08/msg00198.html In summary, it basically confirms everything we already knew and also what I've been saying all along here on lfs-dev. ie: - it's an x86_64 binutils-2.17 bug - binutils devs are reluctant to fix bugs in old releases - hash-style is supposed to be back-compatible - a 2 line patch works around the problem The facts are, our current native build method relies on the ability to link against the host libc with the target ld. There is nothing inherently wrong with this approach because it should always work in typical LFS build scenarios (barring bugs of course). Yes, it would probably be better if we could avoid it somehow, but the build method would need to change radically in order to achieve this - cross compilation, gross hacks, whatever. If someone can come up with something sane (and tasteful!) that works, great, let's look at it. But I'm not holding my breath.. At the risk of dredging up old flamewars, I'd be very reluctant myself to involve cross compilation in a mainstream build method. It's all been said before, but I'll repeat just this point - IMHO cross compilation is a specialty niche area that is not at all well suited to the relatively simple task of building a new Linux system for Joe Sixpack (typical LFS audience). It *is* complicated and relatively few folks understand it. And finally, Alex, you should be more careful with what you write. Making wild and flagrant comments doesn't help anyone. You already have a reputation for jumping to (sometimes wrong) conclusions so please just put a little more thought into your postings. BTW, Alex, I would like to see from you a clear set of guidelines listing all the possible bugs and problems in the LFS LiveCD, even the ones you haven't discovered yet (just joking! :-) See? Hopefully now you'll realise how ridiculous one of your postings in this thread was. 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: jh-branch
Alexander E. Patrakov wrote: I'll wait for PPC results, and try to read the code of binutils in order to answer the x86-related question. ppc works. Hm. It looks like an inconsistency in your attitude to such problems. Huh? WTF does my attitude have to do with anything? Got some sort of axe to grind Alex? Dunno what your problem is dude, but I'm just trying to keep the build working and solve problems as they turn up. Remember, when we had the --as-needed problem from Fedora hosts, you did everything (i.e., -B/usr/bin) in order to prevent gcc/binutils mismatch. Why do you think that the current glibc/binutils situation is different? The most obvious difference is that the --as-needed thing highlighted a blatant problem with the build method. We were just lucky it worked up to that point. This current thing is not so clear cut. Another important difference is that GCC and Binutils are *much* more tightly coupled than any linker/libc scenario. That, and the fact the hash-style stuff was promoted as being compatible with older setups. Bottom line is I'm yet to be convinced this ld doesn't like host glibc thing is an issue for the build method as it appears to be an x86_64-only corner case. We already know a patch will resolve your problem, and we also know FSF binutils-2.18 is around the corner. But like I keep on saying, if you don't like the current build method you don't have to use it. Feel free to cross compile (and stop trolling). 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: jh-branch
Alexander E. Patrakov wrote: OK. However, I would like to see a simple and well-defined set of host requirements for a native build in the DIY reference build document, so that one knows where it is supposed to work and where it isn't. I.e., something that clearly judges the past --as-needed situation as a bug in the build method, the current ld doesn't like host glibc as a corner case, and gcc fails to bootstrap in Lenny x86 multilib setup and all cases starting from uclibc-based hosts as situations that are not going to be supported. Yeah I'd like to see it too, but it ain't gonna happen. Get a grip dude. This isn't a perfect world. Just step back for a moment and look at what you wrote. Whatever you want from me I can't give you. I do my best to help folks keep on building Linux systems but you clearly have some kind of underlying agenda. And I'll bet my bottom dollar it contains the words cross compile. Good luck. 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: jh-branch
Alexander E. Patrakov wrote:
GNU hash. Found it by creating several dummy shared libraries of my own:
Finally! Some technical details. Yay. However, my understanding is that
these hash-style changes are supposed to be back compatible.
echo foo(){} | gcc -fPIC -x c -m64 -shared -o foo.so -
echo foo(){} | gcc -Wl,--hash-style=gnu -fPIC -x c -m64 -shared -o
foo1.so -
echo foo(){} | gcc -Wl,--hash-style=sysv -fPIC -x c -m64 -shared -o
foo2.so -
(Debian defaults to --hash-style=both).
Yes, and so does upstream Glibc ie: Glibc will be built with
--hash-style=both if the binutils support it.
Of these libraries, the new ld recognizes only foo2.so. Is this enough
debugging?
No, not yet :-) If --hash-style=both is the problem, the build should fail
on x86 too? I just built a whole temptools phase with these versions:
gcc-4.1.2 / glibc-2.5.1 / fsf-binutils-2.17
from a host built with:
gcc-4.2.1 / glibc-2.6.1 / hjl-binutils-2.17.50.0.18 (glibc was compiled
with --hash-style=both)
and it built fine. ie: no problem linking against the host glibc.
Therefore the problem you are seeing is either a) not related to
--hash-style, b) is an x86_64 only problem or c) is a Debian only problem
Getting close dude.. but you ain't there yet... :-)
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: jh-branch
Alexander E. Patrakov wrote: The problem looks specific to x86_64. I can't reproduce it on Debian x86 (32-bit). Ok. If latest HJL binutils work, we can therefore conclude there was some x86_64 bugfix made after binitils-2.17. Mission - identify the fix, backport patch to 2.17, voila - problem solved! No need for ridiculously flippant declarations of build methods not working and being insufficient? Yes? 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: jh-branch
Alexander E. Patrakov wrote: Not sure that it is possible. Reason: binutils-2.17.50.0.2 don't support --hash-style=both and fail linking to Debian's glibc, while binutils-2.17.50.0.3 support --hash-style=both and work. So a bugfix is very likely to be just the addition of the GNU hash support. Indeed, the 2006-07-11 CVS checkout (timezone is Asia/Yekaterinburg) doesn't have GNU hash support and can't link anything against Debian's glibc, while 2006-07-12 works. The only difference between them is the addition of GNU hash. Interesting. But it doesn't explain why it works on x86. I'll test ppc and see what happens there. If this is not a Debian-only problem then I should be able to reproduce it on x86_64 later this week. Thus, a general solution should be created to the ld doesn't like host glibc type of problem, as opposed to the gnuhash-specific issue. You already have that solution and it's called cross compilation. But if it turns out that we have to backport the hash-style stuff to 2.17 for this apparent x86_64 corner case with the current build method, then so be it. It ain't ideal but there are already *much* larger patches in LFS introduced by your good self. 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: jh-branch
Alexander E. Patrakov wrote: I don't buy this explanation alone. The fact is that you can't build LFS (or DIY) with FSF binutils if you are on x86_64 and start from a new host such as Debian Lenny x86_64. The LFS/DIY build method is only meant to work on sane build hosts, ie: pure 32, pure 64, etc. No multilib, no multi-arch, no bizarro crazy arse setups. It's horses for courses dude. One side note: CLFS works even in this downgrade scenario - so maybe we should declare the LFS/DIY native build technique non-working and insufficient for stable releases (because they are more than likely to face this downgrade problem), and abandon it (or somehow modify it so that it begins to work in this scenario)? Oh great, Alex is now back to his old FUD-flinging best. Jeez man, how about you stop your whining and actually explain the real problem by actually debugging it? Maybe if you stop trolling we might be able to help? I repeat, if you want to build from a not-so-simple build host then use cross compilation! 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: jh-branch
Alexander E. Patrakov wrote: An untested idea: build binutils-pass1 and gcc-pass1 as cross-tools (as explained in CLFS), cross-compile glibc as explained in CLFS, build native-to-new-glibc binutils and gcc using our cross-tools, and continue with the native method. This way (if this happens to work), we won't rely on compatibility of anything we build with the host's glibc, and will still be able to use the advantage that we can run the compiled binaries. FWIW, If I were to design a pseudo-native build method based on cross compilation that is exactly how I'd attempt to do it. 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: jh-branch
Alexander E. Patrakov wrote: 1) FSF binutils 2.17 don't recognize 64-bit libc.so.6 on Debian Lenny x86_64 Yes, but why? This is the kind of debugging I'm talking about. We need to understand the technical details here and identify the root cause. Once the issue is understood, only then can we possibly figure out how to make the build work. I've only just finished my round of ppc builds (recall that I'm currently testing 5 toolchain combos on 3 arches - ugh, I must be insane). I plan to start on x86_64 some time next week. Hopefully the problem is reproducible on non-Debian setups. 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
Bootstrap times (was Re: [x86_64, herecy] Bootstrap gcc or not?)
Greg Schafer wrote: PS - According to my build logs, GCC-4.2 takes almost *double* the amount of time of GCC-4.1 for a 3-stage bootstrap. This doesn't matter much on a modern dual-core system (16m 45s vs 8m 41s) but it's very noticeable on an older ppc mac mini (91m vs 43m). So maybe there *is* merit in skipping the bootstrap after all? :-) But seriously, I suspect the reason is some extra checking is switched on in the stage1 4.2 compiler (I managed to hac^H^H^H switch it off in the 4.1 series). Will investigate... Ok, it appears the GCC devs conveniently added a new (undocumented?) configure switch in 4.2 `--disable-stage1-checking' which does the right thing. Times for GCC-4.2.1 bootstraps without and with the switch are below: real18m54.421s user32m55.131s sys 1m46.275s real13m0.254s user22m24.004s sys 1m47.959s Amount of time saved will obviously increase the slower the hardware. If bootstrap times are a concern then I would recommend LFS use this switch when upgrading to GCC-4.2.x. I'll be adding it to my Refbuild ASAP. 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: Bash test fix for su nobody
Dan Nicholson wrote: sed -i.bak '/THIS_SH/s,$, /dev/tty,' tests/run-test Seems more appropriate. I was trying to avoid another command, but it's the right thing to do. I'll try to push that in. I wanted to ask you about this, though. What's the reason you don't hit this in DIY? Actually, I do hit it, just not all the time. And no, I don't redirect /dev/null while building. A contributing factor seems to be whether the build is scripted or interactive. An LFS style build (as root) doesn't hit it when scripted but a Pacman based build (where everything is built unprivileged) does hit it. Kinda makes sense now that I think about it :-/ Anyhoo, hopefully this tweak will DTRT in all circumstances. 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: [x86_64, herecy] Bootstrap gcc or not?
Alexander E. Patrakov wrote: I was trying to find a way to build some LFS-like x86_64 system from Debian Lenny x86 (which has 32-bit userspace, a patched compiler that accepts -m64 to produce 64-bit binaries, some multilib setup, and an option to install a 64-bit kernel). Hmm, sounds like a bizarre setup.. Even then, the build failed with specs: invalid argument while bootstrapping gcc pass1. Any chance you could investigate this and find out the root cause? is it really true that bootstrapping gcc pass1 improves the range of hosts that are capable to build LFS? Huh? Where on earth did you get this crazy idea from? AFAIK no-one has ever suggested such a thing. But, for the purpose of compiling glibc and testsuite tools (and these the only things we compile with gcc pass1), we care only about the correct output. So even stage1 is good enough, so again - why bootstrap? It appears you've forgotten the basic rationale behind the GCC 3-stage bootstrap. As per the GCC docs, it ensures we are working with a compiler that can at least compile itself correctly. But having said that, I'd speculate there is enough redundancy in our overall 2-phase build method to take a shortcut and skip the bootstrap. Tho' personally, I'd never do it because I like to know immediately if the compiler can be trusted, rather than finding out too late down the track. But then again, I've only ever seen GCC snapshots fail the bootstrap (as opposed to release tarballs). In summary, I wouldn't call it heresy, but it certainly feels wrong, keeping in mind we are in effect *bootstrapping* a whole new Linux system every time we undertake a build. Regards Greg PS - According to my build logs, GCC-4.2 takes almost *double* the amount of time of GCC-4.1 for a 3-stage bootstrap. This doesn't matter much on a modern dual-core system (16m 45s vs 8m 41s) but it's very noticeable on an older ppc mac mini (91m vs 43m). So maybe there *is* merit in skipping the bootstrap after all? :-) But seriously, I suspect the reason is some extra checking is switched on in the stage1 4.2 compiler (I managed to hac^H^H^H switch it off in the 4.1 series). Will investigate... -- 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: Bash test fix for su nobody
Dan Nicholson wrote: A while back we changed the bash test suite to run as the nobody user because it enables more tests to be run. Ken and I have each had a pair of test failures building with 6.3-rc1. Looking closer, the test is checking whether `test -r /dev/stdin' and `test -r /dev/fd/0' return successfully. Ahh yes. We had a similar discussion back here: http://www.diy-linux.org/pipermail/diy-linux-dev/2006-August/000841.html These fail because permissions to the backing device (/dev/pts/0 in my case) are set up with 620 permissions, owned by dan:tty. This is host dependent, but I imagine it will fail more times than not when switching to the nobody user to run the test. One fix is basically to nullify the test by redirecting stdin to something that will definitely be readable, e.g. /dev/null. This is discussed here: http://linuxfromscratch.org/pipermail/lfs-dev/2007-August/059866.html I added a patch later in the thread: http://linuxfromscratch.org/pipermail/lfs-dev/2007-August/059877.html Sorry for not commenting earlier but I feel your fix is a little heavy handed. For something so critical as the shell test suite, ISTM redirecting stdin for the *whole test suite* could potentially skew results of other tests (not that I'm any expert on file descriptors). I think a more conservative approach would be to redirect stdin only for the test in question ie: `run-test'. I'll probably go with something like this if it tests out correctly: sed -i.bak '/THIS_SH/s,$, /dev/tty,' tests/run-test 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: Plans for LFS-6.3
Dan Nicholson wrote: I would like to allow glibc-2.5.1 through a freeze if it happens. That should be safe since we've been moving the snapshot along. New Glibc's are now up. 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: time for syslog-ng? (was Re: klogd)
Greg Schafer wrote: Indeed, but IMHO some of the Fedora rationale is questionable ie: dead upstream is not quite true. That is, if you can believe the sysklogd maintainer :-) http://lists.infodrom.org/infodrom-sysklogd/2007/0011.html A new release has been made after 6 years. Shock! sysklogd-1.5 is up on the download site. No release announcement yet that I could see. 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
