Does the M4 package need to be identified as a "host requirement"?
Hi all, Best I can tell the GMP package needs M4 to build successfully. This can be approached in one of two ways: 1. Build M4 before building GMP in Chapter 5 (in fact it may be needed to be built before GCC pass1 as GMP is built inside the GCC Pass1 instructions. 2. Add it to the Host Requirements page. Thoughts from others would be appreciated. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Does the M4 package need to be identified as a "host requirement"?
Randy McMurchy wrote: > Best I can tell the GMP package needs M4 to build successfully. > This can be approached in one of two ways: > > 1. Build M4 before building GMP in Chapter 5 (in fact it may > be needed to be built before GCC pass1 as GMP is built inside > the GCC Pass1 instructions. > > 2. Add it to the Host Requirements page. For the time being, I've added M4 to the Chapter 5 build, but it is in the alphabetical order which doesn't help the issue of it being required by the GMP package earlier in Chapter 5. We'll change things once a permanent solution is determined. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Does the M4 package need to be identified as a "host requirement"?
On Mon, 06 Oct 2008 16:15:43 +0200, Randy McMurchy <[EMAIL PROTECTED]> wrote: > Hi all, > > Best I can tell the GMP package needs M4 to build successfully. > This can be approached in one of two ways: > > 1. Build M4 before building GMP in Chapter 5 (in fact it may > be needed to be built before GCC pass1 as GMP is built inside > the GCC Pass1 instructions. > > 2. Add it to the Host Requirements page. > > Thoughts from others would be appreciated. > Hi, I would prefer your first suggestion. I know that the liveCD project is considered as "dead", but I also think that many users who build LFS (especially first-time users) will try to use the liveCD as host system. Quite a few users using the CD will not check the host system requirements, leading to errors when trying to build GMP. So I think we should either build M4 in the book or, if we add it to the host system requirements, add a note that the liveCD is outdated and that people should check the host system requirements even if using the CD. Well, maybe we should add that note in either case, or is it already present and I just oversaw it? Regards - Philipp -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Does the M4 package need to be identified as a "host requirement"?
Randy McMurchy wrote: > Hi all, > > Best I can tell the GMP package needs M4 to build successfully. > This can be approached in one of two ways: > > 1. Build M4 before building GMP in Chapter 5 (in fact it may > be needed to be built before GCC pass1 as GMP is built inside > the GCC Pass1 instructions. > > 2. Add it to the Host Requirements page. If we can build it in LFS without additional host support, then we should do that. Just moving the order of builds would be preferable to a new host requirement, even if we need to add M4 to chapter 5. M4 and GMP are very simple builds. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
GMP and MPFR
Hello, I know I'm jumping in a little bit late here, but I'm having trouble spotting where this discussion took place and I'd appreciate a cluebat. I'm just curious, what was the rationale behind building gmp and mpfr in different manners within the same book? To be more specific, why let GCC build them internally for its own use on GCC pass1 and then build them separately for the other two passes of GCC? Thanks, -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
On Mon, 06 Oct 2008 17:17:01 +0200, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > I'm just curious, what was the rationale behind building gmp and mpfr in > different manners within the same book? To be more specific, why let > GCC build them internally for its own use on GCC pass1 and then build > them separately for the other two passes of GCC? I think this derived from a post in the thread GCC-4.3.2, Linux-2.6.26.2. I don't have enough time on my hands to search the original post, though. From what I understand about it, building GMP and MPFR as separate packages is the preferred method, but the bootstrap build will fail to locate these programs in the /tools directory in the first stage. Regards - Philipp -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Does the M4 package need to be identified as a "host requirement"?
Bruce Dubbs wrote: > If we can build it in LFS without additional host support, then we should do > that. Just moving the order of builds would be preferable to a new host > requirement, even if we need to add M4 to chapter 5. It is not "if" we need to add it to Chapter 5. It is required by GMP. I checked the dependencies of M4 and everything that is noted on the dependencies page is listed on the host requirements. I've already added M4 to Chapter 5, so I suppose all we need to do is move it to right after the first binutils build in Chapter 5. Now we've got address Jeremy's question in the next post. I'll reply to that one now. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Does the M4 package need to be identified as a "host requirement"?
Randy McMurchy wrote: > Hi all, > > Best I can tell the GMP package needs M4 to build successfully. > This can be approached in one of two ways: > > 1. Build M4 before building GMP in Chapter 5 (in fact it may > be needed to be built before GCC pass1 as GMP is built inside > the GCC Pass1 instructions. > > 2. Add it to the Host Requirements page. I would think that adding it to the Host Requirements page would be slightly preferable. Here's my thinking: We already have bison as a host req. Bison depends on m4, so most distros I know will have m4 installed as a dependency of bison. Even building bison from source requires that you first build m4, anyway. So I tend to think of Bison and M4 going hand in hand. Why add an extra thing to build if by far the majority of systems will have already had m4 installed due to the bison req? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
Jeremy Huntwork wrote: > I know I'm jumping in a little bit late here, but I'm having trouble > spotting where this discussion took place and I'd appreciate a cluebat. I'm not sure it was ever discussed. DJ went out on his own and built a version of the book that we've since sort of adopted as the direction of SVN. I believe most of the information he has was determined by seeing what was going on over at DIY. I know that they discussed it a bit over there. You may want to check the DIY archives. > I'm just curious, what was the rationale behind building gmp and mpfr in > different manners within the same book? To be more specific, why let > GCC build them internally for its own use on GCC pass1 and then build > them separately for the other two passes of GCC? I'm not sure the rationale. But you bring up a good point. Perhaps it has something to do with GCC pass 1 having GMP and MPFR built in the GCC tree makes those libraries statically linked to GCC. Then, in Pass 2 of GCC perhaps it was/is undesirable to have the GMP and MPFR libs statically linked. I'm just guessing, though. We'll have to get DJ's input on that one. However, in Chapter 6 I know I wouldn't like to see statically linked GMP and MPFR in GCC as I build them later on and it seems silly to have a package statically linked in GCC and all other packages link dynamically. This is all a guess. DJ and Greg could probably provide much better details. But I'm glad you brought it up Jeremy as we need to have an idea why things are the way they are. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
Philipp Christian Loewner wrote: > From what I understand about it, building GMP and MPFR as separate > packages is the preferred method, but the bootstrap build will fail > to locate these programs in the /tools directory in the first stage. Hmmm. I read through that thread already, but I didn't see any reasoning for why the current approach. I don't know why installing them as separate packages is preferable. Some things to consider: * Only GCC needs them. * GCC has a mechanism built in to build them and use them the way it needs to. If we would just let it build them, then there's that much less possibility of breakage due to misconfiguration. * I don't know if I particularly want to have two extra libs installed in my final (or temporary) system that I will either rarely or never use otherwise. I've used gpm separately before, but usually, in that instance if I need it, I'm totally happy getting it and installing it then. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
Philipp Christian Loewner wrote: > From what I understand about it, building GMP and MPFR as separate > packages is the preferred method, but the bootstrap build will fail > to locate these programs in the /tools directory in the first stage. Yes, that brings back things I remember. Thanks, Philipp. Indeed that was a problem. GCC failed to find GMP and MPFR in /tools during the bootstrap. Now why they are built separately for Pass 2 in Chapter 5, I can't answer. See my previous post why I think they should be stand-alone in Chapter 6. HTH, Jeremy. And thanks again for the heads-up, Philipp. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
Randy McMurchy wrote: > I believe most of the information he has was determined by > seeing what was going on over at DIY. I know that they discussed > it a bit over there. You may want to check the DIY archives. Well, DIY lets GCC build them internally on all passes. When I posted, I was already aware of the DIY method, but I wanted to see what our current rationale was and if there was something I missed. >> I'm just curious, what was the rationale behind building gmp and mpfr in >> different manners within the same book? To be more specific, why let >> GCC build them internally for its own use on GCC pass1 and then build >> them separately for the other two passes of GCC? > > I'm not sure the rationale. But you bring up a good point. > Perhaps it has something to do with GCC pass 1 having GMP > and MPFR built in the GCC tree makes those libraries statically > linked to GCC. > > Then, in Pass 2 of GCC perhaps it was/is undesirable to have > the GMP and MPFR libs statically linked. I'm just guessing, though. > We'll have to get DJ's input on that one. Yeah, looking forward to that. Thanks for the reply, Randy. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
Jeremy Huntwork wrote: > * GCC has a mechanism built in to build them and use them the way it > needs to. If we would just let it build them, then there's that much > less possibility of breakage due to misconfiguration. > > * I don't know if I particularly want to have two extra libs installed > in my final (or temporary) system that I will either rarely or never use > otherwise. I've used gpm separately before, but usually, in that > instance if I need it, I'm totally happy getting it and installing it then. Well, I'll go on record as being one that is 100% opposite with you on this one, Jeremy. I don't want libraries statically linked in my GCC and then discover that one of them (or both) have vulnerabilities discovered, which would make me then have to rebuild GCC. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
On Mon, Oct 6, 2008 at 8:55 AM, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > Philipp Christian Loewner wrote: >> From what I understand about it, building GMP and MPFR as separate >> packages is the preferred method, but the bootstrap build will fail >> to locate these programs in the /tools directory in the first stage. > > Hmmm. I read through that thread already, but I didn't see any reasoning > for why the current approach. I don't know why installing them as > separate packages is preferable. Some things to consider: > > * Only GCC needs them. Just for the record, I know guile can use an external libgmp: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=configure.in;h=e67e1d84;hb=HEAD#l820 Google shows that clamav and openswan use it, too. I don't know if that's compelling enough, but I thought it should be known. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
On Mon, 06 Oct 2008 10:51:15 -0500 Randy McMurchy <[EMAIL PROTECTED]> wrote: > However, in Chapter 6 I know I wouldn't like to see statically > linked GMP and MPFR in GCC as I build them later on and it seems > silly to have a package statically linked in GCC and all other > packages link dynamically. I have to say that I agree with this. However we go, lets make sure it works - at the moment DJ's book works, I know, I'm using (most of) it. I may not be editing, but I am testing. R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
Dan Nicholson wrote: >> * Only GCC needs them. > > Just for the record, I know guile can use an external libgmp: > > http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=configure.in;h=e67e1d84;hb=HEAD#l820 > > Google shows that clamav and openswan use it, too. I don't know if > that's compelling enough, but I thought it should be known. Well, that's not quite what I meant. I meant that in our build process, only GCC requires it. In any case, Randy already raised a good point I hadn't considered. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
> Philipp Christian Loewner wrote: >> From what I understand about it, building GMP and MPFR as separate >> packages is the preferred method, but the bootstrap build will fail >> to locate these programs in the /tools directory in the first stage. > > Hmmm. I read through that thread already, but I didn't see any reasoning > for why the current approach. I don't know why installing them as > separate packages is preferable. Some things to consider: > > * Only GCC needs them. > > * GCC has a mechanism built in to build them and use them the way it > needs to. If we would just let it build them, then there's that much > less possibility of breakage due to misconfiguration. > > * I don't know if I particularly want to have two extra libs installed > in my final (or temporary) system that I will either rarely or never use > otherwise. I've used gpm separately before, but usually, in that > instance if I need it, I'm totally happy getting it and installing it > then. Sorry to drop in after being away so long. This topic is near and dear to my heart and I had to speak up. The libgmp and libmpfr libs are quite valuable to the people in the scientific or mathematics world and I, for one, use them a lot. While GCC needs them as part of the bootstrap process and then LFS has no other need I would submit to you the idea that these two libs are of great value to a number of technical users. Also, there are other software packages which the user may want later on that depend on either gmp or mpfr ( or both ) such as PHP 5 - GnuMP Extensions and ClamAV antivirus software. I say to you that having the gmp and mpfr packages as separate items/packages is of value and with so little overhead required to build them it would perhaps be best to leave them in the LFS process as is. Dennis Clarke -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Milestones
Hi Bruce, On Sun, Oct 05, at 12:49 Bruce Dubbs wrote: > > That seems reasonable.It > would not be hard to branch a 6.3.1 from 6.3 and commit changes to that as > appropriate. I'm not sure what the release procedures should be. Do we do > a > -rc1, etc for a minor errata change? I am thinking that would be overkill. I think the same, there is no need for a release candidate. > I suppose that a message that the branch is ready to the -dev list would be > enough > to decide if it's ready and then go through the normal process of building > the > book in the various formats, updating the web site, and making the > announcement > would be appropriate. I am not sure about the announcement. > As an aside, how do we handle the change log? Do we leave in all the changes > form 6.2 to 6.3 and add the changes for the point release to the top, or do > we > just put in the changes made in the point release. I believe, we don't want to clean the changelog in that case, just append the changes. Speaking for point releases, there are now (at least) three changes and maybe there is enough justification for one: - E2fsprogs which is in errata - the security fix for perl - and a broken mktemp link it might be more, so we have a chance to test our reflexes and check how the system works. > > The same thing goes for the development book. This requires somebody to > > define a set of goals and a time frame for the next minor release (or major > > version) of the book. > > I just did that, but of course we can change it if we can develop a consensus > about what changes are needed. Oh thanks, although I think it would be better if you started a new thread. > > > At some point, we should branch when a clear set of > > goals are defined for the next release. The fun part is that this should > > happen fairly *early* in the development cycle. This, in effect, is an > > answer > > to Ag's previous concern. In that branch, we would require that changes are > > checked pretty thoroughly, much like we watch over trunk today. Basically, > > we > > have a set of goals now, so IMO as soon as the big list of package updates > > are done, we should branch for 6.4, not *after* trunk is proven to be > > stable-ish. > > This sounds a bit like what we did once before where we had an experimental > branch as well as the -dev branch. This used to be for bleeding edge stuff. > I > really don't think it is necessary at the level of changes that are currently > being made. I think we should provide more freedom to editors to create new branches for whatever reason (even just to have their own book in the repository). Look; all the serious development that took place in those 2-3 years I am present in the project, it was after some branches, like the alphabetical branch or/and especially the UTF8 stuff, which it wasn't even a branch, it was a book that was sitting in the public_html of our Russian expert. Even now, the current resurrection came after another book from the LFS home dir, and forgive me but this is a shame. Again, I would welcome to see editors to work in their own copies. I guess the natural choice for that kind of development is git. > I'm not sure I understand Ag's need to have a release for every gcc version. > That makes an LFS release tied to the gcc release cycle. I don't think we > want > to tie ourselves to that. Also, as noted before, the full tool chain of gcc, > binutils, and glibc are the critical packages that all the others depend > upon. > On top of that, as DJ noted, there are no formal release cycles for glibc any > more. > > I would be more in favor of just having a target minor release cycle of every > six months, say Feb 1 and Aug 1, where the packages are updated. As editor > time > and interest allows, then fold in more significant changes within that cycle. I am pretty sure that I don't have a "need", but we are talking about branches and releases and we need to mark the start of a new cycle with a way, and from all the four toolchain components, (I believe) the most appropriate package to mark this cycle, is the compiler; because is the most fragile of all (Only the compiler can make large chunk of code unbuild-able). You seem to prefer a cycle based on a time, which I am not really opposite, but the funny thing is, that the six months time frame, is only achievable today (in Linux land), by only Ubuntu, but who has paid developers. Again I believe that the compiler is the natural choice here, but I won't be negative for a time based cycle. > > It is my hope that branching early on, and being a little more lax with > > trunk > > and its freedom to create more branches would keep people interested in > > contributing. Much like the LFS-Hackers list provided some time ago, but > > with > > more definition. BTW, I miss the lfs-hackers list! ;-) Toying on the > > bleeding > > edge and finding or making the solutions is fun for me and
Re: GMP and MPFR
Dan Nicholson wrote: > Just for the record, I know guile can use an external libgmp: > > http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=configure.in;h=e67e1d84;hb=HEAD#l820 > > Google shows that clamav and openswan use it, too. I don't know if > that's compelling enough, but I thought it should be known. The next version (7.x) of Coreutils can link against libgmp if available. >From the release notes: "If the GNU MP library is available at configure time, factor and expr support arbitrarily large numbers. Pollard's rho algorithm is used to factor large numbers." Yet another reason for possibly separate gmp installation in the chroot. Keep in mind tho' there are some gotchas. Last time I checked, the problem pointed to below was still there ie: build failure for 32-bit x86 if the real hardware is 64-bit. http://gcc.gnu.org/ml/gcc/2006-10/msg00698.html Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r8591 - in trunk/BOOK: . chapter01 chapter03 chapter06
Greg Schafer wrote: > This Perl version includes s static version of Zlib. Better to link > against the system Zlib? I think so. I would as well had I known. Thanks for the tip. I'll look into it. > The above post also refers to a test failure in the Syslog module. You're > not seeing that? Not sure why you're seeing it. In fact I had 0 (zero) failures on my testsuite run. :-) ext/Sys/Syslog/t/00-load..ok ext/Sys/Syslog/t/constantsok ext/Sys/Syslog/t/syslog...ok See below for more about the testsuite. >> +patch -Np1 -i >> ../&perl-page-patch; >> + >> Fix an incompatibility with gcc-&gcc-version;: > > Umm, that patch was only needed for perl-5.8.x, not 5.10.x And it was due > to kernel headers, not GCC. Good to know. Thanks, Greg. >> -make test >> +make -k test || true > > Ah, that explains why no test failure :-( Not good when the fix is known, > committed upstream and available. I'm interested in what fails. I suppose I'll need to look at the URL you posted, as I said I didn't have any failures. I left the syntax as DJ had it simply because it didn't dawn on me that it wasn't required. Thanks for your interest in our development and especially your comments. It is very nice of you to be helping out like this. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r8591 - in trunk/BOOK: . chapter01 chapter03 chapter06
Randy McMurchy wrote: > Not sure why you're seeing it. In fact I had 0 (zero) failures on my > testsuite run. :-) > > ext/Sys/Syslog/t/00-load..ok > ext/Sys/Syslog/t/constantsok > ext/Sys/Syslog/t/syslog...ok Ah, maybe something else (libc, kernel) has since been fixed. I'll also look into it. > Thanks for your interest in our development and especially your > comments. It is very nice of you to be helping out like this. No worries. Good to see you pitching in to get the LFS ball rolling. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
Jeremy Huntwork wrote: > Hello, > > I know I'm jumping in a little bit late here, but I'm having trouble > spotting where this discussion took place and I'd appreciate a cluebat. > > I'm just curious, what was the rationale behind building gmp and mpfr in > different manners within the same book? To be more specific, why let > GCC build them internally for its own use on GCC pass1 and then build > them separately for the other two passes of GCC? > I do not have all the details in front of me, but somebody said that gcc failed if gmp was not on the host in pass1. Greg pointed us to a DIY thread that showed how to build with GCC. There was no _need_ to build inline beyond that point, because that fixed the problem of the extra host system requirement. The extra packages are minimal, and required one way or the other. Shared seems better IMO as I use GMP anyway. It might not be a bad idea (less maintenance) to build the same way for both early builds and only build gmp and mpfr standalone for the final, though I haven't tried that yet. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
DJ Lucas wrote: > I do not have all the details in front of me, but somebody said that gcc > failed if gmp was not on the host in pass1. Greg pointed us to a DIY > thread that showed how to build with GCC. There was no _need_ to build > inline beyond that point, because that fixed the problem of the extra > host system requirement. The extra packages are minimal, and required > one way or the other. Shared seems better IMO as I use GMP anyway. It > might not be a bad idea (less maintenance) to build the same way for > both early builds and only build gmp and mpfr standalone for the final, > though I haven't tried that yet. Understood. This explanation as with others that appeared on the thread have answered the question adequately, I think. I don't have any problems with installing them to the final system. I was going to ask what you thought about making both passes in chapter 5 the same, but you've touched on that as well. I don't suppose it makes a big difference there. The only advantages I can see for building inline for both passes are perhaps a slightly smaller set of temporary tools, a marginal amount of time saved by the user (especially if building by hand) and, again, slightly less chance of error. Nothing really there that I think it's worth making a stink about. Anyway, I think I'm satisfied on this point. Thanks, everyone, for the input. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
Jeremy Huntwork wrote: > DJ Lucas wrote: > >> I do not have all the details in front of me, but somebody said that gcc >> failed if gmp was not on the host in pass1. Greg pointed us to a DIY >> thread that showed how to build with GCC. There was no _need_ to build >> inline beyond that point, because that fixed the problem of the extra >> host system requirement. The extra packages are minimal, and required >> one way or the other. Shared seems better IMO as I use GMP anyway. It >> might not be a bad idea (less maintenance) to build the same way for >> both early builds and only build gmp and mpfr standalone for the final, >> though I haven't tried that yet. >> > > I was going to ask > what you thought about making both passes in chapter 5 the same, but > you've touched on that as well. I don't suppose it makes a big > difference there. The only advantages I can see for building inline for > both passes are perhaps a slightly smaller set of temporary tools, a > marginal amount of time saved by the user (especially if building by > hand) and, again, slightly less chance of error. > You forgot the editor's responsibility. If something changes in GMP at a later date, it would only have to be changed in one place instead of two. It's worth investing the time to make and test that change IMO. I'll try it in my Wednesday build. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Coreutils-i18n patch
DJ Lucas wrote: > Randy McMurchy wrote: > >> Hi all, >> >> Noted in DJ's book (I'll continue to refer to it as that >> even though his book is what will be SVN, he's the one >> that got all this stuff going) that we've dropped the >> i18n patch for Coreutils. IIRC, upstream won't touch it, >> and I think I remember there may have been a discussion >> about it here, but I want to revisit it to ensure that >> we're all good dropping it and/or keeping it. >> >> Alexander may have some good info here, as others may >> also, but I want to ensure the community is agreed as to >> the direction we take. >> >> I'm not an i18n person, so I really cannot contribute >> anything worthwhile other than bringing it up here. >> >> I'm going to update Coreutils to 6.12 without the patch >> and we can always add it if we determine it should be >> there. I simply don't know if it should or should not be. >> >> > That patch has been buggy in the past. The current upstream version of > it does not apply to raw Coreutils-6.12, and it has been rejected by > upstream in the past. While I can certainly munge that patch into > applying, I do not have any reliable way to test the changes other than > witnessing no change. > Must have been more than 2 months and 2 weeks since I tested it. The current patch applies (with fuzz and offset). It does not build in the host system (BLFS-6.3) however. Again, I'll drop it in when this one is done and run through the tests that Alexander posted. FYI, the first test confirmed that the first sed in GLibC was correctly removed. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
DJ Lucas wrote: > Jeremy Huntwork wrote: >> DJ Lucas wrote: >> >>> I do not have all the details in front of me, but somebody said that gcc >>> failed if gmp was not on the host in pass1. Greg pointed us to a DIY >>> thread that showed how to build with GCC. There was no _need_ to build >>> inline beyond that point, because that fixed the problem of the extra >>> host system requirement. The extra packages are minimal, and required >>> one way or the other. Shared seems better IMO as I use GMP anyway. It >>> might not be a bad idea (less maintenance) to build the same way for >>> both early builds and only build gmp and mpfr standalone for the final, >>> though I haven't tried that yet. >>> >> I was going to ask >> what you thought about making both passes in chapter 5 the same, but >> you've touched on that as well. I don't suppose it makes a big >> difference there. The only advantages I can see for building inline for >> both passes are perhaps a slightly smaller set of temporary tools, a >> marginal amount of time saved by the user (especially if building by >> hand) and, again, slightly less chance of error. >> > You forgot the editor's responsibility. If something changes in GMP at > a later date, it would only have to be changed in one place instead of > two. It's worth investing the time to make and test that change IMO. > I'll try it in my Wednesday build. Typically, the changes for a package are minimal -- a change in md5sum, etc. A patch would require changes in two places, but for these packages, that is pretty unlikely. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
>>> DJ Lucas wrote: >>> I do not have all the details in front of me, but somebody said that gcc failed if gmp was not on the host in pass1. Greg pointed us to a DIY thread that showed how to build with GCC. There was no _need_ to build inline beyond that point, because that fixed the problem of the extra host system requirement. The extra packages are minimal, and required one way or the other. Shared seems better IMO as I use GMP anyway. It might not be a bad idea (less maintenance) to build the same way for both early builds and only build gmp and mpfr standalone for the final, though I haven't tried that yet. FYI: The GMP and MPFR packages can be built in Chapter 5 as seperate packages (no need to inline with GCC), but must be built statically (due to linker issues with finding shared libraries outside normal paths) and require configure switches are needed to help MPFR (and possibly gcc) locate the static libs (--with-gmp=/tools from memory) The Chapter 6 chroot shared build works due to the shared libs being in a standard location (/usr/lib, etc), and the linker able to find them using normal paths. So Chapter 5 can be inline with GCC (which builds static by default) or seperate but static, and Chapter 6 can be shared or static as you prefer. -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
Steve Crosby wrote: > So Chapter 5 can be inline with GCC (which builds static by default) > or seperate but static, and Chapter 6 can be shared or static as you > prefer. After thinking about this all day, I tend to think this is the way to go. Build GMP and MPFR inline with GCC (static) in Chapter 5, then break them out and build them separately in Chapter 6. Chapter 5 is the tools that build our final production version of packages. There's really no need to build GMP and MPFR separately in Chapter 5. It is actually easier to simply put instructions in the Chapter 5 GCC (both passes) to untar the packages and let GCC do its thing. Then, in Chapter 6, break out GMP and MPFR into separate packages. I'd like to see this as the direction we take. Of course, other suggestions are welcome. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Does the M4 package need to be identified as a "host requirement"?
Jeremy Huntwork wrote these words on 10/06/08 10:45 CST: > I would think that adding it to the Host Requirements page would be > slightly preferable. Here's my thinking: > > We already have bison as a host req. Bison depends on m4, so most > distros I know will have m4 installed as a dependency of bison. Even > building bison from source requires that you first build m4, anyway. So > I tend to think of Bison and M4 going hand in hand. Why add an extra > thing to build if by far the majority of systems will have already had > m4 installed due to the bison req? I lean to agreeing with Jeremy on this one. If M4 is probably present on the host (due to it being required by bison), then it is one less package that needs to be built in Chapter 5. We need to resolve this issue, so let's make some sort of decision one way or another. Other suggestions are welcome. -- Randy rmlscsi: [bogomips 1003.28] [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] 19:56:00 up 43 min, 1 user, load average: 0.36, 0.20, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
Randy McMurchy wrote: > Steve Crosby wrote: > >> So Chapter 5 can be inline with GCC (which builds static by default) >> or seperate but static, and Chapter 6 can be shared or static as you >> prefer. > > After thinking about this all day, I tend to think this is the > way to go. Build GMP and MPFR inline with GCC (static) in > Chapter 5, then break them out and build them separately in > Chapter 6. > > Chapter 5 is the tools that build our final production version > of packages. There's really no need to build GMP and MPFR > separately in Chapter 5. It is actually easier to simply put > instructions in the Chapter 5 GCC (both passes) to untar the > packages and let GCC do its thing. > > Then, in Chapter 6, break out GMP and MPFR into separate > packages. I'd like to see this as the direction we take. I like that approach. It is a win-win. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GMP and MPFR
On Monday October 6 2008 08:50:08 pm Randy McMurchy wrote: > Steve Crosby wrote: > > So Chapter 5 can be inline with GCC (which builds static by default) > > or seperate but static, and Chapter 6 can be shared or static as you > > prefer. > > After thinking about this all day, I tend to think this is the > way to go. Build GMP and MPFR inline with GCC (static) in > Chapter 5, then break them out and build them separately in > Chapter 6. > > Chapter 5 is the tools that build our final production version > of packages. There's really no need to build GMP and MPFR > separately in Chapter 5. It is actually easier to simply put > instructions in the Chapter 5 GCC (both passes) to untar the > packages and let GCC do its thing. > > Then, in Chapter 6, break out GMP and MPFR into separate > packages. I'd like to see this as the direction we take. > > Of course, other suggestions are welcome. > > -- > Randy I ran into problems when I combined GCC and Binutils in the same tree because of libiberty. GMP and MPFR don't have their own version of libiberty, so this specific problem shouldn't occur with GMP or MPFR. But I feel it is more flexable to build GMP and MPFR separately, statically, until the top level makefile, in GCC, becomes more standardized. robert pgp51DnlYiCfe.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Does the M4 package need to be identified as a "host requirement"?
Randy McMurchy wrote: > Jeremy Huntwork wrote these words on 10/06/08 10:45 CST: > > >> I would think that adding it to the Host Requirements page would be >> slightly preferable. Here's my thinking: >> >> We already have bison as a host req. Bison depends on m4, so most >> distros I know will have m4 installed as a dependency of bison. Even >> building bison from source requires that you first build m4, anyway. So >> I tend to think of Bison and M4 going hand in hand. Why add an extra >> thing to build if by far the majority of systems will have already had >> m4 installed due to the bison req? >> > > I lean to agreeing with Jeremy on this one. If M4 is probably present > on the host (due to it being required by bison), then it is one less > package that needs to be built in Chapter 5. > > We need to resolve this issue, so let's make some sort of decision > one way or another. Other suggestions are welcome. > > It has to built in Chpater 5 for the chapter6 GMP regardless. When is the only question. I see no need to add a host requirement if m4 can be built right after binutils' first pass. I suppose it could be moved way up in the chain for Chapter 6, but I though that we wanted all tools compiled by the last built version of gcc and binutils. Obviously, BinUtils, GMP and MPFR are exceptions to this rule (but are compiled by the same version of the target compiler type and libs), should M4 be an exception also? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
The Perl libc patch
Hello. From what I can see, we can use: -Dlibc=/tools/lib/libc-2.8.so -Ulocincpth -Uloclibpth \ -Dglibpth="/tools/lib" -Dusrinc="/tools/include" instead of the Perl libc patch. Is LFS interested in this (one less patch)? Someone needs to verify that this has identical results compared to the patch. robert pgpylNX9O1bJ8.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS Milestones
Bruce Dubbs wrote:
> DJ Lucas wrote:
>
>> Bruce Dubbs wrote:
>>
>>> I have added a new milestone, 6.4, for the current effort.
>>>
>
>
>> Yeah, actually. 6.4 sounds good to me.
>>
>
> OK, I have fleshed out the description of 6.4 and 7.0.
>
> http://wiki.linuxfromscratch.org/lfs/roadmap
>
> I've set a tentative target date of 6.4 as November 1 with the limited goal of
> updating all packages to latest stable releases.
>
> For 7.0, the tentative target date is March 31, 2009 with the goals:
>
>* Add x86_64 64-bit instructions
> o Still to be decided if a pure 64-bit or mixed 64/32-bit system should
> be
> targeted
>* Add introduction to Linux Standards Base
>* Update packages to latest stable releases
>
Cool.
>> Errata shouldn't sit around for 2 or 3 months, it should be addressed by
>> a new micro release in the release branch if the changes are not too
>> invasive. Take for instance the Perl-5.8.8 security patch. Micro package
>> revisions can also take place here.
>>
>
> That seems reasonable.It
> would not be hard to branch a 6.3.1 from 6.3 and commit changes to that as
> appropriate. I'm not sure what the release procedures should be.
Probably just use tags at that point since it is only in maintenance mode.
> Do we do a
> -rc1, etc for a minor errata change? I am thinking that would be overkill.
I agree.
> I
> suppose that a message that the branch is ready to the -dev list would be
> enough
> to decide if it's ready and then go through the normal process of building
> the
> book in the various formats, updating the web site, and making the
> announcement
> would be appropriate.
>
>
Include something to the effect of it being a bugfix release or point
release and that changes are only for security fixes or other minor errata.
> As an aside, how do we handle the change log? Do we leave in all the changes
> form 6.2 to 6.3 and add the changes for the point release to the top, or do
> we
> just put in the changes made in the point release.
>
>
We currently have a "What's new since the last release" page. The first
line on that page says "Below is a list of package updates since the
last release of the book."
How about addin an {H2} for each version? I haven't looked at LFS
sources to see exactly how that would work yet.
Since it is only a point bugfix release, the changelog should still
include the changelog from the previous release IMO.
>
>
Added the PM to future for now so that people see it there.
> There is nothing stopping an editor from branching for experimental purposes
> like Jeremy did with his pure 64-bit version. It doesn't have to be done at
> the head of the -dev version.
>
That depends on it's intended target for inclusion, but most likely,
this will be trunk to minimize the amount of merge issues when it comes
back for inclusion. I can't think of an example where it would be
appropriate to branch from next release target, but who knows.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Coreutils-i18n patch
DJ Lucas wrote: > DJ Lucas wrote: > >> Randy McMurchy wrote: >> >> >>> Hi all, >>> >>> Noted in DJ's book (I'll continue to refer to it as that >>> even though his book is what will be SVN, he's the one >>> that got all this stuff going) that we've dropped the >>> i18n patch for Coreutils. IIRC, upstream won't touch it, >>> and I think I remember there may have been a discussion >>> about it here, but I want to revisit it to ensure that >>> we're all good dropping it and/or keeping it. >>> >>> Alexander may have some good info here, as others may >>> also, but I want to ensure the community is agreed as to >>> the direction we take. >>> >>> I'm not an i18n person, so I really cannot contribute >>> anything worthwhile other than bringing it up here. >>> >>> I'm going to update Coreutils to 6.12 without the patch >>> and we can always add it if we determine it should be >>> there. I simply don't know if it should or should not be. >>> >>> >>> >> That patch has been buggy in the past. The current upstream version of >> it does not apply to raw Coreutils-6.12, and it has been rejected by >> upstream in the past. While I can certainly munge that patch into >> applying, I do not have any reliable way to test the changes other than >> witnessing no change. >> >> > Must have been more than 2 months and 2 weeks since I tested it. The > current patch applies (with fuzz and offset). It does not build in the > host system (BLFS-6.3) however. The testsuite fails to run to completion, first because nobody doesn't have write permissions to config.log, then misc/cut test fails. Needs investigation. Added config.log to chown command, and added -k to non root checks. For right now, it is just known to fail. I'll see if I can dig up some info on it. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
