Re: LiveCD Users
> > I would love a simple installer that copies the contents of the livecd > > to a "safe OS" partition, from which to build LFS or CLFS or whatever. > > > Sorry, the information how to do this was available before, and is still > available via private e-mail. However, due to dummies asking stupid BLFS > support questions on IRC without completing LFS, I provide this > information only on the condition that you unsubscribe from the support I do understand this line of reasoning. If we went into the business of this we would become a distro, if that's what I am to understand. :) We need to put this desire to not be a distro in some sort of mission statement, if it already isn't in one. :) In the meantime I guess I will just have to make my own script :) I will try loading the cd into my 2G of RAM. Thanks for the help! Craig Jackson (TheEpitome) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Users
Craig Jackson wrote: > Otherwise, I use > console due to the extreme performance hit of X when run from the > LiveCD. (Not sure why this is). > This is known to happen on machines with insufficient amount of RAM due to VM bug in the kernel, because it doesn't like the fact that our dm-snapshot device is backed by a loop device on a sparse file on tmpfs (it fruitlessly loops and tries to free some memory by flushing dirty buffers, try "echo 2 > /proc/sys/vm/overcommit_memory" and see an oops). Try adding swap to work around this. Or, if this guess is wrong (i.e., you have 512 MB of RAM or more), try booting the SVN version of the LiveCD as "linux toram" (if you have only 512 MB of RAM, you'll have to add swap, though). >> 4) What is the most annoying or useless bits of the CD? >> > > IPRoute. net-tools were added in the SVN version of the LiveCD. > I can hack the init scripts a bit to get it to work, but its > command line parameters are not very intuitive. This was my least > favorite upgrade from 5.x. I do understand the need for the update. > (IPv6 support). > LFS doesn't support IPv6, so the move to iproute2 is unjustified from this viewpoint. I will take back this opinion as soon as LFS bootscripts start supporting IPv6. >> 5) What would you change/add/improve? >> > > I would love a simple installer that copies the contents of the livecd > to a "safe OS" partition, from which to build LFS or CLFS or whatever. > Sorry, the information how to do this was available before, and is still available via private e-mail. However, due to dummies asking stupid BLFS support questions on IRC without completing LFS, I provide this information only on the condition that you unsubscribe from the support lists and agree to be banned on IRC. The SVN CD includes a compromise: you can put the ISO as a file onto a partition and use this file for booting - but you can't save anything across a reboot (i.e., the same limitation as if you booted from a CD). -- Alexander E. Patrakov -- 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"
Sent: Monday, July 23, 2007 8:51 PM
Subject: Re: {B,C}LFS State of Things (was Re: SVN-20070706: ...)
>
> 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.
Hello Jeremy.
Really I appreciate your efforts.
A full 64-bit LiveCD is interesting indeed, I'm working since last year
to a DVD installation set covering archs I've tested and adding more
things to installation options, deviating from LFS and BLFS so don't
take it as related or whatever.
Now I'm looking for a good Qt4 programming book to change installer to
have it graphical too (if one wants it) using Qt libraries (I don't like
Gtk, that's all).
Best wishes,
Luca
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
most recent iproute2
Randy McMurchy wrote: > 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. > s/iptables/iproute2/ :( The changelog's most recent entry is 2006-03-21, so it has not been kept up to date. A diff between the versions gives about 900 lines difference, but I haven't analyzed what was done. Changed files: iproute/Makefile iproute/include/SNAPSHOT.h iproute/include/iptables_common.h iproute/include/libiptc/ipt_kernel_headers.h iproute/include/linux/fib_rules.h iproute/include/linux/if.h iproute/include/linux/if_addr.h iproute/include/linux/if_link.h iproute/include/linux/netfilter/x_tables.h iproute/include/linux/netfilter/xt_tcpudp.h iproute/include/linux/netfilter_ipv4/ip_tables.h iproute/include/linux/netlink.h iproute/include/linux/socket.h iproute/include/linux/tc_act/tc_defact.h iproute/include/linux/xfrm.h iproute/ip/ipaddress.c iproute/ip/ipneigh.c iproute/ip/iprule.c iproute/ip/ipxfrm.c iproute/ip/routef iproute/ip/rtmon.c iproute/ip/xfrm.h iproute/ip/xfrm_policy.c iproute/ip/xfrm_state.c iproute/lib/libnetlink.c iproute/lib/ll_addr.c iproute/lib/ll_map.c iproute/lib/ll_types.c iproute/misc/ss.c iproute/tc/Makefile iproute/tc/m_ipt.c iproute/tc/q_netem.c iproute/tc/tc.c iproute/tc/tc_core.h iproute/tc/tc_filter.c iproute/tc/tc_util.c iproute/tc/tc_util.h -- 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: > 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: ...)
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: ...)
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: ...)
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: ...)
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: ...)
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: ...)
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: ...)
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: ...)
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: ...)
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: ...)
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:
> 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: r8232 - in branches/x86_64/BOOK: . chapter05 chapter06
Greg Schafer wrote:
>> Author: jhuntwork
>> - Use --disable-multilib in final gcc and binutils
>
> Why binutils? It serves no purpose there.
I did notice that it didn't make a difference with binutils, but I must
admit that this was a case of working from CLFS. I started by taking
notes of what they had and adapting for LFS. When I noticed that I
forgot this for final GCC in chapter 6 (the build crashed looking for
unnecessary stub headers), I just dumped in the command for binutils, as
well, assuming that CLFS knew what they are doing. Assumptions...
I can see by grepping that binutils seems totally unaware of this
switch. Will remove...
>> - Explicitly tell Glibc to use /lib and /usr/lib, instead
>> of defaults of /lib64 and /usr/lib64
>
> Again, why do it? The symlinks take care of this. It's just complicating
> the build unnecessarily IMHO.
This one I deliberated with for a bit. I finally opted for the switches
to Glibc for a couple of main reasons:
* Elsewhere, (in the gcc patches, for example) we are explicitly
forcing /lib to be the location of the 64-bit libraries. For the sake of
consistency in the system, it seemed better to have Glibc configured to
look there (and install there) by default.
* If Glibc is configured for /lib and /usr/lib, then if for some the
reason the symlinks disappear, the toolchain remains relatively intact.
If Glibc is left to its defaults, when the {/usr,}/lib64 links
disappear, the linker is broken immediately. It seems more robust to
have the symlinks there for compatibility only, than for them to be
absolutely depended upon. Of course, since I am still in the midst of
testing, I can't say definitively that the symlinks aren't absolutely
necessary either way.
Feel free to prove me wrong on the above. I am definitely learning as I
go and pointers from those already through this route are always welcome.
--
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:
> 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: r8232 - in branches/x86_64/BOOK: . chapter05 chapter06
> Author: jhuntwork > Date: 2007-07-23 16:04:42 -0600 (Mon, 23 Jul 2007) > New Revision: 8232 > - Use --disable-multilib in final gcc and binutils Why binutils? It serves no purpose there. > - Explicitly tell Glibc to use /lib and /usr/lib, instead > of defaults of /lib64 and /usr/lib64 Again, why do it? The symlinks take care of this. It's just complicating the build unnecessarily 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: {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: ...)
On Mon, Jul 23, 2007 at 03:39:21PM -0600, Jeremy Huntwork wrote:
> 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.
>
Ah, I misunderstood. Yes, clfs had a separate
gcc-4.1.2-pure64_specs patch. Attached.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
Submitted By: Robert Connolly (ashes)
Date: 2007-02-14
Initial Package Version: 4.1.2
Upstream Status: Not Sent - LFS Specfic
Origin: Idea originally developed by Ryan Oliver and Greg Schafer for
the Pure LFS project.
More architectures added by Zack Winkles.
Further fine tunings by Greg Schafer.
Rediffed against gcc 4.0.0 by Robert Connolly.
Rediffed against gcc 4.1.0 by Chris Staub
Rediffed against gcc 4.1.2 by Jim Gifford
Description: This patch modifies the location of the dynamic linker for
the GCC Pass 2 build in LFS Chapter 5.
diff -Naur gcc-4.1.2.orig/gcc/config/alpha/linux-elf.h
gcc-4.1.2/gcc/config/alpha/linux-elf.h
--- gcc-4.1.2.orig/gcc/config/alpha/linux-elf.h 2005-06-24 18:22:41.0
-0700
+++ gcc-4.1.2/gcc/config/alpha/linux-elf.h 2007-02-14 07:51:38.0
-0800
@@ -27,7 +27,7 @@
#define SUBTARGET_EXTRA_SPECS \
{ "elf_dynamic_linker", ELF_DYNAMIC_LINKER },
-#define ELF_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+#define ELF_DYNAMIC_LINKER "/tools/lib/ld-linux.so.2"
#define LINK_SPEC "-m elf64alpha %{G*} %{relax:-relax} \
%{O*:-O3} %{!O*:-O1} \
diff -Naur gcc-4.1.2.orig/gcc/config/arm/linux-elf.h
gcc-4.1.2/gcc/config/arm/linux-elf.h
--- gcc-4.1.2.orig/gcc/config/arm/linux-elf.h 2005-10-09 18:04:31.0
-0700
+++ gcc-4.1.2/gcc/config/arm/linux-elf.h2007-02-14 07:51:38.0
-0800
@@ -51,7 +51,7 @@
#define LIBGCC_SPEC "%{msoft-float:-lfloat} %{mfloat-abi=soft*:-lfloat} -lgcc"
-#define LINUX_TARGET_INTERPRETER "/lib/ld-linux.so.2"
+#define LINUX_TARGET_INTERPRETER "/tools/lib/ld-linux.so.2"
#define LINUX_TARGET_LINK_SPEC "%{h*} %{version:-v} \
%{b} \
diff -Naur gcc-4.1.2.orig/gcc/config/frv/linux.h
gcc-4.1.2/gcc/config/frv/linux.h
--- gcc-4.1.2.orig/gcc/config/frv/linux.h 2005-06-24 18:22:41.0
-0700
+++ gcc-4.1.2/gcc/config/frv/linux.h2007-02-14 07:51:38.0 -0800
@@ -41,7 +41,7 @@
%{mfdpic: -m elf32frvfd -z text} %{shared} %{pie} \
%{!shared: %{!static: \
%{rdynamic:-export-dynamic} \
- %{!dynamic-linker:-dynamic-linker /lib/ld.so.1}} \
+ %{!dynamic-linker:-dynamic-linker /tools/lib/ld.so.1}} \
%{static}}"
/* Support for compile-time default CPU. */
diff -Naur gcc-4.1.2.orig/gcc/config/i386/gnu.h gcc-4.1.2/gcc/config/i386/gnu.h
--- gcc-4.1.2.orig/gcc/config/i386/gnu.h2004-09-07 17:17:19.0
-0700
+++ gcc-4.1.2/gcc/config/i386/gnu.h 2007-02-14 07:51:38.0 -0800
@@ -27,7 +27,7 @@
%{!shared: \
%{!static: \
%{rdynamic:-export-dynamic} \
- %{!dynamic-linker:-dynamic-linker /lib/ld.so}} \
+ %{!dynamic-linker:-dynamic-linker /tools/lib/ld.so}} \
%{static:-static}}"
#undef STARTFILE_SPEC
diff -Naur gcc-4.1.2.orig/gcc/config/i386/linux.h
gcc-4.1.2/gcc/config/i386/linux.h
--- gcc-4.1.2.orig/gcc/config/i386/linux.h 2005-08-10 10:53:01.0
-0700
+++ gcc-4.1.2/gcc/config/i386/linux.h 2007-02-14 07:51:38.0 -0800
@@ -105,7 +105,7 @@
/* If ELF is the default format, we should not use /lib/elf. */
#define LINK_EMULATION "elf_i386"
-#define DYNAMIC_LINKER "/lib/ld-linux.so.2"
+#define DYNAMIC_LINKER "/tools/lib/ld-linux.so.2"
#undef SUBTARGET_EXTRA_SPECS
#define SUBTARGET_EXTRA_SPECS \
diff -Naur gcc-4.1.2.orig/gcc/config/i386/linux64.h
gcc-4.1.2/gcc/config/i386/linux64.h
--- gcc-4.1.2.orig/gcc/config/i386/linux64.h2005-08-10 10:53:01.0
-0700
+++ gcc-4.1.2/gcc/config/i386/linux64.h 2007-02-14 07:51:38.0 -0800
@@ -60,8 +60,8 @@
%{!shared: \
%{!static: \
%{rdynamic:-export-dynamic} \
- %{m32:%{!dynamic-linker:-dynamic-linker /lib/ld-linux.so.2}} \
- %{!m32:%{!dynamic-linker:-dynamic-linker /lib64/ld-linux-x86-64.so.2}}} \
+ %{m32:%{!dynamic-linker:-dynamic-linker /tools/lib32/ld-linux.so.2}} \
+ %{!m32:%{!dynamic-linker:-dynamic-linker
/tools/lib/ld-linux-x86-64.so.2}}} \
%{static:-static}}"
/* Similar to standard Linux, but adding -ffast-math support. */
diff -Naur gcc-4.1.2.orig/gcc/config/ia64/linux.h
gcc-4.1.2/gcc/config/ia64/linux.h
--- gcc-4.1.2.orig/gcc/config/i
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: ...)
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: > > 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: Plans for LFS-6.3
On 7/23/07, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Lunes, 23 de Julio de 2007 20:49, Dan Nicholson escribió:
>
> > That doesn't say too much. OK, looking at postix/test-vfork3.c, I
> > think I see the issue. At that point it does 'unsetenv ("PATH");' and
> > then tries to execute "echo". For this to work, we need to have echo
> > in /bin, which we don't at that point. If /bin/echo -> /tools/bin/echo
> > is added to the Essential Symlinks, I bet it will pass. Can you give
> > that a try?
>
> Yes, it passes, included using -j3 ;-)
OK. I'm adding echo and noting that nptl/tst-cancel1 is known to fail.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LiveCD Users
On Mon, Jul 23, 2007 at 12:57:14PM -0700, Craig Jackson wrote:
> I would love a simple installer that copies the contents of the livecd
> to a "safe OS" partition, from which to build LFS or CLFS or whatever.
The most recent version does allow you to run the CD from a partition or
USB flash drive. Also, IIRC, there are hints available on 'installing'
the CD contents to a hard disk.
> has errors, but Linux doesn't seem to mind so much. (If you think
> this is immoral, think about all the people that suddenly like Linux
> so much more after seeing its ability to do this) :)
Immoral? Nah, I think it's great. :)
> No, thank you Jerermy and company. You truly have built the ultimate
> boot cd as far as I'm concerned. :)
And many thanks to all who participated in this thread. It was most
appreciated. I think it helps to see that people are still making use of
the CD and that, for the most part, it's well-liked. I'll be looking
over the comments made to see where we might be able to use the
suggestions.
Admittedly, I was disappointed to see that only one {x,}LFS developer
commented. :/ Still, there was far more feedback than I expected. Thanks
again, everyone.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
gcc --print-search-dirs losing data in chroot
Something strange popped up after a recompile of one of my systems. I performed a chroot after building the toolchain and suddenly gcc could not find 'cc1', etc. After doing research, I found the command gcc --print-search-dirs. I then compared this with the /tools/bin/gcc in the chroot to the outside chroot /tools/bin/gcc, which are still the same exact files. Results differed, after comparing the two, I noticed /tools/lib/ from outside the chroot became /tools/ causing gcc to not be able to find anything as /lib vanished using its own built in search functions!? Any ideas? -- Kevin Day -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD Users
> 1) What version of the CD do you use/have? Currently, 6.2-5. For LFS 5.x production server builds, I use a LiveCD 5.x build I have archived. > 2) What do you use the CD most for? Building LFS and CLFS. I will use X on the CD only if I have no other way of browsing the net (like another machine). Otherwise, I use console due to the extreme performance hit of X when run from the LiveCD. (Not sure why this is). > 3) What are the most useful parts of the CD to you? The fact it is a clean environment to build X, without worrying about the kernel version or getting complaints of automake not being the perfect version etc. > 4) What is the most annoying or useless bits of the CD? IPRoute. I can hack the init scripts a bit to get it to work, but its command line parameters are not very intuitive. This was my least favorite upgrade from 5.x. I do understand the need for the update. (IPv6 support). > 5) What would you change/add/improve? I would love a simple installer that copies the contents of the livecd to a "safe OS" partition, from which to build LFS or CLFS or whatever. I know, I know, I should write a script. I am only reluctant to do so because I am told it would not be in the spirit of LFS to have it all done for you. I would not use it this way, it would be the OS I build it from, not my final product. There are plenty of great features on the LiveCD that I would not include in my final customized build. I would leave this theoretical LiveCD image on my hard drive until another major release of LiveCD came out. > Of course any other thoughts or comments are welcome. We really just > need to get an idea of how useful our project is to the community. If > it's too much work to answer the above, just a short reply saying you > use the CD would be helpful, too. Ironically, I have worked at places that are Windows-only and as soon as it is introduced, we use this livecd regularly to recover data from systems. Windows is very picky about mounting an NTFS partition that has errors, but Linux doesn't seem to mind so much. (If you think this is immoral, think about all the people that suddenly like Linux so much more after seeing its ability to do this) :) > Thanks in advance, No, thank you Jerermy and company. You truly have built the ultimate boot cd as far as I'm concerned. :) Craig Jackson (TheEpitome) -- 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
El Lunes, 23 de Julio de 2007 20:49, Dan Nicholson escribió:
> That doesn't say too much. OK, looking at postix/test-vfork3.c, I
> think I see the issue. At that point it does 'unsetenv ("PATH");' and
> then tries to execute "echo". For this to work, we need to have echo
> in /bin, which we don't at that point. If /bin/echo -> /tools/bin/echo
> is added to the Essential Symlinks, I bet it will pass. Can you give
> that a try?
Yes, it passes, included using -j3 ;-)
--
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: Plans for LFS-6.3
On 7/23/07, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Lunes, 23 de Julio de 2007 02:37, Dan Nicholson escribió:
>
> > That's what I meant.
>
> tst-vfork3.out just contains:
>
> script 1
> script 1
> script 1
> script 1
> script 1
> script 2
> script 2
> script 2
> script 2
> script 2
> script 3
> script 3
> script 3
> script 3
> script 3
> echo failed with status 512
>
> Do you need tst-vfork3.mtrace and/or test-vfork3.o.d?
That doesn't say too much. OK, looking at postix/test-vfork3.c, I
think I see the issue. At that point it does 'unsetenv ("PATH");' and
then tries to execute "echo". For this to work, we need to have echo
in /bin, which we don't at that point. If /bin/echo -> /tools/bin/echo
is added to the Essential Symlinks, I bet it will pass. Can you give
that a try?
Hmm. We may want to scour through the essential symlinks again. Greg
seems to be getting away without grep and stty.
http://www.diy-linux.org/x86-reference-build/chroot.html#c-create_symlinks
> > That's one of those things I'd like to make
> > cleaner/easier in jhalfs.
>
> Well, on normal failures the build dirs are keep. For forced failures like
> this one, what I do is to not run automatically the Makefile, insert a "exit
> 1" on the appropriate build script, and then launch manually the Makefile.
> Very easy and quick, IMHO
>
> But if what you are thinking is on an option to keep all build dirs, that's
> another beast ;-)
That's what I had in mind. I have an idea of how to store a list of
"keep_dirs" to compare against the current build/src directory, but I
don't know if it will get really ugly. Manually killing it at the
right spot works for now.
--
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: ...)
Greg Schafer zip.com.au> writes: > 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. 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? -- JH -- 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
El Lunes, 23 de Julio de 2007 02:37, Dan Nicholson escribió: > That's what I meant. tst-vfork3.out just contains: script 1 script 1 script 1 script 1 script 1 script 2 script 2 script 2 script 2 script 2 script 3 script 3 script 3 script 3 script 3 echo failed with status 512 Do you need tst-vfork3.mtrace and/or test-vfork3.o.d? > That's one of those things I'd like to make > cleaner/easier in jhalfs. Well, on normal failures the build dirs are keep. For forced failures like this one, what I do is to not run automatically the Makefile, insert a "exit 1" on the appropriate build script, and then launch manually the Makefile. Very easy and quick, IMHO But if what you are thinking is on an option to keep all build dirs, that's another beast ;-) -- 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
