Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Mon, Jul 23, 2007 at 10:06:03PM -0500, Bruce Dubbs wrote: Randy McMurchy wrote: The other, iproute2-2.6.22-070710, is something we need to discuss. The problem is with the packaging. The package expands to the current directory. The issue is what to do. Here is what I see as the options: 1. Ignore the update for now. 2. Use our own repackaged version. 3. Add a note or other comments to to the iptables page Both Dan and I have written to the iptables maintainer and have not heard any response. Opinions? Anything that expands to the current directory is more aggravation than it's worth, so IMO 3 is right out. I'm not totally against the idea of repackaging it, but I am reluctant - particularly when we're close to a release. The changelog from the announcement on lwn has: David Lamparter (1): iproute2: Format IPv6 tunnels endpoints nicely. Mike Frysinger (1): ip/routef lifesaver Patrick McHardy (1): Fwd: Re: more iproute2 issues (not critical) Pavel Roskin (1): ip: add support for displaying link types 802 and 803 Stephen Hemminger (11): Revert Increase internal clock resolution to nsec Add xt_tcpudp.h incorrect initialization headers update to 2.6.22 fix last change fix build warnings netem: static Add TC_LIB_DIR environment variable. ss: fix issues with signed inodes Thomas Graf (2): iproute2: support for goto/nop action and detached flag iproute2: Support IFF_LOWER_UP and IFF_DORMANT Yasuyuki KOZAKAI (1): Fix symbolic link to tc-bfifo.8 jamal (2): SAD info SPD info Most of these mean nothing to me, the only one that sounds important is the ip/routef change. I guess this is from gentoo http://bugs.gentoo.org/show_bug.cgi?id=139853 - looks worthwhile, but not critical (the dates suggest it went upstream a year ago) so I vote for ignoring the update. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Ken Moffat wrote: ip/routef lifesaver This sounds fairly important, but I have no idea if it actually is... incorrect initialization Depending on whether this would get hit by any of our users, it may be important. Probably not critical though. headers update to 2.6.22 Might be nice, but in reality I think this is only helpful if you're trying to use bleeding-edge features, so probably not needed. Fix symbolic link to tc-bfifo.8 I believe there was some discussion on this symlink earlier. Probably not worth repackaging a whole new release just for this, though, since we have a workaround already (the fix dangling symlinks sed in chapter06/iproute2.xml). So I'd vote to keep the version we have now, too (for 6.3, of course). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGpd9iS5vET1Wea5wRA3BsAKDA0FaAChCbjgf0BNUxOen2USghGACgjLG3 VSnqCMQwqD9e/Od1LskNXk0= =uvJG -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote: Here's the results from what is currently in the branch: http://linuxfromscratch.org/~jhuntwork/test.log http://linuxfromscratch.org/~jhuntwork/search_dirs.log One last thing dude. Could you please advise exactly what host system you're using and also show the output of: ls -ld /l* BTW, I've reproduced the problem here and think I know what's going on. Just need to gather more info and perform some further 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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Mon, Jul 23, 2007 at 06:38:46PM +, Jeremy Huntwork wrote: Since the specs patch is already set up for pure64 and modifies the 64-bit linker to be in /tools/lib, I'm thinking to merge these small changes above to the pure64_specs patch and call it done. Any objections to that? The pure64 patch is usually thought to be needed in chapter 6 as well as pass 2 ;) ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Mon, Jul 23, 2007 at 10:34:45PM +0100, Ken Moffat wrote:
The pure64 patch is usually thought to be needed in chapter 6 as
well as pass 2 ;)
The problem I ran into is that the pure64 patch (at least the one I
found that's usable for gcc-4.1.1) won't apply once the specs patch has
been applied. I think both try to make dynamic linker changes to
linux{,64}.h. So I figured I'd roll up the needed changes from the
pure64 patch into the specs patch. That way we can just apply the specs
patch in gcc-pass2 and apply the pure64 patch in final gcc.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Mon, Jul 23, 2007 at 06:38:46PM +, Jeremy Huntwork wrote: MULTILIB_OPTIONS = m64/m32 MULTILIB_DIRNAMES = 64 32 -MULTILIB_OSDIRNAMES = ../lib64 ../lib +MULTILIB_OSDIRNAMES = ../lib ../lib32 And, I suppose if I'm going to be adding this to the specs patch, it would be safer to have the dirnames be /tools/lib and /tools/lib32 -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote:
Thanks. This was just an oversight. I meant to include the contents of the
pure64 patch for gcc pass2, but overlooked it due to the similarly named
pure64_specs patch. Here's what the pure64 patch would give us (Approximately.
The following is a faux diff due to line wrapping issues on my news client):
gcc-4.1.2.orig/gcc/config/i386/t-linux64
gcc-4.1.2/gcc/config/i386/t-linux64
MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64 32
-MULTILIB_OSDIRNAMES = ../lib64 ../lib
+MULTILIB_OSDIRNAMES = ../lib ../lib32
Since the specs patch is already set up for pure64 and modifies the 64-bit
linker to be in /tools/lib, I'm thinking to merge these small changes above to
the pure64_specs patch and call it done. Any objections to that?
Umm, you appear to have missed the point completely. Please re-read the
info I pointed to. MULTILIB_OSDIRNAMES needs to be *non-existent* to work
around the surprising (buggy?) GCC behavior I'm talking about.
Then again, I haven't tested x86_64 in a while so I might be talking out
of my arse. Preferably on an Ubuntu64 host, please post the verbose output
of gcc-pass2 so we can what is going on ie:
echo 'main(){}' | gcc -xc -o /dev/null -v -
Another point - To be honest, I don't see why any pure64 patch is needed
at all. That's what the symlinks are for. All the patch seems to do is
diverge the `x86_64 --disable-multilib' build further away from x86 than
is necessary.
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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Greg Schafer wrote:
Preferably on an Ubuntu64 host, please post the verbose output
of gcc-pass2 so we can what is going on ie:
echo 'main(){}' | gcc -xc -o /dev/null -v -
Actually, that may not be enough. Would also need to see the output of:
gcc -print-search-dirs | sed 's/:/\n/g'
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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Greg Schafer wrote:
Umm, you appear to have missed the point completely. Please re-read the
info I pointed to. MULTILIB_OSDIRNAMES needs to be *non-existent* to work
around the surprising (buggy?) GCC behavior I'm talking about.
I didn't miss the point, I understood all of what you wrote. I just
chose to test it differently.
Then again, I haven't tested x86_64 in a while so I might be talking out
of my arse. Preferably on an Ubuntu64 host, please post the verbose output
of gcc-pass2 so we can what is going on ie:
echo 'main(){}' | gcc -xc -o /dev/null -v -
I don't have an Ubuntu host to work from, but I will share the results
that I can. Have to fire off another build, so it might be a little bit.
Another point - To be honest, I don't see why any pure64 patch is needed
at all. That's what the symlinks are for. All the patch seems to do is
diverge the `x86_64 --disable-multilib' build further away from x86 than
is necessary.
Well, you may be right. But before I make any futher changes, I'd like
to get some feedback on this from others in the LFS community about it.
Greg, care to explain in more detail the {dis,}advantages of the
symlinks a bit more?
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote:
Greg, care to explain in more detail the {dis,}advantages of the
symlinks a bit more?
Dude, it's fairly simple. The symlinks keep the `-disable-multilib' build
very much compatible with x86 ie: very little changes are required, and
this is a *MASSIVE* maintenance advantage. Also, as mentioned elsewhere in
this thread, LSB binaries (those with interpreter path
/lib64/ld-linux-x86-64.so.2) will work. I don't buy your argument about
symlinks being less robust.. neither does Ubuntu.. rescue CD's exist for a
reason you know :-)
I thought you were trying to adapt the current LFS/DIY *native* build
method to non-multilib x86_64 (similar to what I've done in the DIY
Refbuild). None of the CLFS gunk you're currently adding is needed. If
you're going to borrow bits of CLFS stuff then IMHO you may as well just
forget the whole thing and point folks to CLFS.
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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Greg Schafer wrote these words on 07/23/07 20:44 CST: None of the CLFS gunk you're currently adding is needed. If you're going to borrow bits of CLFS stuff then IMHO you may as well just forget the whole thing and point folks to CLFS. I ditto these sentiments. Jeez, Jeremy, why invent the wheel? Besides, wouldn't your efforts be better spent getting LFS-6.3 out the door, instead of trying to incorporate into LFS (the hard way) what everyone has access to using already discovered methodology? Just my opinion. Don't answer the question, nor comment if there's nothing to be gained technically. We all appreciate your quest for knowledge. Just not at the expense of putting into LFS what is already out there, with your deviations. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 21:04:00 up 11 days, 14:11, 1 user, load average: 0.10, 0.04, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Greg Schafer wrote: Dude, it's fairly simple. I'm not sure if you meant to sound condescending here; I'll give you the benefit of the doubt and assume you didn't. It does appear, however, that you missed the point of my request. I wasn't asking you to explain to me your method; I get it. I was asking you to present the options to the community in order to foster discussion. The symlinks keep the `-disable-multilib' build very much compatible with x86 ie: very little changes are required, and this is a *MASSIVE* maintenance advantage. Also, as mentioned elsewhere in this thread, LSB binaries (those with interpreter path /lib64/ld-linux-x86-64.so.2) will work. Thank you, this is what I was after. I don't buy your argument about symlinks being less robust.. neither does Ubuntu.. rescue CD's exist for a reason you know :-) I simply presented it as something to consider... I thought you were trying to adapt the current LFS/DIY *native* build method to non-multilib x86_64 (similar to what I've done in the DIY Refbuild). None of the CLFS gunk you're currently adding is needed. If you're going to borrow bits of CLFS stuff then IMHO you may as well just forget the whole thing and point folks to CLFS. Well the same could be said for adding material borrowed from DIY. 'Might as well just point the users to DIY-Linux'. The 'gunk' that you've mentioned is just one patch to GCC and two possible commands added to Glibc. And as was already mentioned, even that could be removed. It would just require that we alter the text that is shown from the gcc tests. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Randy McMurchy wrote: I ditto these sentiments. Jeez, Jeremy, why invent the wheel? Actually, I was trying to avoid that. The simple fact is that I rarely consult DIY. For reference, I looked at what I was already familiar with: CLFS. I didn't even remember that DIY had a native x86_64 build until after I already started my edits on my working copy. If there's a better method (one that is a closer fit to what we want to achieve in LFS) from DIY, great. Let's use it. Besides, wouldn't your efforts be better spent getting LFS-6.3 out the door, instead of trying to incorporate into LFS (the hard way) what everyone has access to using already discovered methodology? [snip] Just my opinion. Don't answer the question, nor comment if there's nothing to be gained technically. If there's nothing to be gained technically, why ask the question? knowledge. Just not at the expense of putting into LFS what is already out there, with your deviations. That's what bringing x86_64 into LFS would be - adding what has already been done with deviations appropriate for our BOOK/community. I'm not at all trying to make this about me, so it's not *my* deviations. The only reason I was the one to create the branch and start dropping in changes is because I was hoping to create a full 64-bit LiveCD. It would be very useful to me personally and at work, and we've had a few requests for such a CD on the livecd list. Am I free to use my time in that manner? BTW, how does this happen? How does it work out that I get attacked for my efforts? I created a branch *specifically* as an out of the way place where if I mess it up, no harm is done. I freely admit through all of my messages and commits that there may be errors to what is there. I ask for suggestions, and I try to show that I'm open to other methods and am willing to adjust. And yet people blast me for what I'm doing? What gives? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Randy McMurchy wrote: Besides, wouldn't your efforts be better spent getting LFS-6.3 out the door Jeremy is getting a head start on a potential LFS-7.0. I am about to cut a lfs-6.3-rc1. Right now there are two outstanding tickets. One, man-pages-2.63, it pretty trivial and I'll make that change in a few minutes. The other, iproute2-2.6.22-070710, is something we need to discuss. The problem is with the packaging. The package expands to the current directory. The issue is what to do. Here is what I see as the options: 1. Ignore the update for now. 2. Use our own repackaged version. 3. Add a note or other comments to to the iptables page Both Dan and I have written to the iptables maintainer and have not heard any response. Opinions? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Bruce Dubbs wrote: 1. Ignore the update for now. 2. Use our own repackaged version. 3. Add a note or other comments to to the iptables page I'd opt for either 1 or 2. If we did number 3, I'm sure many people would see the message after they've already unpacked it. What's included in the update? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Greg Schafer wrote:
Greg Schafer wrote:
Preferably on an Ubuntu64 host, please post the verbose output
of gcc-pass2 so we can what is going on ie:
echo 'main(){}' | gcc -xc -o /dev/null -v -
Actually, that may not be enough. Would also need to see the output of:
gcc -print-search-dirs | sed 's/:/\n/g'
Here's the results from what is currently in the branch:
http://linuxfromscratch.org/~jhuntwork/test.log
http://linuxfromscratch.org/~jhuntwork/search_dirs.log
It does seem that there are still locations in /usr showing up in the
search dirs. They are later in the list, but still, it seems the
potential is there to pull in unwanted libs from the host.
Going to be adjusting the build again. It will end up being more DIY-like.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote these words on 07/23/07 13:51 CST: And yet people blast me for what I'm doing? What gives? You are too sensitive. I've not seen anyone blast you. I've only seen people be critical of the ideas you have. That is okay. This is a discussion forum where folks are expected to give their opinions on things. You take it personally, and you shouldn't. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 22:03:00 up 11 days, 15:10, 1 user, load average: 0.20, 0.05, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Randy McMurchy wrote: You are too sensitive. Yes, you're probably right. :/ -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Bruce Dubbs wrote these words on 07/23/07 22:06 CST: The other, iproute2-2.6.22-070710, is something we need to discuss. The problem is with the packaging. The package expands to the current directory. The issue is what to do. Here is what I see as the options: 1. Ignore the update for now. 2. Use our own repackaged version. 3. Add a note or other comments to to the iptables page Both Dan and I have written to the iptables maintainer and have not heard any response. Not sure what the iptables maintainer has to do with an issue with the iproute package, but I'm guessing this a typographic error. However, if the current update in the iproute package sucks and doesn't perform to our expectations, then blow it off. What is in the book works. That means I vote for #1. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 22:24:00 up 11 days, 15:31, 1 user, load average: 0.15, 0.17, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote: It does seem that there are still locations in /usr showing up in the search dirs. They are later in the list, but still, it seems the potential is there to pull in unwanted libs from the host. Actually, they show up on x86 too so they're not the problem. The specific problem I'm referring to was about GCC adding -L/lib/../lib64 entries when it shouldn't have... Aha, it's all starting to come back to me now.. the confusing thing was ../lib64 didn't show up in the -print-search-dirs output (which BTW, I think is fixed in GCC-4.2 or 4.3) and this made it hard to figure out the problem. Anyhoo, thanks for the logs but I don't think they're going to help.. oops. I'll try and come up with a simple testcase which will hopefully clarify it. Gimme a few days to get my x86_64 house in order.. 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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Luca wrote: Grub-0.9x is old Grub legacy and no-more maintained. According to their site, it is maintained, just no new features are being added. (Though I'm not sure what sense of the word maintained they're using then... but whatever. Presumably it just means they'd still fix bugs if there are any.) Grub-1.x is new one [...] I tried it only x86 but there was a similar discussion in Debian for x86-64 arch support. Here's where I'm a bit confused. Why should grub need to switch the processor into long mode? For one, the kernel already does that -- IIRC, Linux expects to start in real mode. (I'm not sure if there are any provisions to start in protected mode, for grub2, or not. I'm pretty sure grub2 switches into protected mode, so if that's true and it works, then there probably is some protocol to make it work.) But for two, isn't 4G of virtual address space way more than enough for grub to do whatever it needs to do? I mean, all it has to do is load up a file or two off the host FS and jump to an address inside the memory image of one of the files. That's not nearly complicated enough to require more than 4G of memory. In short, I'm not sure the bootloader needs to be 64-bit. Now I can see making the grub shell (and other programs on the host) be 64-bit. Even if that's way overkill IMO too, it would be necessary if you're trying to do a pure64 system (because you won't have the 32-bit ld.so). Is that all that's being discussed when people talk about x86-64 arch support? (Not that a pure64 system is all that useful if you need -- or want -- to use Flash, but that's a different issue.) In any case, I had planned on doing some grub2 testing today, so hopefully I'll be able to get it to work. I really do need to make and test a bootable floppy first, though. :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGogDjS5vET1Wea5wRAzYdAKC4LsfvxS8vEO6jNsH8tYNJDiKmPACfULGA BrlI1fZyDJ8IiIHHwBdOoyQ= =Xjqk -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Bryan Kadzban wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Luca wrote: Grub-0.9x is old Grub legacy and no-more maintained. According to their site, it is maintained, just no new features are being added. (Though I'm not sure what sense of the word maintained they're using then... but whatever. Presumably it just means they'd still fix bugs if there are any.) Grub-1.x is new one [...] I tried it only x86 but there was a similar discussion in Debian for x86-64 arch support. Here's where I'm a bit confused. Why should grub need to switch the processor into long mode? For one, the kernel already does that -- IIRC, Linux expects to start in real mode. (I'm not sure if there are any provisions to start in protected mode, for grub2, or not. I'm pretty sure grub2 switches into protected mode, so if that's true and it works, then there probably is some protocol to make it work.) Grub legacy sets up protected mode. Yes, the linux kernel can startup in protected mode, but any kernel that grub loads needs to setup protected mode. If the kernel doesn't setup protected modem you have the possibility of a triple fault (reboot). Grub sets up a GDT. If the kernel being loaded by grub overwrites the GDT created by grub before setting up one of it's own you'll get a triple fault. I learned that the hard way. But for two, isn't 4G of virtual address space way more than enough for grub to do whatever it needs to do? I mean, all it has to do is load up a file or two off the host FS and jump to an address inside the memory image of one of the files. That's not nearly complicated enough to require more than 4G of memory. Without setting up protected mode you can't access more then 1mb of physical memory, without pulling your hair out. In short, I'm not sure the bootloader needs to be 64-bit. Now I can see making the grub shell (and other programs on the host) be 64-bit. Even if that's way overkill IMO too, it would be necessary if you're trying to do a pure64 system (because you won't have the 32-bit ld.so). Is that all that's being discussed when people talk about x86-64 arch support? The bootloader doesn't need to be 64bit, actually, 32bit would be ideal. The problem with grub legacy is that stage2 gets linked into the grub shell. stage2 can be compiled as a 32bit binary. But the grub shell would need to be 64bit, specifically because it requires a 64bit libc and optionally a 64bit libncurses (Can use a text interface). Grub legacy's design makes it virtually impossible to use on 64bit. (Not that a pure64 system is all that useful if you need -- or want -- to use Flash, but that's a different issue.) In any case, I had planned on doing some grub2 testing today, so hopefully I'll be able to get it to work. I really do need to make and test a bootable floppy first, though. :-) Grub2 should be able to work. I just compiled 1.95 with 64bit binaries and 32bit modules. Now all I would like to do is compile a pure64 system and try this. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
- Original Message -
From: Bryan Kadzban [EMAIL PROTECTED]
To: LFS Developers Mailinglist lfs-dev@linuxfromscratch.org
Sent: Saturday, July 21, 2007 2:49 PM
Subject: Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
According to their site, it is maintained, just no new features are
being added. (Though I'm not sure what sense of the word maintained
they're using then... but whatever. Presumably it just means they'd
still fix bugs if there are any.)
Hello Bryan.
I used maintained simply according to your words: only fixes but dead
for all the rest.
Happy testing :)
Luca
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Bryan Kadzban wrote: Right. (Actually I'm not sure you can access more than 1MB of memory even if you *do* pull your hair out. The memory model is 16-bit segments and 16-bit offsets, but the physical address mapping is shift the segment number by 4 bits and add the offset -- so the maximum physical memory is 20 bits' worth, or 1MB. Although I'm not exactly sure what happens when you try to access :0010. Physical address zero? Overflow bit turned on in EFLAGS? Hard lockup? :-P) It's called extended (not expanded) memory. This was a way to access 1M + 64K - 16 of memory. It is my understanding that many systems use the hardware's BIOS, which is always customized for the specific hardware of the motherboard, to copy from real address space ( 1M ) to protected address space 1M. If you look at the detail of the kernel code that starts exactly at the 1M address point. It starts in real mode. It transitions to protected mode, uncompresses the kernel to just above the compressed image, jumps to some very small piece of copy code, copies the uncompressed kernel back to 1M and then jumps back to 1M where the kernel starts initializing hardware, memory structures, etc. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote: On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote: LFS could be made to accommodate x86_64 (multilib) with very few changes and a bunch of new pages. Where multilib gets tricky is where lfs stops and blfs begins. With the introduction of pkg-config and all those fun *-config programs and hard coded library paths. And non-multilib is even fewer changes, and would be much easier for BLFS to accomodate. I suppose the only concern is compliance with standards and/or user expectations. I'm working on getting a LFS-style native build done on x86_64 with as few changes as possible. I'll let you know how it goes. There is even a bigger problem with non-multilib builds. The way clfs does it, all the 64bit libs go into /lib and such. FHS specifies ld.so for 64bit x86_64 to be at /lib64/ld-linux-x86_64.so.2. If ld.so is in /lib, all those nice 64 binary packages need to be modified or a compatibility symlink has to be put in place. Plus a 64bit build will be incapeable of running 32bit binaries, unless 32lib libraries are put on the system somewhere, and /lib/ld-linux.so.2 knows where to look for them. You can have /lib64/ld-linux-x86_64.so.2 (symlink to /lib), /lib/ld-linux.so.2 (32bit), and /lib/ld-linux-x86_64.so.2 (64bit). Your 64bit libs in /lib. and your 32bit libs in /lib32 or some weird place lib /opt/emul_32/lib. A hint about using /opt/emul_32/lib for the specific purpose of running wine could definitely be written up. That would be useful for clfs too. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Fri, Jul 20, 2007 at 12:45:37PM -0400, Joe Ciccone wrote: There is even a bigger problem with non-multilib builds. The way clfs does it, all the 64bit libs go into /lib and such. FHS specifies ld.so for 64bit x86_64 to be at /lib64/ld-linux-x86_64.so.2. If ld.so is in /lib, all those nice 64 binary packages need to be modified or a compatibility symlink has to be put in place. Plus a 64bit build will be incapeable of running 32bit binaries, unless 32lib libraries are put on the system somewhere, and /lib/ld-linux.so.2 knows where to look for them. all those nice 64 binary packages - I suppose that means nvidia or ati kernel modules ? I don't know of anything else that comes as 64-bit without source. Yeah, if people want to run binaries, they do need a multilib build. Personally, I'd rather have the discussion about where LFS should be going _after_ the holiday season. Hey, gcc-4.2 might even be working on ppc64 in clfs by then - although I doubt it ;) ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On 7/20/07, Joe Ciccone [EMAIL PROTECTED] wrote: Jeremy Huntwork wrote: On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote: LFS could be made to accommodate x86_64 (multilib) with very few changes and a bunch of new pages. Where multilib gets tricky is where lfs stops and blfs begins. With the introduction of pkg-config and all those fun *-config programs and hard coded library paths. And non-multilib is even fewer changes, and would be much easier for BLFS to accomodate. I suppose the only concern is compliance with standards and/or user expectations. I'm working on getting a LFS-style native build done on x86_64 with as few changes as possible. I'll let you know how it goes. There is even a bigger problem with non-multilib builds. The way clfs does it, all the 64bit libs go into /lib and such. FHS specifies ld.so for 64bit x86_64 to be at /lib64/ld-linux-x86_64.so.2. If ld.so is in /lib, all those nice 64 binary packages need to be modified or a compatibility symlink has to be put in place. Plus a 64bit build will be incapeable of running 32bit binaries, unless 32lib libraries are put on the system somewhere, and /lib/ld-linux.so.2 knows where to look for them. You can have /lib64/ld-linux-x86_64.so.2 (symlink to /lib), /lib/ld-linux.so.2 (32bit), and /lib/ld-linux-x86_64.so.2 (64bit). Your 64bit libs in /lib. and your 32bit libs in /lib32 or some weird place lib /opt/emul_32/lib. A hint about using /opt/emul_32/lib for the specific purpose of running wine could definitely be written up. That would be useful for clfs too. Thanks for the info. I think just to get started on handling multiple arches in LFS, we should focus on non-multilib 64 and just symlink /lib - /lib64. Hopefully it doesn't bite elsewhere, but I think it's the fastest way to get up and running. Multilib is definitely the way to go, but I think it's more important to just get a 64 bit build in before handling the much larger case. Then again, I haven't done anything, so this is just speculation. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Fri, Jul 20, 2007 at 11:38:30AM -0700, Dan Nicholson wrote: Thanks for the info. I think just to get started on handling multiple arches in LFS, we should focus on non-multilib 64 and just symlink /lib - /lib64. Hopefully it doesn't bite elsewhere, but I think it's the fastest way to get up and running. Multilib is definitely the way to go, but I think it's more important to just get a 64 bit build in before handling the much larger case. Then again, I haven't done anything, so this is just speculation. Agreed. I believe I have the necessary changes worked through in a working copy of the x86_64 branch I made the other day. Due to time constraints I haven't been able to finish a full build, but I believe what is there will work. I do plan on testing it fully before I commit any changes, but I figured I'd show what I have and give someone else the opportunity to build it if they like and/or look for any obvious errors. Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 And here's the current diff (so you can see the changes in a glance): http://linuxfromscratch.org/~jhuntwork/x86_64-changes.diff The two gcc pure64 patches come from CLFS. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote: On Fri, Jul 20, 2007 at 11:38:30AM -0700, Dan Nicholson wrote: Thanks for the info. I think just to get started on handling multiple arches in LFS, we should focus on non-multilib 64 and just symlink /lib - /lib64. Hopefully it doesn't bite elsewhere, but I think it's the fastest way to get up and running. Multilib is definitely the way to go, but I think it's more important to just get a 64 bit build in before handling the much larger case. Then again, I haven't done anything, so this is just speculation. Agreed. I believe I have the necessary changes worked through in a working copy of the x86_64 branch I made the other day. Due to time constraints I haven't been able to finish a full build, but I believe what is there will work. I do plan on testing it fully before I commit any changes, but I figured I'd show what I have and give someone else the opportunity to build it if they like and/or look for any obvious errors. Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 Should we add lfs-x86_64 to to jhalfs now or wait a few weeks/months? I assume there will be a multi-lib version after all objections/ideas have been aired. (planning ahead for jhalfs) And here's the current diff (so you can see the changes in a glance): http://linuxfromscratch.org/~jhuntwork/x86_64-changes.diff The two gcc pure64 patches come from CLFS. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
El Viernes, 20 de Julio de 2007 22:29, George Boudreau escribió: Should we add lfs-x86_64 to to jhalfs now or wait a few weeks/months? I assume there will be a multi-lib version after all objections/ideas have been aired. (planning ahead for jhalfs) Depends on how the changes are applied in the branch. If the branch will contains only x86_64 pure64 libs commands for now (i.e. replacing the needed x86 trunk commands by the ones for pure64), current jhalfs should work fine. If we start merging directly the new pure64 command/packages with the current x86 ones using XSL profiles to generate separate books, then jhalfs will need be updated to can handle such profiles in a similar way than HLFS do. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote: Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 You have correctly dropped grub from the list of packages (nobody has managed to build it successfully on a pure64 system), but it's still referenced in Chapter 8 - Making the LFS System Bootable. A slightly bigger problem might be that you don't seem to have a replacement for it. ĸen, trying not to use the 'l' word because it usually leads to flame-wars ;-) -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Fri, Jul 20, 2007 at 09:51:48PM +0100, Ken Moffat wrote: A slightly bigger problem might be that you don't seem to have a replacement for it. Indeed. I meant to drop something in, but forgot about it. bin86/lilo would probably be alright. Anyone tried grub2? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Fri, Jul 20, 2007 at 10:47:16PM +0200, M.Canales.es wrote: Depends on how the changes are applied in the branch. If the branch will contains only x86_64 pure64 libs commands for now (i.e. replacing the needed x86 trunk commands by the ones for pure64), current jhalfs should work fine. If we start merging directly the new pure64 command/packages with the current x86 ones using XSL profiles to generate separate books, then jhalfs will need be updated to can handle such profiles in a similar way than HLFS do. And for these reasons I vote to wait wrt adjusting jhalfs. Let's see where this will go - and for now, I believe current jhalfs will build the new branch. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On 7/20/07, Ken Moffat [EMAIL PROTECTED] wrote: On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote: Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 You have correctly dropped grub from the list of packages (nobody has managed to build it successfully on a pure64 system), but it's still referenced in Chapter 8 - Making the LFS System Bootable. The 1.9.x versions, too? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
El Viernes, 20 de Julio de 2007 22:54, Jeremy Huntwork escribió: Indeed. I meant to drop something in, but forgot about it. bin86/lilo would probably be alright. Anyone tried grub2? IMHO, for now lilo should be used due that the build commands could be copied from CLFS. For the future, see Alexander comment on http://wiki.linuxfromscratch.org/lfs/ticket/1955 -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Fri, Jul 20, 2007 at 02:06:00PM -0700, Dan Nicholson wrote: On 7/20/07, Ken Moffat [EMAIL PROTECTED] wrote: On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote: Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 You have correctly dropped grub from the list of packages (nobody has managed to build it successfully on a pure64 system), but it's still referenced in Chapter 8 - Making the LFS System Bootable. The 1.9.x versions, too? No idea - playing with experimental bootloaders scares the crap out of me. I got yaboot building with a natively 64-bit gcc last year, I'm hoping not to touch anything in that line this year ;) ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Dan Nicholson wrote: On 7/20/07, Ken Moffat [EMAIL PROTECTED] wrote: On Fri, Jul 20, 2007 at 01:29:20PM -0600, Jeremy Huntwork wrote: Here's the rendered book: http://linuxfromscratch.org/~jhuntwork/lfs-x86_64 You have correctly dropped grub from the list of packages (nobody has managed to build it successfully on a pure64 system), but it's still referenced in Chapter 8 - Making the LFS System Bootable. The 1.9.x versions, too? I'll have to check on the more recent versions. I know that 1.9.2 (the last time I tried) still needed a 32bit glibc. I don't have a pure64 build around but I think the new one (1.9.5) may work. grub2 is a completely different beast then grub legacy. Still no documentation. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Ken Moffat wrote: all those nice 64 binary packages - I suppose that means nvidia or ati kernel modules ? I don't know of anything else that comes as 64-bit without source. I know a few people use Opera too. I personally use a binary JDK if I need java. If someone wanted to use a binary firefox / seamonkey / thunderbird they'd fall in that group. It is definitaly a small group of people that would need that functionality, but it still exists. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Jeremy Huntwork wrote: but I figured I'd show what I have and give someone else the opportunity to build it if they like and/or look for any obvious errors. It appears you haven't allowed for a surprising gotcha that means GCC-Pass2 will search for libs on the host thus rendering the build method ineffective. This (and the fix) is all documented in the DIY Refbuild. More info here: http://www.diy-linux.org/pipermail/diy-linux-dev/2006-September/000871.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: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On 7/20/07, Joe Ciccone [EMAIL PROTECTED] wrote: Dan Nicholson wrote: The 1.9.x versions, too? I'll have to check on the more recent versions. I know that 1.9.2 (the last time I tried) still needed a 32bit glibc. I don't have a pure64 build around but I think the new one (1.9.5) may work. grub2 is a completely different beast then grub legacy. Still no documentation. Well, I had a look at the 1.9.5 version, and it looks like configure is forcing 32bit for target_cpu=x86_64. So, I'd say probably not. http://cvs.savannah.gnu.org/viewvc/grub2/configure.ac?root=grubview=markup -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Fri, Jul 20, 2007 at 07:10:59PM -0400, Joe Ciccone wrote: Ken Moffat wrote: all those nice 64 binary packages - I suppose that means nvidia or ati kernel modules ? I don't know of anything else that comes as 64-bit without source. I know a few people use Opera too. I personally use a binary JDK if I need java. If someone wanted to use a binary firefox / seamonkey / thunderbird they'd fall in that group. It is definitaly a small group of people that would need that functionality, but it still exists. I'll give you java, so I have to accept there are binary 64-bit applications. But I can't find any 64-bit binaries for firefox or opera. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Ken Moffat wrote: I'll give you java, so I have to accept there are binary 64-bit applications. But I can't find any 64-bit binaries for firefox or opera. I could have sworn they existed but I just checked and couldn't find them either. So strike two more off the list. That still leaves java. Which is a major one. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
- Original Message -
From: Jeremy Huntwork [EMAIL PROTECTED]
To: LFS Developers Mailinglist lfs-dev@linuxfromscratch.org
Sent: Friday, July 20, 2007 10:54 PM
Subject: Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Indeed. I meant to drop something in, but forgot about it. bin86/lilo
would probably be alright. Anyone tried grub2?
Hello.
Grub-0.9x is old Grub legacy and no-more maintained.
Grub-1.x is new one (latest I tried was 1.95, release 2006-10-15) but
it's still experimental and doesn't support all file-systems features
(xfs btrees aren't supported as example) but it will support much
file-systems than old one; I tried it only x86 but there was a similar
discussion in Debian for x86-64 arch support.
Supported archs are: PC (i386), Mac (powerpc), Pegasos II (powerpc),
Sparc v9 (Sun UltraSparc) - under development, Mac (i386) - under
development.
Supported file-systems: ext2, fat (+ long filenames), ufs (versions 1
and 2), minix (versions 1 and 2), iso9660 (plus rockridge extensions),
jfs, hfs, affs, sfs, xfs (no btrees).
Supported loaders: PC (chainloader, linux, multiboot), Mac (linux).
Terminals: PC (VGA framebuffer, textmode, VESA framebuffer - in
progress), PPC UltraSparc ( ANSI - Open Firmware).
Partition maps: standard pc and extended partitions, BSD partitions,
Macintosh partitions, Amiga style partitions (RDB), Sun partitions, GPT
(used by EFI).
Features: memory management, module loading, font support (framebuffer
only), grub-emu (testing/debugging), argument parsing interface,
rescue/normal mode, variable support, compression support, command
history/tab completion (normal mode), scripting.
Anyway you can find more on the GRUB Wiki - http://grub.enbug.org/ -
under GRUB 2.
Regards,
Luca
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Gerard Beekmans wrote: A few people have already expressed the fact that platforms like x86_64 are becoming more and more standard. We simply have to keep up with the times. Adopting some/all of CLFS' methods into mainstream LFS will happen sooner or later. Back in the day, LFS' chapter 5 made allowances for systems based on a (very) old Glibc that wasn't compatible with the newer Glibc LFS was installing. Along that same vein sooner or later we'll have to add similar workarounds if one wants to end up with a 64 bit build. Or it will end up in an LFS Hint. Or we'll defer completely to CLFS. LFS could be made to accommodate x86_64 (multilib) with very few changes and a bunch of new pages. Where multilib gets tricky is where lfs stops and blfs begins. With the introduction of pkg-config and all those fun *-config programs and hard coded library paths. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Thu, Jul 19, 2007 at 09:59:31PM -0400, Joe Ciccone wrote: LFS could be made to accommodate x86_64 (multilib) with very few changes and a bunch of new pages. Where multilib gets tricky is where lfs stops and blfs begins. With the introduction of pkg-config and all those fun *-config programs and hard coded library paths. And non-multilib is even fewer changes, and would be much easier for BLFS to accomodate. I suppose the only concern is compliance with standards and/or user expectations. I'm working on getting a LFS-style native build done on x86_64 with as few changes as possible. I'll let you know how it goes. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Tue, 17 Jul 2007 17:36:40 -0600, Gerard Beekmans wrote: Or it will end up in an LFS Hint. Or we'll defer completely to CLFS. Long live pureLFS! When I was first introduced to CLFS it was indicated that some people indeed anticipated that, eventually, the cross method would become The Book. I had a few months to look at it before the last bombshell completely took out my base (think the first release of Red Alert). I didn't see anything, from a user's perspective, so extraordinarily advanced in it that made me think that it wouldn't become The Book. I can somewhat see how the CLFS method may be a bit harder on the devs to maintain but, if everything does finally merge together again, then it'll smooth itself out over time. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
I agree with those statements, Craig. Every now and then the old past still rears its ugly head. A few things happened that hurt a number of people (professional and personal pride) and those things are typically hard to get over. I, too, have always thought it to be a good idea to merge CLFS with the rest of LFS in some way. The CLFS fork, as some call it, will hopefully come to an end. It's not exactly a true fork (at least IMO, which isn't shared by everybody) and I don't think it will be impossible to put an end to it, when the time is right. It'll probably upset a few more people in the merger, but hopefully it can be done with everybody agreeing that it's a logical next thing to do for LFS. A few people have already expressed the fact that platforms like x86_64 are becoming more and more standard. We simply have to keep up with the times. Adopting some/all of CLFS' methods into mainstream LFS will happen sooner or later. Back in the day, LFS' chapter 5 made allowances for systems based on a (very) old Glibc that wasn't compatible with the newer Glibc LFS was installing. Along that same vein sooner or later we'll have to add similar workarounds if one wants to end up with a 64 bit build. Or it will end up in an LFS Hint. Or we'll defer completely to CLFS. At any rate, you can see the trend developing. One day we'll get over this hump and put all of this behind. But first are summer holidays. I imagine lots of us will be gone (myself included starting end of next week) so this probably isn't the right time to start an in-depth discussion with people not paying attention anymore or entire gone. I'll leave it at that before this becomes a lengthy brain dump. Comments always welcome of course -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
On Tue, Jul 17, 2007 at 05:36:40PM -0600, Gerard Beekmans wrote: But first are summer holidays. I imagine lots of us will be gone (myself included starting end of next week) so this probably isn't the right time to start an in-depth discussion with people not paying attention anymore or entire gone. /me looks forward to an extensive discussion in the future. Maybe by that time I'll have clarified my thoughts on x86_64 (at the moment, I prefer a single library, _except_ when I prefer multilib ;) Enjoy your holiday. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
{B,C}LFS State of Things (was Re: SVN-20070706: ...)
Craig Jackson wrote these words on 07/13/07 18:02 CST: I don't know how to say this delicately, so I will just say it. And being one that appreciates such candor, I applaud your message. It seems futile for me to attempt to test for LFS for the simple fact that the x86 architecture's days are limited. You can barely buy a new system off the retail shelf that isn't at least a single-core athlon64. I am very curious where the efforts will change with regard to the very dedicated LFS developers. Do you have any plans to eventually begin work on CLFS when the time is right? This should not spark a flame war, you make a very concise and to the point statement/question that deserves discussion. However, the CLFS fork was mostly due to some dev's dissatisfaction with the decisions that were made a *long* time ago. It's my belief there is still animosity. I have thought about this many, many times. To the point of sending private emails to some of the CLFS devs/major users. *All* of them that I contacted have said that a merge or even an attempt at a merge of our (LFS/BLFS devs) efforts with the CLFS team would never work, or even be contemplated. That said, for (B)LFS devs who weren't envited to join CLFS, they will never be able to, if what I've been told is true. Recently, I've been away from the project, some of it due to the fact that I'm using 64 bit arch's and my work on these platforms is now of no value to BLFS, nor am I able to contribute meaningfully to CLFS. Yes, I agree the (B)LFS days are limited. I've been trying to get the BLFS book somewhat up to date in the last couple of weeks, as I believe there's still a niche out there. x86 archs will be in use for some time to come in various capacities, especially in dedicated server use. You ask if there are any plans to eventually begin work on CLFS when the time is right. Unfortunately, I don't believe it is an option at this point. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 18:17:00 up 1 day, 11:24, 1 user, load average: 0.06, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
Randy McMurchy wrote: This should not spark a flame war, you make a very concise and to the point statement/question that deserves discussion. However, the CLFS fork was mostly due to some dev's dissatisfaction with the decisions that were made a *long* time ago. It's my belief there is still animosity. What animosity, CLFS is not a fork, we are a different form of LFS. If you consider us running our own website and servers a fork, I guess we are one. But this was all authorized by Gerard. I have thought about this many, many times. To the point of sending private emails to some of the CLFS devs/major users. *All* of them that I contacted have said that a merge or even an attempt at a merge of our (LFS/BLFS devs) efforts with the CLFS team would never work, or even be contemplated. The one thing everyone has stated Randy, is our methodologies are different, LFS caters to x86 processors, CLFS caters to more than just x86. Everything after the cross-tools, and tools chapters are almost exactly the same. Except for the udev and bootscripts package. That said, for (B)LFS devs who weren't envited to join CLFS, they will never be able to, if what I've been told is true. Recently, I've been away from the project, some of it due to the fact that I'm using 64 bit arch's and my work on these platforms is now of no value to BLFS, nor am I able to contribute meaningfully to CLFS. Randy, CLFS has an open door development policy. No one is limited. All you have do is contribute. Yes, I agree the (B)LFS days are limited. I've been trying to get the BLFS book somewhat up to date in the last couple of weeks, as I believe there's still a niche out there. x86 archs will be in use for some time to come in various capacities, especially in dedicated server use. Randy I think your in the same boat as Ryan and myself are right now. We have been to busy with our day jobs to keep up to date on changes required for the projects. You ask if there are any plans to eventually begin work on CLFS when the time is right. Unfortunately, I don't believe it is an option at this point. CLFS has offered it's services to help the LFS and BLFS teams numerous times, we have never been given any tasks or have been asked to help. I'm just disgusted you decided to bring up the past, that was all behind us. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
