Re: [lfs-dev] [blfs-dev] Introduction
On Aug 20, 2012, at 3:03 PM, Randy McMurchy wrote: > Anyway, I'm glad to be back and I look forward to getting back working > on the BLFS book again. I must really have stopped paying attention, I thought you were still leading the BLFS effort! Anyway, welcome back! I'm certain the various projects will benefit from your energy and enthusiasm again. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] 5.17. Coreutils-8.18 "cp -v src/su /tools/bin No such file or directory"
On Aug 16, 2012, at 12:37 PM, Bruce Dubbs wrote: > Sigh. > > It looks like we will need to add a section to Chapter 5 for shadow: > > pushd libmisc; make libmisc.a;popd > pushd lib; make libshadow.la; popd > pushd src; make su ; popd > > cp src/su /tools/bin Crazy overkill. su is only required for some testsuites. Try the busybox in chapter 5 route. It will save you time and space. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [blfs-dev] Andy Benton
Oh no! I'm so sorry to hear that! I always enjoyed reading Andy's posts and seeing the contributions he made to the projects. He will definitely be greatly missed. Please convey my deepest sympathy to his family. JH On Jul 31, 2012, at 5:25 PM, Bruce Dubbs wrote: > With great sadness, I have to report the passing of Andy Benton. > > I never had the opportunity to meet Andy in person, but after several > thousand posts to the lists, I think I knew him. His first post was in > March 2004. Since that time he made many, many contributions to LFS and > BLFS. > > Andy was from Prenton in northwest England and educated as an > Astrophysicist in Edinburgh. His son tells me that two things made him > happy: playing Team Fortress 2 and his work on LFS. > > Andy was 47 years old. He is survived by his Mother, Father, three > sisters, wife Angie, his son Eddie, and daughter Rusti. > > He will be missed. A lot. > > -- Bruce > -- > http://linuxfromscratch.org/mailman/listinfo/blfs-dev > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Linux, an OS?
On Jun 14, 2012, at 5:06 PM, Bruce Dubbs wrote: > youlys...@riseup.net wrote: >> Hey all! >> >> I'm new to LFS, and I started skimming though the book, and I found this. >> >> >>> Linux Kernel >>> >>> This package is the Operating System. It is the Linux in the GNU/Linux >>> environment. >>> >>> - >> http://www.linuxfromscratch.org/lfs/view/development/prologue/package-choices.html >> >> To my understanding, a Operating System is a series of packages, (more >> than one) that is used in unison to make a "feature-full" system. Isn't >> Linux just the part of the system that allocates memory to applications, >> and some other low-level tasks? >> >> What's the rational behind this? > > You have to understand what the definition of an operating system is. > Some people confuse the OS and the system. The OS is the kernel that > controls what programs are run, memory allocation, hardware input and > output, etc. The kernel alone would not be very useful without > supporting systems like bash. > > You can run the Linux kernel with just bash for IO, but even that > wouldn't be very useful without utility programs like coreutils, major > libraries like glibc, etc. > > Take a look at the Wikipedia entry for Operating System. Well from that article you can see that they don't mean just the kernel. For example they correctly list Mac OS X as an operating system which is much more than just their mach kernel. A kernel is just one part of the OS. You also need software in user space that acts as a human interface in order to achieve anything, even if this is just a simple shell. I suggest we change the wording in that section to at least call Linux the core of the operating system. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] kbd resizecons was still build on 32-bit x86
On Jun 6, 2012, at 10:47 PM, Bruce Dubbs wrote: > It's a neat exercise to get it as small as possible. Not very critical > though when RAM is $4/G, disk is $0.50/G, and even SSDs are down to $1/G. Again, it's not just about disk space or available RAM. It's about (as one example) the time it takes (and ease of) dynamically spinning up new virtual instances when a web cluster suddenly gets loaded down. People seem to forget how to achieve performance because technology is cheap. They've thrown caution to the wind regarding size (among other things) and lose sight of the fact that they _need_ more powerful hardware to achieve what they used to be able to do on less because they've let their code and system become unnecessarily bloated. It's a vicious cycle. Less is more. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] kbd resizecons was still build on 32-bit x86
On 6/6/12 9:21 PM, Bruce Dubbs wrote: > Jeremy Huntwork wrote: > >> (Major tangent now) My main motive for wanting to keep a very >> lightweight base system isn't so much size on disk as image size (a >> complete base system image). This is a somewhat important consideration >> if you want to be easily transferring / duplicating / manipulating >> virtual machines. > > Well you could always 'rm -rf /usr/share' > > and of course 'rm /usr/lib/*.a' Yes, removing docs and other extra files is good. As well as packaging link-time files separately (headers, static libs), compiling with -Os, stripping all binaries and libs, using a smaller libc (like http://www.etalabs.net/musl/) and other smaller utilities (like busybox or toybox). I'm doing most of those already: https://github.com/jhuntwork/LightCube-OS and https://github.com/jhuntwork/lightcube-bootstrap-musl JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] kbd resizecons was still build on 32-bit x86
On 6/6/12 7:27 PM, Ken Moffat wrote: > 1. It may encourage the people who are resurrecting the "drop > autotools from LFS" suggestion :) Too late, I'm already encouraged! :P Seriously though, I really didn't intend to bring up that discussion again. I only wanted to get rid of popt. :) But that may be a futile endeavor too... (Major tangent now) My main motive for wanting to keep a very lightweight base system isn't so much size on disk as image size (a complete base system image). This is a somewhat important consideration if you want to be easily transferring / duplicating / manipulating virtual machines. But that's all stuff I can achieve outside of LFS so there's no real need for me to encourage LFS proper to do the same, although I wouldn't mind if it did that either. :D JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] grep nitpick in chapter 5
On 6/6/12 3:24 PM, Matt Burgess wrote: > Surely if we can't find/link against host libs at this point, that flag > is at best superfluous and at worst a potential danger as it may mask us > being able to link against host libs when we shouldn't be able to? Yep - agreed on all points. Superfluous. > If you didn't gather from the above, I'm happy to take the switch and > its explanation out, but want to make sure it really is safe to do. I > assume this is safe(r) to do because of the recent toolchain/build > method improvements you committed? Well, technically, it should have always been safe. But it's possible, I suppose, that there was something in the previous method that leaked in some host paths. It should definitely not be the case now. Note that if some package has hard-coded link or include options that point to the host system, then they could conceivably be picked up, but no packages that I know of in LFS chapter 5 have this. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] grep nitpick in chapter 5
We have the switch --disable-perl-regexp which is fine, but the explanation is no longer correct. It says: This ensures that the grep program does not get linked against a Perl Compatible Regular Expression (PCRE) library that may be present on the host but will not be available once we enter the chroot environment. If the user has been following the instructions correctly, it will be impossible to link against host libs at this point. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] popt in the book?
On 6/5/12 2:05 AM, g@free.fr wrote: > This make me smile a lot. > There is much more dependencies in perl than just glibc and linux packages. > Check a bit your log with > grep -rl 'perl ' Getting perl hits in your logs does not always equate to actual dependency. Configure scripts may check for perl even if it's not required and packages may at times install supplementary perl scripts that aren't typically used at runtime. Few packages actually require perl to be present to build and/or run. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] popt in the book?
On 6/4/12 10:51 PM, Bryan Kadzban wrote: >> OK. Your distro, your rules. :) > > For the record, perl is also required for automake. Half of its > installed files (or so) are perl modules, and /usr/bin/automake is a > perl script. That's another package I would personally remove from LFS (along with libtool and autoconf). By far, most released packages don't need automake or autoconf to be run at build time, unless you're doing actual development work. For those that do, install it when/if you need it. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] popt in the book?
On 6/4/12 8:52 PM, Bruce Dubbs wrote: > "As stated earlier, the goal of LFS is to build a complete and usable > foundation-level system. This includes all packages needed to replicate > itself while providing a relatively minimal base from which to customize > a more complete system based on the choices of the user. This does not > mean that LFS is the smallest system possible. Several important > packages are included that are not strictly required." I know what the book currently says. That doesn't mean I have to agree with it or even accept it. And anyway, I said already I'm not seriously suggesting this for the main book. If I want to experiment, I'll do it elsewhere. If someone else wants to experiment and then suggest LFS do this, that's their decision. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] popt in the book?
On 6/4/12 7:54 PM, Jeremy Huntwork wrote: > On 6/4/12 7:52 PM, Andrew Benton wrote: >> So maybe it should just be installed in Chapter 5 and the Chapter 6 >> page could move to BLFS? > > If you removed the dependency in glibc and linux, you wouldn't need to > do either. Oh, I see what you mean though, if we build the minimal perl in chapter 5 we can use that for the chapter 6 glibc and linux-headers (like we already do) and not worry about perl in chapter 6. Sorry I'm a bit slow today. Still, I'd be interested in seeing what it would take to remove perl completely from LFS. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] popt in the book?
On 6/4/12 7:52 PM, Andrew Benton wrote: > So maybe it should just be installed in Chapter 5 and the Chapter 6 > page could move to BLFS? If you removed the dependency in glibc and linux, you wouldn't need to do either. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] popt in the book?
On 6/4/12 5:20 PM, DJ Lucas wrote: > On 06/04/2012 02:35 PM, Jeremy Huntwork wrote: >> (perl is another one I'd love to see removed, but I'm not going to >> seriously recommend that one :) ) > > Just curiosity, what are the necessary steps? I was pretty sure that > something obscure in either gcc or glibc builds required it, but I am > all too aware of how well fuzzy memories have served me recently! :-) The current headers-install command in the kernel tree is a perl script, but there exists a patch to replace it with a very simple shell script (and I believe the intent is to submit it upstream). Glibc also requires perl for some part of its build system, but I can't recall where offhand exactly and I don't have any recent build logs available. But I doubt it's a very big deal to remove that dependency as well. I see perl as one of those things that's necessary to have available for any serious distro, but not necessarily something I need or want installed on every machine. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] popt in the book?
On 6/4/12 3:28 PM, Bruce Dubbs wrote: > hd2u.xml: > libbonobo.xml: > libdv.xml:, > rsync.xml:, > samba3.xml:, > inkscape.xml:, > > You too can learn grep. Har har - I don't have the sources anywhere that I can grep and I figured you'd know. *shrug* Anyway, I think popt is kind of silly and I hope that it'll eventually be removed from LFS. (perl is another one I'd love to see removed, but I'm not going to seriously recommend that one :) ) JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] popt in the book?
On 6/4/12 3:06 PM, Bruce Dubbs wrote: > Jeremy Huntwork wrote: >> I thought popt was already removed from pkg-config in git? If so, why >> did we add it into the book now instead of at least applying Dan's patch >> to remove that dependency? > > Other packages use popt. If it works (appears to be ok) and can be used > by pkg-config, then we might as well do it. At least that's my conclusion. Heh, ok. I thought you were the one usually against adding anything extra into LFS. :) Personally, I don't think popt is all that useful. The standard C library provides getopt which is sufficient for most needs. No other current LFS package uses popt - how many packages in BLFS actually use popt? JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] popt in the book?
I thought popt was already removed from pkg-config in git? If so, why did we add it into the book now instead of at least applying Dan's patch to remove that dependency? JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Fix Includes [WAS: Re: Wording fix]
On 5/28/12 6:54 PM, Jeremy Huntwork wrote: > Maybe let's wait before updating anything again, just to be 100% certain > on what the right path is here, and I'll try to reach out to upstream in > the meantime to see if someone there is willing to give me an answer we > can work with. Well, I posted a question on gcc's list and got very little useful feedback. Thread starts here: http://gcc.gnu.org/ml/gcc/2012-05/msg00367.html And continues here: http://gcc.gnu.org/ml/gcc/2012-06/msg3.html In order to determine what it's 'fixing' we would need to do a review of the scripts ourselves. On the whole, for our purposes, it's probably typically safe to let the script run, but it's probably also completely unnecessary (and while rare, there is the chance of hitting a bug with it). So I'll leave it to you to decide whether to leave it as is or disable the script. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 6/1/12 9:31 AM, James Robertson wrote: > Sure. Lets take sudo as an example. What could be considered a simple > program has 8 optional dependencies with 4 being "off book". I think we > ignore those 4 and worry only for the 4 "in book" optional > dependencies. The build instructions in the main BLFS book explicitly > use two without configure parameters to get around no pam or an mta. So > I am thinking we have a few versions of this package. > > sudo-1.8.4p4-book > sudo-1.8.4p4-pam-sendmail > sudo-1.8.4p4-pam-sendmail-kerberos-ldap > > The first notates that it is a package right from the book. The second > one adds pam and leverages a local sendmail and the third has all the > "in book" optional deps. The second and third packages would been a > pre- script to check for a valid sendmail command before installation as > well. > > The spec file for each of these will be slightly different and certainly > the run time deps will be as well. > > Lets use shadow as another example. Since shadow is also in LFS, there > is a real need for more than one version. > > shadow-4.1.5-lfsbook > shadow-4.1.5-blfsbook-pam-cracklib > > or something like that. I have to admit that I didn't like this at first, because something like this would likely confuse auto-installers. For example, if we used pacman to auto-install a full base system to use as development - which version of shadow do we use? But after thinking on it some more, I think there are likely various ways to work around this and your multi-package method does fit the BLFS model more closely. > We you thinking of providing a pre-packaged kernel? That is going to be > an interesting one as we all love to customize our kernels. Present > company included. Yeah, not sure about this one. For pure (B)LFS development purposes, a packaged kernel isn't necessary at all. Perhaps we leave this as a 'build it and package it yourself' option for anyone that wants to actually use the binaries as a working system. I suppose we could still provide a template for it and let people generate their own config - the default perhaps being a very general purpose nearly-all-modules-enabled config. > I have been wanting to get back to contributing for some time and this > seems to be a great place to do it. I'm going to start by jumping on the parser, since it will be necessary right away for any of this to work. My initial thoughts are to build one parser that can accept different output filters, for example, outputting to PKGBUILD files, or rpm spec files, or even, the jhalfs-type build scriptlets. Any thoughts on that? JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN and Systemd Report
On 5/25/12 8:55 AM, Armin K. wrote: > I want to add that I've experimented with "the /usr merge" since I use > one partition for everything. I don't believe anyone commented on this part, but I'm curious. What did you do exactly to achieve "the /usr merge"? For my own experiments in LightCube I've removed /usr completely and put everything under /. Thanks, JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN and Systemd Report
On 5/31/12 6:17 PM, Jeremy Huntwork wrote: > It still amazes me that pkg-config requires any other external library. > glib1 wasn't bad since it was shipped alongside it and had no other > deps, fairly lightweight. But switching to glib2 was just ridiculous. > All that pkg-config is doing is parsing a text file and spitting out > results. Makes me want to look it over and rip out that dependency... Check these out: http://sourceforge.net/projects/pkgconfiglite/ And: https://github.com/nenolod/pkgconf JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/31/12 4:41 PM, James Robertson wrote: > I have been watching this thread and it seems to have gone a bit dormant > so maybe now is a good time to add my thoughts. First off - Jeremy, > your contributions to this project continue to amaze me. Keep it up buddy. Thanks James, :) > 1. Adding PM is NOT a replacement for the books. It should also be > noted and clear that the purpose of this effort is not to turn (B)LFS > into a binary distro. It is and always should be a cookbook so those > that want can still roll their own. I really think that this effort > should be a book development tool and cookbook for those wanting to > learn about package management. I think the current books stay as is > and PM is another off-shoot like cLFS. The books should stay > independent as they have different goals. I am thinking that we attempt > to leverage the (B)LFS book sources in some manner (maybe combine them > into a super book) and then add the PM stuff to each page (build > steps). If we go this route, we won't confuse goals and won't make the > main books too hard to read. Remember we get new users all the time. > Also by creating an off-shoot version of each book, we can go hog wild > with educational text about package management strategies, procedures, > etc and that text stays out of the main books (again because it is not > the main book's goal). Hmm, possibly. I'm wary of new projects/books (given their life span) but I also see the value in what you're saying about keeping the book unchanged. > Questions about the binary repository came up. I too have some > questions about that. What is the definition of 'official'? Who/What > is 'official'? Who is going to vet submitted binaries? What is the > standard we are going to follow? I would assume binaries compiled with > commands right out of the books with no extra optimization flags and > such, but that should be agreed upon. Yet another good reason for PM to > be a separate book. We can have a whole chapter documenting this if we > need to. Yep, all good questions. I don't know the answer yet. Perhaps the answer is to do like I suggested in another message and show a proof of concept first, then we can tackle the hard decisions as the concept gains ground. > The separate work things also aid #3 above as well. We can document the > standard workflow, tool use, etc there. Things like what you need to > get started building a book development environment, a reminder of > selection criteria used for the PM tool of our choice (just to help us > remember why a certain tool was picked as our memory fades), etc. One > tool I think we will need is a spec file generator. This goes back to > my thought about putting xml tags in the book source that is parsed out. Yep, the parser/generator will need to be one of the first things tackled. > WRT BLFS book development specifically. Lots of commentary about > dependencies - both build and run-time ones. Part of the PM project > would be to standardize how we create packages. My thinking is to > create a package for the required deps and the come up with a way to > generate other "versions" of a package with the run time deps built > in. Keeping PM in a separate book will give us this option to document > and explain. Not sure I'm following this exactly. Do you mind being a little more specific or provide an example? > I would like to contribute to this one, but won't be able to until this > fall when I can get some other things off my plate. Never seems to be > enough time to do what I want to do. Nice! Totally understood. We're all busy... some perhaps more than others. :) I look forward to working with you on it. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN and Systemd Report
On 5/31/12 6:10 PM, Andrew Benton wrote: > On Thu, 31 May 2012 22:38:21 +0100 > Jeremy Huntwork wrote: > >> Since when does glib require Python? > > I think Python's been a required dep since glib-2.32. It may be > possible to build glib without python but it will need more than > configure switches. > >> Are you using glib2? IIRC, >> pkg-config up until recently shipped with glib1 sources and built that >> in its own build system. In fact pkg-config's page says it uses >> glib-1.2.10 - that's lightweight and has no external deps. > > glib-1.2.10 is 11 years old and would probably need a lot of work to > get it to compile. It still amazes me that pkg-config requires any other external library. glib1 wasn't bad since it was shipped alongside it and had no other deps, fairly lightweight. But switching to glib2 was just ridiculous. All that pkg-config is doing is parsing a text file and spitting out results. Makes me want to look it over and rip out that dependency... JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN and Systemd Report
On 5/31/12 6:01 PM, Armin K. wrote: > pkg-config 0.26 uses glib2 and does not ship glib1 anymore. And since > LFS/BLFS tends to use latest stuff, glib 2.32 requires python for gdbus > stuff and libffi for some other stuff ... Do note that pkg-config 0.25 > can be still built flawlessly. It can be installed in temporary system, > then just symlink pkg.m4 from /tools/share/aclocal into > /usr/share/aclocal and you should be good. Hmm, if it requires glib2, then they need to update their website. At that rate, just use 0.25 - as you say, works great here, too and probably will for some time to come. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN and Systemd Report
On 5/31/12 5:32 PM, Andrew Benton wrote: >> pkk-config >> glib (required) Since when does glib require Python? Are you using glib2? IIRC, pkg-config up until recently shipped with glib1 sources and built that in its own build system. In fact pkg-config's page says it uses glib-1.2.10 - that's lightweight and has no external deps. Two possibilities 1. Add in glib1 (preferably to pkg-config's internal build like it was previously) 2. Provide a workaround for missing pkg-config in the script - it is possible since pkg-config is pretty basic stuff - it's just looking for link and include options. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Fix Includes [WAS: Re: Wording fix]
On 5/28/12 6:37 PM, Matt Burgess wrote: > On Mon, 2012-05-28 at 18:16 -0400, Jeremy Huntwork wrote: >> On 5/28/12 6:15 PM, Jeremy Huntwork wrote: >>> It's probably safer to add back the command that disables this script >>> but just make sure that our explanation for it is accurate. >> >> Oh, and sorry for the trouble here, I realize I was the one that started >> this... > > No need to apologize! I'm interested in what's made you rethink this? > I see no build issues with the few 'fixed' headers installed. If you > don't think the headers that are being fixed need to be, is it worth > reporting this as an upstream bug in the fixincludes machinery? Well it is interesting that it hasn't been dropped from their sources yet, but from talking with others who know the history as well as reading the available docs it becomes clear that the script is a hack. The idea of libc headers requiring "fixing" by the compiler is just silly. If there is something that is 'broken' in the libc headers then it should be handled appropriately upstream, and over the years, any broken headers do seem to have been appropriately handled where necessary. Maybe let's wait before updating anything again, just to be 100% certain on what the right path is here, and I'll try to reach out to upstream in the meantime to see if someone there is willing to give me an answer we can work with. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Fix Includes [WAS: Re: Wording fix]
On 5/28/12 6:15 PM, Jeremy Huntwork wrote: > I think we may have been too quick on the draw with removing this > command entirely. The reason being that this script was originally added > into gcc to "fix" non-ANSI headers in various packages. > > http://gcc.gnu.org/viewcvs/trunk/fixincludes/README-fixinc?view=markup > > Especially given the success of many recent years of LFS without 'fixed' > headers, I'd say the case of broken headers is these days extremely > rare. And because of the automated nature of the script there exists the > possibility that it actually 'fixes' things we don't need or want 'fixed'. > > It's probably safer to add back the command that disables this script > but just make sure that our explanation for it is accurate. Oh, and sorry for the trouble here, I realize I was the one that started this... JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Fix Includes [WAS: Re: Wording fix]
On 5/9/12 4:29 PM, Matt Burgess wrote: > On Wed, 2012-05-09 at 16:24 -0400, Jeremy Huntwork wrote: > >> I'll dig a bit and get back to you. > > Note that I'm busy digging too. Having fixincludes run in chapter 5 > looks safe; GCC only searches for headers under /mnt/lfs/tools/include > or /tools/include. > > I'll have results for chapter 6 tomorrow, hopefully! I think we may have been too quick on the draw with removing this command entirely. The reason being that this script was originally added into gcc to "fix" non-ANSI headers in various packages. http://gcc.gnu.org/viewcvs/trunk/fixincludes/README-fixinc?view=markup Especially given the success of many recent years of LFS without 'fixed' headers, I'd say the case of broken headers is these days extremely rare. And because of the automated nature of the script there exists the possibility that it actually 'fixes' things we don't need or want 'fixed'. It's probably safer to add back the command that disables this script but just make sure that our explanation for it is accurate. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN and Systemd Report
On 5/28/12 2:52 PM, Bruce Dubbs wrote: > The problem is that none of these libraries are used for udev. On a > recent blfs system, where the systemd dependent libraries are installed, > I as able to build and looked at the executables and libraries. AFAIK, > the only ones are /bin/udevadm, /usr/lib/systemd/systemd-udevd, > /lib/libudev.so.1.0.0 and /usr/lib/udev/*. Perhaps the best solution is to complain loudly to upstream and hope that enough do so that they build into the package the ability to build and install only the udev components as they said would be possible. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN and Systemd Report
On 5/25/12 12:51 PM, Bruce Dubbs wrote: > I suppose we will need to do a minimal install in LFS and a more > complete install with all the bells and whistles in BLFS. Sigh. There are dev alternatives, like mdev from busybox. It may at least be worth investigation to see if we can avoid the systemd craziness completely. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/20/12 7:09 PM, Ken Moffat wrote: > The more I think about this, the less happy I am. Point 2 doesn't > really help editing BLFS as far as I can see (upgrading a package > usually needs several builds - typically, for me, a first to see if > it actually works when I use it, then others to get nice clean > measurements, check what is in the DESTDIR (or INSTALLROOT), and > review options for the optional dependencies and any testsuite. Actually, from my experience a packaging tool eases a lot of the pain inherent in the process you've described. Auto-fetching of sources (including dependencies), auto-preparation of a clean build tree, post-build reports of what files have been included in the package and what (if any) auto dependencies have been discovered. Re-doing a build if issues or errors are found (including, if necessary, setting up an entire chroot system as well) becomes a matter of one command, instead of several. > Then there is the question of dependencies - in BLFS we don't > normally tell people how to use optional deps. Sometimes they are > picked up automatically, but many times you have to pass a switch to > get them used. The instructions in BLFS are hopefully correct, but > they don't suit everyone. > > I'm also wary of standard workflows - my own LFS build is different > enough (nothing updated in /sources, because that is an nfs mount on > my systems, and with efforts to remove many of the static libraries) > that I expect pain. And that's just for LFS. For BLFS, I suspect > this sort of change will actually increase my workload and therefore > reduce my contributions. This is one of those scenarios where I think it's difficult to see how a thing will be useful or beneficial until after you've actually tried it out. I'm not guaranteeing you'll think it better, more useful or simpler - though my belief is that it does actually simplify the process of correctly building and documenting the build of an individual package, once the tools are available and the infrastructure in place. > The intention is good, but I'm not at all convinced that the plan > will help. Perhaps it really is something that needs to been seen and experienced. I can do as I planned and document the procedure to build in PM with LFS and set up the basic infrastructure required (a web server with a public binary repo). Once that's in place, anyone who wants to test out the new workflow can try it and offer thoughts, comments, suggestions. Then perhaps a decision can be reached as to whether it be actually implemented for either LFS or BLFS. This way, too, at least the documentation will have been done. Anyone interested in helping with the above, or should I just report back here when I've accomplished this on my own? > Also, can I really trust whoever is permitted to edit a book (I'm > assuming that part of the aim is to get more people editing in BLFS > ?) to have an uncompromised system, and to not want to upload > compromised binaries ? For the xml in the book, and for patches, we > can look at what is being changed. For a binary, how do we know > what was done to it ? Distros have build machines with restricted > access and some degree of security. Is LFS going to need signed > binaries and a ring of trust ? This is a great question, and I'm still not sure the best way to answer it. Perhaps it should be tabled and reconsidered if and when either book looks to actually adopt the workflow as 'official'. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/20/12 7:09 PM, Ken Moffat wrote: [snip - a number of good, thoughtful questions] I'm going to have to let your questions brew for a while before I can reply to them. Perhaps someone else will have an opinion regarding them in the meantime... JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/20/12 5:34 PM, Bruce Dubbs wrote: > OK, then what's wrong with a tarball of binaries that we have created > for this purpose? There could be a tarball of the base LFS system and > then additional tarballs for certain packages or groups (e.g. xorg) of > packages. This method does not collect and keep package dependency. Using a manager like pacman, ff you have a repository with dependency baked in, when you go to build an individual tool you can automatically discover and download/install into your build environment all required packages - and only the required packages. Also, for a reader who is serious about making a distro, creating a giant tarball of the LFS base does not teach any good practices for creating and deploying a distribution of their own. Another benefit of a package manager is that changelog information can be related to individual packages and can be easier to track changes - again, this is less important in LFS, but could be useful in BLFS. If it's simplicity that you like, one advantage of pacman is that the packages themselves are actually just tar archives containing the files and metadata. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/20/12 2:18 PM, Bryan Kadzban wrote: > In other words, I think it'd help to only use packages to simplify > (mostly BLFS) testing, but make them semi-public for people who really > want them. Don't use them at all in the actual build instructions (what > would be the point? :-) ), but generate the spec files, or whatever > equivalent, from the book XML. (This last bit might be either hard or > impossible; I don't know.) Yes - I believe you have hit exactly what I'm trying to propose. The binaries (and binary repository) aren't advertised in any way for general use - they aren't even mentioned in the build instructions. For example, consider this as a very simplified version of a package page: "Build package Blah: Manually: ./configure ... make (Optionally, via package tool): # Grab generated spec file here... ./makepkg " And then the spec file, would have references to the dependency packages in BLFS, calling them exactly how they've been referenced in the book's source. I suppose here the 'optional' ones could be enabled or disabled by a reader. As would devs - although I think for dev purposes it might be useful to have built binaries with all optional dependencies enabled. Behind the scenes, a set of tools and a defined workflow can help the devs to share binaries already produced via the spec files - but those are never explicitly shared or brought to the attention of the reader. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/20/12 3:10 PM, Bruce Dubbs wrote: >> This exact reason, for the record, is why I really dislike binary >> distros. I *never* choose the same set of dependencies that are >> optional in the source, as the distro does. And because when they ran >> ./configure, they added a --with-foo flag, the package compiled with >> -lfoo, meaning the binary version of the package now has a hardcoded >> requirement for libfoo.so.N or whatever it is. > > I agree with this. I am updating vim in BLFS to add current patches and > do not like all the xorg dependencies in vim. Others may want gvim. > > There are a lot of decisions that must be made in BLFS about > dependencies. It's difficult to provide a package manager that does not > take away the user's choices. I think perhaps the point is being missed here. The purpose of the proposal (creating and providing binaries) isn't for the _reader's_ use, (if someone found them and wanted to use them that's their decision), but it's solely for making development easier and providing documentation on how to use a packaging tool for creating an actual distribution. So there is no threat here to what LFS or BLFS currently is. I absolutely agree that choice of optional dependencies should be left completely to user discretion. A decision about how to build a binary (and provide a spec file) for use by other developers should be based completely, then, on what is useful for developing BLFS. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/19/12 5:27 PM, lfs-dev.neophyte_...@ordinaryamerican.net wrote: > The "pacman" reference here is to https://wiki.archlinux.org/index.php/Pacman > not http://pacman.com/en/ > Correct? Haha. Yes, that's right. Unless you can find a way to package up distributable packages with the arcade game... JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/19/12 7:29 PM, Bruce Dubbs wrote: > Certainly you have the privs, but I would like to have the capability of > doing make DESTDIR=$DEST without being root. I don't particularly like > the developer saying "you have to be root to run install". It's my > system, not the developer's. I believe that pacman handles that with fakeroot, when not running makepkg as root. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On May 19, 2012, at 5:03 PM, Bruce Dubbs wrote: > DJ Lucas wrote: > >> I have long suggested that LFS and BLFS move to installations >> from DESTDIR (or equivalent) > > I do use DESTDIR to check the installation of most packages, but there > are some where it just doesn't work. Actually, any package that decides > to do a chown or use the -g or -o options of install is a problem, but > several just ignore DESTDIR completely. Not necessarily a problem. There's various ways to address this, depending on which PM you use. Typically you'd be building an individual package on a chroot or fake root env where you have privs to do this very type of thing. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On May 19, 2012, at 5:04 PM, Bruce Dubbs wrote: > > It's easy to create a tarball of binaries for a specific > architecture (686, x86_64, etc) and extract that to an empty partition. > A rebuild of the kernel, setting up grub, and a script to handle some > specific things (fstab, ip address, etc) would be easy enough. > > But then, I don't think of that as LFS. And it misses nearly all of the goals I'm hoping to hit with the proposal. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/19/12 1:15 PM, DJ Lucas wrote: > My hope is that build order is still a manual process where the user > determines build order herself. Dependency checking is done only at > build time and that optional deps remain optional. If there will be > automation, how do we determine what optional deps to pull in? Sorry, I meant to answer this question better in the last reply. I think I would aim to keep the BLFS book as close as it is today in terms of allowing a someone to 'choose your own path'. Where that gets interesting is how to fit that into a new workflow with shared binary packages. From what I can see, there's three options: 1. Make the policy to not build the official binaries with _any_ of the optional dependencies present. 2. Make the policy for to the dev to build with _all_ of the optional dependencies listed present. 3. Choose some 'sane' set of defaults to build against, but mark that certain ones are not strictly required. This also gets into the realm of the difference between run-time and build-time dependencies, as well as the reasons for splitting some packages into sub packages - but I'll leave those for perhaps a little later when this topic has gotten a bit more circulation. :) JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/19/12 1:21 PM, Baho Utot wrote: > I have in the past worked on LFS-6.8 and have a completed pacman build > for it. I wanted to build a desktop system from LFS/BLFS but it was too > much work for me. I have not gone further because BLFS is a beast as > you say. I completed a server using LFS/BLFS that handles mail web and > news services. Nice! > Sharing the work using pacman would be great, maybe we can exchange notes? Assuming this proposal gets some forward momentum, it's still not 100% decided that pacman is the package manager that would be used, although I would probably vote that direction. But if it is pacman, by all means, we can exchange notes. :) Thanks, JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 5/19/12 1:15 PM, DJ Lucas wrote: > What separates LFS from say Arch, Gentoo, T2... at that point? No mile > long USE flags or complex switching scripts I presume, but I know little > about the other two. I've included some of their work in BLFS in the > past, but that is about it. Well, the way I saw this working out in my head - we don't really advertise the binary package repository, although it would be available for anyone to use. Hence, "semi-public". The focus would still be on the book and letting a user choose her own path. The optional PM parts would serve as a reference for how to do something similar either with the same packaging tool, or one of the user's choice. And yet, in the background, what I'll call the "distro-y bits" would be fully functional, driving consistency in the book(s) as well as accuracy since it should serve to help identify dependencies and installed resources. If anyone chose to actually use the created and shared binaries as a full-fledged distro, they absolutely should be able to, with the knowledge that we are not providing any guarantees as to usability, reliability, or support, etc. > My hope is that build order is still a manual process where the user > determines build order herself. Dependency checking is done only at > build time and that optional deps remain optional. If there will be > automation, how do we determine what optional deps to pull in? I think that can still work. The main point of the "distro-y bits" is to make development easier, as well as provide actual documentation on how to make a binary package distro - not just a system built from source. There's a fair bit more to it than what LFS or the hints provide. > What benefits can we expect for users who have already done the leg work > to use other packaging methods? > For instance, with what is put into the book, could a logical parser be > made to genarate a spec file? How about dpkg? If we did it correctly, I think this should be possible. It would definitely be nice to keep this as a goal. However we do it, it would be wise to make the spec generator modular enough to accept different output filters. > While I admit that the .d/ directory reduces this concern immensely, > what happens to configuration files that must be modified by additional > installations? Do we keep diffs indefinitely, or do we create a comment > marker for each package's additions, modify the package to support some > sort of include directive? I can see scripting getting somewhat > difficult here, not impossible, but difficult. There's two features of most mature package managers that can help with this. First, config files can be identified in the spec so that when the version installed on the system is different than the one in the package being installed, a backup of one or the other is made, and the PM tells you what it did. So this helps preserve user modifications. Second, for config files which we might reasonably expect to be modified by various installed system packages (e.g., /etc/passwd, /etc/group), those modifications can be done through pre- or post-install scripts, as well as pre- or post-uninstall scripts. And yes, using .d directories where supported does help simplify things. > If it is to be done, it should be designed with all goals in mind from > the start. I have long suggested that LFS and BLFS move to installations > from DESTDIR (or equivalent) as this does about 60% of building your src > rpm without defining a particular package manager. The other 40% is just > transposing what is in the book to spec, and could be automated, but > even this has had lackluster support in the past despite the obvious > educational benefits. Absolutely. Looking forward to hearing more thoughts. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Once more: Package Management
I've been holding back bringing this up on-list for a while because I intended to do the bulk of the work and then present a working system to the community for comment and review. I still intend to do that, but given some recent discussions, I think the time is right to bring this up and see where it goes. (Sorry for the cross posting, but since it involves both projects, I wanted to make sure all saw it - if possible, please reply on lfs-dev.) Proposal: 1. Adjust LFS/BLFS to auto-generate build recipes for individual packages that a packaging tool can use to create binary packages with meta information included such as dependency tracking. 2. Store 'official' copies of those binary packages in a developer package repository so that when developing (primarily BLFS) a dev can automatically pull and install into a build environment the dependencies he needs to build and create an individual package. 3. Create a standard workflow and tools whereby a developer can accomplish #2 and edit the book accordingly in an efficient, reliable way. Rationale: (B)LFS-style development by hand becomes a huge undertaking. BLFS _is_ a huge undertaking - and it's a difficult beast to maintain. In order to create a stable reference page in BLFS an editor has to have spent the time to build all of LFS, tweak it, go through current BLFS, manually install dependency packages and then carefully document the package he builds. No two developers are guaranteed to have the same environment, either, so accuracy and stability becomes an issue. The same is true of the LiveCD project, and is the main reason why it sits dead today. It is difficult to maintain when there are no packaged binaries to draw from and the entire thing is a scripted source build. Let me just say now that because (B)LFS is primarily (and probably should always be) about educating, I don't think we should require end-users to use package management. Mainly the proposal is intended to assist in development. However, if we have taken the time to incorporate PM in our dev workflow, we can make the option of building via PM tools available to readers if they wish to use it for themselves and build their own package repository. Details: (The following details assume pacman is the package manager chosen, but it could conceivably be another, such as rpm5.) 1. The end of LFS chapter 5 is modified to (optionally) build the packaging tool and any dependencies it has. 2. LFS chapter 6 is modified so that for each package a build recipe (e.g. PKGBUILD file) is generated from the book's source. A reader is given the option of carrying out the build manually or via the packaging tool. 3. LFS devs create official copies of the binary packages and install them to a semi-public package repository 4. BLFS is modified to also generate build recipes (PKGBUILD files) from its source 5. As BLFS devs work on individual packages, they can use the defined workflow and tools to generate a chroot environment with only the packages they need for build-time dependencies - they can then both produce a binary version of the package as well as document what they've done, the end product being a BLFS page which will generate/correspond to the PKGBUILD file. 6. BLFS dev updates the BLFS binary package repository with the 'official' package and other devs can now draw from and use those when working on their respective package. There are, I'm sure, both positives and negatives to this proposal, and I'd like to hear everyone's thoughts. I intended to do all the development in the jh branch, but if there are more parties interested in helping this development, then I'm also open to sharing the workload and perhaps creating an environment where this can be done together. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] kbd
On 5/18/12 3:36 PM, Qrux wrote: > I'll let you and Bruce continue on about experimentation, etc. I would > ordinarily chime in (and suggest probably more flame-worthy stuff like > moving to git would foster more experimentation, because the effort of > merging would be front-loaded on forkers--not trunk maintainers) but > I'll take a break for a bit, and wait until this episode cools off. I would love to see the project move from subversion to git. I'll continue to poke at that one from time to time as well... JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] kbd
On 5/18/12 12:34 PM, Jeremy Huntwork wrote: > I agree with all these points, but being stable and > re-thinking/experimenting are not mutually exclusive. Again, it's a > matter of process and organization. But the typical behavior I've seen > is to nay-say new ideas because it does not fit in with the tradition > and the expectation of what the current-stable book is, instead of > encouraging a platform for new ideas and experimentation. Perhaps this > stems from the assumption that there are too few hands to do the work > involved to develop and support - but chasing away ideas also chases > away the hands to do the work. I should acknowledge here that it was very flexible indeed to re-create a branch for me that allows me to do experimental work. I suppose what I am really after is that as a community we provide more means/avenues to foster experimental thinking where appropriate. If you have any suggestions on how to do this, I'd love to hear them. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] kbd
On 5/18/12 11:37 AM, Bruce Dubbs wrote: > Jeremy, I think you overstate the issues. To me, LFS is a leading edge > system, > but not a bleeding edge system. On one hand we try to keep up to date with > the > current package releases, but we try to stay away from intermediate versions > that lie in the respective version control systems. To produce a leading edge system, you need to do some bleeding edge work. How that process leads to stability is a matter of organization and development, but in my experience, LFS (as it is today) shies away from any experimentation unless the larger distros are implementing some new standard. > In some cases we are very proactive. We were one of the first to adopt the > /run > directory. > > Others use a sledgehammer like systemd when the value for most users is small. > We resist those changes. Likewise, we resist making an initrd mandatory or > having /usr mounted as a requirement for booting. > > Some of the 'advances' take away capabilities. I feel that we should continue > to provide options for the users. > > I agree that the Linux wold needs thought/energy and experimentation, but it > also needs a stable base from which to launch those new ideas. I agree with all these points, but being stable and re-thinking/experimenting are not mutually exclusive. Again, it's a matter of process and organization. But the typical behavior I've seen is to nay-say new ideas because it does not fit in with the tradition and the expectation of what the current-stable book is, instead of encouraging a platform for new ideas and experimentation. Perhaps this stems from the assumption that there are too few hands to do the work involved to develop and support - but chasing away ideas also chases away the hands to do the work. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] kbd
On 5/18/12 5:22 AM, Qrux wrote: > But, let's not make it a crime to clarify. If Ken would rather assert > that I'm not "new" to the community, then to the extent that his > assertion is valid I'd say that I see a lot of GroupThink(TM) in LFS. > Most is probably good. But there are often ruffled feathers when > long-held assumptions from time immemorial are questioned. I figure > decisions about LFS aren't usually proofs. It stands to reason, then > that those decisions can be questioned. I could be wrong, but I think what is happening is that the length and style of your emails reads as a bit aggressive and ends up being a little off-putting. I do agree with you on at least one point - there tends to be an attitude here in LFS-land of "if it's not broken, don't fix it." I think this is fine where truly valid, i.e., the current methods do exactly what is expected and modifying it provides no gain. However, I think this principle is often misapplied for two main reasons: 1. People assume what end-users expect out of LFS with little or no backing evidence. (Note this one can be applied to both sides of this particular discussion.) 2. Tradition outranks reason (this has been systemic of much of the open source world, not just LFS) - we've done it this way for years, people expect it to be this way, this is how it will always be. To get past both of these, I think we really just need to get over ourselves. LFS is huge - larger than we know because we don't always get feedback from those that read and implement - and it's impact is huge. We should take this into more consideration... The world is not a static place, especially the world of computing. Just because we've done something a certain way for a long time and it brought us successfully to this point doesn't mean that there is not now a compelling reason to do it differently. Perhaps we chose this method previously because there were no better alternatives at the time? I think it's a mistake to say "LFS is done and only in maintenance mode" because they way people use and interact with computers changes - even in the Linux world. LFS needs more thought/energy and experimentation. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Suggestion
On 5/9/12 4:43 PM, Bruce Dubbs wrote: > Total 5 minutes + 42 seconds Yes, the actual machine time is not as great a savings as I would like, however it does make a huge dent in user time for manual builds - no matter what, everyone goes through the manual build process of LFS at least once - this makes it somewhat less of a beast. Also, the CMMI learning experience in LFS is great enough that I don't think cutting out 13 packages in chapter 5 is going to hurt that. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Suggestion
On 5/9/12 4:38 PM, Matt Burgess wrote: > The only concern I would have is whether or not the use of busybox will > alter the results of any configure scripts. Assuming testing shows it > doesn't, then I've no objections at all to a mockup with a view to > getting this merged relatively quickly. Yes, we would want to run some tests to make sure the effect on chapter 6 is marginal at most - after all, for example, busybox's awk != gawk, and the shell is not bash (although they claim to have some bash compatible extensions). However, I've already been experimenting with busybox in other places and I think it should do just fine for our chapter 5 needs. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Wording fix
On 5/9/12 4:29 PM, Matt Burgess wrote: > On Wed, 2012-05-09 at 16:24 -0400, Jeremy Huntwork wrote: > >> I'll dig a bit and get back to you. > > Note that I'm busy digging too. Having fixincludes run in chapter 5 > looks safe; GCC only searches for headers under /mnt/lfs/tools/include > or /tools/include. > > I'll have results for chapter 6 tomorrow, hopefully! OK, great. That saves me from having to do it. :) JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Wording fix
On 5/8/12 2:54 AM, Matt Burgess wrote: >> If so, then all that section about fixincludes can be dropped from pass 2. > > Are we only talking about changing pass 2 here? We also have a sed in > the final build of GCC in chapter 6 with the following explanatory text: > > "The fixincludes script is known to occasionally erroneously attempt to > "fix" the system headers installed so far. As the headers up to this > point are known to not require fixing, issue the following command to > prevent the fixincludes script from running:" I should take some time to fully evaluate this and send in my results. > I'm a little nervous about that paragraph; are we absolutely certain > that the headers we've installed so far will never need fixing up? I'll dig a bit and get back to you. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Suggestion
Greetings all, Consider two things: 1. We all hate long build times. Anything we can (reasonably and accurately do) to speed up the build we do. 2. Chapter 5 are a set of throwaway tools (in some cases we only build just what we want out of those tools, again, for sake of speed, i.e., gettext) Given the above, why don't we use busybox in chapter 5? If we standardize a config we could get rid of 12 packages in chapter 5, namely: ncurses, bash, bzip2, coreutils, diffutils, findutils, gawk, grep, gzip, sed, tar, xz. Possibly 13, patch, although the last time I tested busybox's patch it didn't quite work as hoped, but it's possible it is fixed now. In addition to being able to drop those packages, you also get free of charge a vi editor and wget utility for use in chroot. Thoughts? If interested, I could start a mockup in the jh branch. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Wording fix
On 5/7/12 7:04 PM, Matt Burgess wrote:
> There's a comment in linux/a.out.h that it fixed
> up /tools/include/a.out.h so that looks OK. syslimits.h just includes
> limits.sh, so that looks fine too. limits.h has been fixed but there's
> no indication of which limits.h was used as input to it. I can only
> assume it was /tools/include/limits.h due to the a.out.h fix and the
> fact that no other headers from my host's devel packages have ended up
> being fixed up.
Yep it goes like this:
#include -> gcc internal limits.h -> system limits.h
I'm pretty certain that we're safe to remove it here; two final checks
could put this to bed:
pre-pass2:
echo 'main (){}' | $LFS_TGT-gcc -x c - -v | grep -i include
post-pass2:
echo 'main (){}' | cc -x c - -v | grep -i include
And just confirm that both are only looking for paths in $LFS/tools or
/tools - nothing on the host system.
If so, then all that section about fixincludes can be dropped from pass 2.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Wording fix
On May 5, 2012, at 10:24 AM, Jeremy Huntwork < jhuntw...@lightcubesolutions.com> wrote: Looks like I missed some necessary text changes. There's also this statement made regarding the fixincludes script in GCC pass 2: "In fact, running this script may actually pollute the build environment by installing fixed headers from the host system into GCC's private include directory" That may no longer be true. In fact it would be nice if we can confirm this. Anyone willing to poke a bit there and see if touching this fixincludes script is still necessary? Also, very minor, but there's an extra space at the top of binutils pass 2 configure command. JH * * * * -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Wording fix
Looks like I missed some necessary text changes. At the bottom of chapter 5 glibc, in the sanity check box, the following sentences are no longer accurate and can be removed: "Something may have gone wrong with the specs file amendment above. In this case, redo the specs file amendment, being careful to copy-and-paste the commands." Thanks, JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Nitpick on the jh merge
On 26 Apr 2012, at 15:10, Ken Moffat wrote: > I've got a diff of chapter06/adjusting.xml from trunk/BOOK to > branches/jh which looks as if it will do the right thing. I can > apply it if you like ? Sure - there's also these two minor ones: Index: chapter05/gcc-pass2.xml === --- chapter05/gcc-pass2.xml (revision 9832) +++ chapter05/gcc-pass2.xml (working copy) @@ -120,7 +120,7 @@ Now prepare GCC for compilation: -CC="$LFS_TGT-gcc" \ +CC=$LFS_TGT-gcc \ AR=$LFS_TGT-ar \ RANLIB=$LFS_TGT-ranlib \ ../gcc-&gcc-version;/configure \ Index: chapter05/binutils-pass2.xml === --- chapter05/binutils-pass2.xml(revision 9832) +++ chapter05/binutils-pass2.xml(working copy) @@ -67,7 +67,7 @@ The meaning of the new configure options: -CC="$LFS_TGT-gcc" AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib +CC=$LFS_TGT-gcc AR=$LFS_TGT-ar RANLIB=$LFS_TGT-ranlib Because this is really a native build of Binutils, setting these variables ensures that the build system uses the cross-compiler and JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Nitpick on the jh merge
On 26 Apr 2012, at 14:02, Ken Moffat wrote: > Compare > http://www.linuxfromscratch.org/lfs/view/development/chapter06/readjusting.html > to > http://www.linuxfromscratch.org/lfs/view/jh/chapter06/adjusting.html I think it was a bad svn merge. Let me see if I can fix. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Cherry picking r9818 and r9822 for trunk
On 4/23/12 11:42 PM, Bruce Dubbs wrote: > That's it. I think Jeremy has done a great job. Thanks :) glad it worked well for you. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Cherry picking r9818 and r9822 for trunk
On 4/23/12 4:33 PM, Matt Burgess wrote: > The fix for this is to add > --with-native-system-header-dir=/tools/include to GCC's pass1 and pass2 > builds so that it doesn't look at /usr/include at all. For the current build method, I think it's only required for pass 2. Given the difference of our pass 1 builds, I'm uncertain of the effect of passing that switch in for pass 1 with the current method. I believe Pierre confirmed it working added to pass2 only. > In addition, --without-cloog and --without-ppl can be removed as they > don't do anything useful. > > Jeremy, my gut feeling is that your proposed build method changes may > well make it into trunk fairly shortly, but in the mean time I'd like to > take the above mentioned commits as they fix known issues and are as > applicable to the old build method as the new (i.e. they don't require > any of your other changes in order to be applied to trunk). > > Any objections? Nope! JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Minor nitpick
On 4/23/12 1:11 PM, Pierre Labastie wrote: > The reason is that /tools/bin/su cannot work for a normal user, > because the setuid bit cannot be set at install in chapter 5 (if > installing as user lfs). Hence the choice of naming it su-tools, to > prevent it to run (and fail) if the lfs user (who has a PATH beginning > with /tools/bin) runs su to become root. Yep! Maybe it's OK to leave it as Matt has changed it (to /tools/bin/su) but add a large warning about it on the coreutils page. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Minor nitpick
On 4/23/12 12:45 PM, Jeremy Huntwork wrote: > This changelog entry on 2012-04-05 isn't quite correct. It reads: > > [matthew] - Use su from chapter 6 Coreutils in the Bash instructions, > instead of the one from chapter 5. Install su as su rather than su-tools > in chapter 5. Fixes #3057. > > coreutils in chapter 6 doesn't install su. So the su you're using for > tests all throughout chapter 6 is the one we explicitly install from > chapter 5 coreutils. su is installed in chapter 6 by the shadow package. > > I can't recall offhand why we chose to use su-tools originally. Probably > just as a nominal reminder that we were using the one in /tools. :) A, memory refreshed: http://wiki.linuxfromscratch.org/lfs/ticket/1877 I knew there was a reason we named it su-tools :) The link Dan provides to Greg's warning in DIY has moved, but basically it's a reminder that su, even though we installed it, can't be used to actually elevate privileges because it lacks the setuid bit. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Minor nitpick
This changelog entry on 2012-04-05 isn't quite correct. It reads: [matthew] - Use su from chapter 6 Coreutils in the Bash instructions, instead of the one from chapter 5. Install su as su rather than su-tools in chapter 5. Fixes #3057. coreutils in chapter 6 doesn't install su. So the su you're using for tests all throughout chapter 6 is the one we explicitly install from chapter 5 coreutils. su is installed in chapter 6 by the shadow package. I can't recall offhand why we chose to use su-tools originally. Probably just as a nominal reminder that we were using the one in /tools. :) If I get a chance, just for curiosity, I'll see if I can look up that thread. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Summary of changes in JH toolchain proposal
On 4/23/12 12:28 PM, Bruce Dubbs wrote: > I also think we will need a paragraph or two in the "What's New" section > explaining the changes. Yeah, that might be good. Also a review of section 5.2 to make sure all statements there are still correct. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Summary of changes in JH toolchain proposal
On 4/23/12 12:00 PM, Jeremy Huntwork wrote: > The --with-native-system-header-dir=/tools/include option is actually an > addition, not a removal. Everything else looks like it's correct, Bruce. > (I think I forgot to remove the startfiles patch from chapter 3 and the > patches.ent. I'll take a l Wow, my computer hates me... Anyway, fixing up those minor issues now. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Summary of changes in JH toolchain proposal
On 4/22/12 11:36 PM, Bruce Dubbs wrote: > gcc-pass2 [snip] > Configure: > Remove -B/tools/lib/ from CC > Remove configure options > --with-native-system-header-dir=/tools/include > --without-ppl > --without-cloog The --with-native-system-header-dir=/tools/include option is actually an addition, not a removal. Everything else looks like it's correct, Bruce. (I think I forgot to remove the startfiles patch from chapter 3 and the patches.ent. I'll take a l -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] --without-ppl and --without-cloog
On 4/22/12 6:44 PM, DJ Lucas wrote: > I'm not entirely positive, it's been a few years, but there was no need > to compile unnecessary additions that eat up time. Granted, it is a very > small savings in the grand scheme. That was the goal of those switches > and several others at the time that GCC started requiring mpc, mpfr, and > gpc (and when it was decided to exclude Cloog and PPL). Yeah, it would add _slightly_ to the compile time to link in those features, but I can't see it making a difference on modern hardware. Whether the resultant gcc actually operates slower is another question, although I doubt that too is significant, if so. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] minor
On 4/22/12 6:41 PM, Jeremy Huntwork wrote: woops, that wasn't supposed to send. Turned out to be a very minor thread after all. :) JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] minor
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] --without-ppl and --without-cloog
On 4/22/12 6:00 PM, Matt Burgess wrote: > Given your reasoning, I don't see why they're needed either, but #2723 > explicitly mentioned link errors (although conveniently failed to copy > and paste them). Now, admittedly, I never saw those errors myself, but > then I only test on one arch on one host distro, and there have been > several occasions where things like this have been host specific. > > I don't mind taking these out from trunk, and hope that any > host-specific issues are picked up during the next RC phase, if not > before. Thanks, I removed them from the jh branch. FYI, Bruce set up a job to render the jh branch daily, should be located here: http://www.linuxfromscratch.org/lfs/view/jh/ For the moment it only has the changes already discussed. In the future, it may have more radical changes, we'll see. :) JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] --without-ppl and --without-cloog
On 4/22/12 5:59 PM, DJ Lucas wrote: > On 04/22/2012 04:35 PM, Jeremy Huntwork wrote: >> So, I'm seeing that you have the aforementioned switches in both pass 1 >> and pass 2 gcc and I'm trying to understand exactly why. > > In pass1 it simply speeds up the build How does it speed up the build? JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] --without-ppl and --without-cloog
So, I'm seeing that you have the aforementioned switches in both pass 1 and pass 2 gcc and I'm trying to understand exactly why. Here's the changeset that introduced them: http://wiki.linuxfromscratch.org/lfs/changeset/9349 And here's the ticket that started that ball rolling: http://wiki.linuxfromscratch.org/lfs/ticket/2723 I don't think those switches are necessary for either scenario. For pass 1, we're building a throwaway cross-compiler that is intended to run on the host system. If it gets linked against libraries on the host, so what? Those libraries will just be for runtime of that one compiler and then will be gone by pass2 of gcc and should not affect at all the building of glibc or the next versions of binutils and gcc. Now granted, leaving those switches in doesn't hurt, but the explanation currently given in pass 1 is misleading. It says: "These switches prevent GCC from building against the PPL and CLooG libraries which may be present on the host system, but will not be available in the chroot environment." Doesn't matter. That gcc won't be present in the chroot environment either. For pass 2: it gets built by the pass 1 compiler, but that should by that point already be configured to look exclusively in /tools for libs and headers. There is no way it can link against a cloog or ppl on the host. If it does, there's a problem with the instructions or with the way the user has followed the instructions. So given that... I don't see a need to have those switches for either pass 1 or pass 2. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 4/22/12 4:09 PM, Jeremy Huntwork wrote: > So CROSS_SYSTEM_HEADER_DIR should get set correctly if we've already > specified NATIVE_SYSTEM_HEADER_DIR, which is what gets set via your switch. > > I'll just fix up the jh branch source and give another run and compare > results. Looks good, committing the change to the jh branch. Thanks Pierre. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 4/22/12 3:48 PM, Pierre Labastie wrote:
> I think the sysroot method can be simplified if using the switch above:
> you do not even need the part:
>
> cp gcc/Makefile.in{,.orig}
> sed '/^CROSS_SYSTEM_HEADER_DIR/s@= .*@= /tools/include@' \
> gcc/Makefile.in.orig> gcc/Makefile.in
> cp gcc/cppdefault.c{,.orig}
> sed '/#define STANDARD_INCLUDE_DIR/s@"/usr/include"@0@g' \
> gcc/cppdefault.c.orig> gcc/cppdefault.c
>
>
> Suppressing that and adding the switch (to both gcc passes) to the
> sysroot method,
> I have been able to build and test that there is no differences in the
> resulting system
> with the SVN build (with switch).
Nice, it looks like you're right. This is in the gcc/configure script:
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
So CROSS_SYSTEM_HEADER_DIR should get set correctly if we've already
specified NATIVE_SYSTEM_HEADER_DIR, which is what gets set via your switch.
I'll just fix up the jh branch source and give another run and compare
results.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 4/22/12 3:48 PM, Pierre Labastie wrote:
> cp gcc/Makefile.in{,.orig}
> sed '/^CROSS_SYSTEM_HEADER_DIR/s@= .*@= /tools/include@' \
> gcc/Makefile.in.orig> gcc/Makefile.in
> cp gcc/cppdefault.c{,.orig}
> sed '/#define STANDARD_INCLUDE_DIR/s@"/usr/include"@0@g' \
> gcc/cppdefault.c.orig> gcc/cppdefault.c
Well the STANDARD_INCLUDE_DIR constant isn't even used by gcc-4.7.0, so
I've already dropped that from the jh branch:
http://www.linuxfromscratch.org/~jhuntwork/sysroot/chapter05/gcc-pass2.html
The CROSS_SYSTEM_HEADER_DIR is used for pass1 gcc and
NATIVE_SYSTEM_HEADER_DIR is used for pass2. If the configure switch you
propose does effectively the same thing for pass2, I don't mind using it.
What about pass1? Is there a corresponding switch? I haven't
investigated 4.7.0 too deeply yet.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 4/22/12 2:52 PM, Jeremy Huntwork wrote:
> On 4/22/12 2:49 PM, Pierre Labastie wrote:
>> Solution:
>> add the switch --with-native-system-header-dir=/tools/include to
>> gcc-pass2 configure command.
>> I've been building ten times on various (virtual) hosts with this switch
>> without a problem.
>
> I believe the proposed sysroot method also fixes this. I'm just
> verifying this specific test case now.
Verified: the jh branch (with the sysroot method) builds correctly,
ncurses doesn't see gpm.h
echo 'main(){}' | /tools/bin/gcc -x c - -v -Wl,--verbose
#include "..." search starts here:
#include <...> search starts here:
/mnt/lfs/build/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
/mnt/lfs/build/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
/tools/include
End of search list.
So to be clear, Pierre is correct in that there is a serious flaw in the
current LFS SVN. In fact, until this gets resolved LFS SVN should be
considered completely broken. Having a chapter 5 toolchain that searches
/usr/include kills the purpose of building a separate temporary
toolchain at all.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 4/22/12 2:49 PM, Pierre Labastie wrote: > Solution: > add the switch --with-native-system-header-dir=/tools/include to > gcc-pass2 configure command. > I've been building ten times on various (virtual) hosts with this switch > without a problem. I believe the proposed sysroot method also fixes this. I'm just verifying this specific test case now. At the least, LFS should do the above (if that does indeed completely remove /usr/include from the header search paths), but I'd still like to see it go the sysroot route due to the fact that it avoids the startfile revert patch and the first adjusting the toolchain phase. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 4/22/12 2:35 PM, Jeremy Huntwork wrote:
> On 4/22/12 2:25 PM, Jeremy Huntwork wrote:
>> On 4/22/12 2:23 PM, DJ Lucas wrote:
>>> As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
>>> not a symlink, but rather a linker script that points to another linker
>>> script that points to an invalid destination (ie: no 64bit libgpm). I
>>> was going to close as invalid, but then I wondered if we want our
>>> chapter 5 ncurses linked to something that does not exist in the chroot
>>> environment?
>>
>> Yes, that's the point, we don't - and I don't think the chapter 5
>> toolchain should even be aware of what is in /usr so if it is, there's a
>> problem somewhere.
>
> I was just able to reproduce your issue. Going to dig in a bit more now
> and see if we can't find out why it's being found at all.
This is why it's seeing it:
checking if you want to link with the GPM mouse library... maybe
checking for gpm.h... yes
echo 'main(){}' | /tools/bin/gcc -x c - -v -Wl,--verbose
...
#include "..." search starts here:
#include <...> search starts here:
/mnt/lfs/build/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
/mnt/lfs/build/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
/tools/include
/usr/include
End of search list.
...
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 4/22/12 2:35 PM, Bruce Dubbs wrote: > It only makes a difference if we are going to actually use ncurses > functionality > between the time we bould it in Chapter 5 and Chapter 6. Otherwise we are > just > linking to the libraries. > > However, I don't have a problem with adding --without-gpm to just avoid > questions like this. Please wait before doing this... I actually have a problem with it ;) it shouldn't be happening. Let me dig in a bit first, please before we make any decisions here. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 4/22/12 2:25 PM, Jeremy Huntwork wrote: > On 4/22/12 2:23 PM, DJ Lucas wrote: >> As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is >> not a symlink, but rather a linker script that points to another linker >> script that points to an invalid destination (ie: no 64bit libgpm). I >> was going to close as invalid, but then I wondered if we want our >> chapter 5 ncurses linked to something that does not exist in the chroot >> environment? > > Yes, that's the point, we don't - and I don't think the chapter 5 > toolchain should even be aware of what is in /usr so if it is, there's a > problem somewhere. I was just able to reproduce your issue. Going to dig in a bit more now and see if we can't find out why it's being found at all. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 4/22/12 2:23 PM, DJ Lucas wrote: > As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is > not a symlink, but rather a linker script that points to another linker > script that points to an invalid destination (ie: no 64bit libgpm). I > was going to close as invalid, but then I wondered if we want our > chapter 5 ncurses linked to something that does not exist in the chroot > environment? Yes, that's the point, we don't - and I don't think the chapter 5 toolchain should even be aware of what is in /usr so if it is, there's a problem somewhere. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] [lfs-book] [LFS Trac] #3066: Chapter 5 ncurses fails with (old?) gpm on host
On 4/22/12 11:33 AM, LFS Trac wrote: > #3066: Chapter 5 ncurses fails with (old?) gpm on host > -+-- > Reporter: dj@… | Owner: lfs-book@… > Type: task | Status: new > Priority: normal | Milestone: 7.2 > Component: Book | Version: SVN > Severity: normal |Keywords: > -+-- > Host system is again Gentoo Live DVD 2011. I had to add --without-gpm to > the configure flags to get around it. (I tried updating the ticket in trac, but that required me resetting my password and now the site puts me in an infinite redirect loop... trac is being wonky) Anyway, unless ncurses is doing something non-standard to detect gpm, I don't think this should be happening. The point of the chapter 5 toolchain is to remove /usr or anything like it from the search paths. DJ can you dig in the logs to find out what ncurses is doing to detect gpm? In the meantime, I've downloaded the gentoo live dvd and am going to play a bit. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Serious regression with gcc-4.7.0
On 3/29/12 3:54 PM, Pierre Labastie wrote: > Le 29/03/2012 19:13, Pierre Labastie a écrit : >> Hi, >> >> #include "..." search starts here: >> #include<...> search starts here: >> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include >> >> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed >> /tools/include >> /usr/include >> End of search list. >> [...] > Adding --with-native-system-header-dir=/tools/include seems to solve the > issue. > I still have to try a full build. Was with the book's current build method or with the one I proposed? JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Coreutils uname patch for all arches
On Mar 28, 2012, at 9:37 PM, DJ Lucas wrote: > Drop is better for the book. +1 JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] pass1 gcc 4.7.0 glibc 2.15 fails
On 3/22/12 6:01 PM, Pierre Labastie wrote:
> Why do you use :
>
> + make install_root=/tools install?
>
> With --prefix=/tools, all the files are installed in
> /tools/tools/{lib,include}
>
> Of course the sanity check fails, because it looks for files in
> /tools/{lib,include}
Yep, thanks, I think that's it - I didn't look at his full log before I
replied - so I see he actually made it through the install and it's the
sanity check that fails... Nice spot.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] pass1 gcc 4.7.0 glibc 2.15 fails
On 3/22/12 5:43 PM, Thierry Nuttens wrote: > In file included from /mnt/lfs/tools/include/features.h:382:0, > from /mnt/lfs/tools/include/limits.h:27, > from > /mnt/lfs/tools/bin/../lib/gcc/x86_64-lfs-linux-gnu/4.7.0/include-fixed/limits.h:169, > from > /mnt/lfs/tools/bin/../lib/gcc/x86_64-lfs-linux-gnu/4.7.0/include-fixed/syslimits.h:7, > from > /mnt/lfs/tools/bin/../lib/gcc/x86_64-lfs-linux-gnu/4.7.0/include-fixed/limits.h:34, > from dummy.c:1: > /mnt/lfs/tools/include/gnu/stubs.h:9:27: fatal error: gnu/stubs-64.h: No such > file or directory > > > The completed log is here > > http://orchidman.dyndns-server.com/log/sekong/x86_64/pass1/gcc-4.7.0/07_glibc.log > > Note that I used Jeremy method's > > http://linuxfromscratch.org/~jhuntwork/sysroot/ At a quick glance, it looks like you have a /tools/include/limits.h file already which shouldn't be there - that will get put into place after you've compiled and installed glibc. Double check your gcc pass1 commands, that they match what is in the book. I didn't get a chance yet to update my changes with the new versions of gcc and glibc - I'll aim to do that soon. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On 3/18/12 6:44 PM, Bryan Kadzban wrote: > Well, from the comments in the book, it's not libc; it's crt1/crt0/crtn, > or whatever the files are named these days. Yes, you are correct, it's the start files it can't find. I was just being imprecise. > One other thing I'm concerned about is enabling multilib for my own > builds, if we do this setup, without having to go all the way into the > CLFS (IMO-)crazy with cloog and ppl and eglibc and whatever else. I > might be able to get away with simply removing --disable-multilib, and > then building all the libraries twice with the proper -m flags, but it's > been a while and I don't remember for sure. :-/ (OTOH it may be quite > a while before I rebuild this system.) Yes, multilib still works well, just remove the lib64 symlinks, make real lib64 dirs, kill the --disable-multilib flags and build 32-bit glibc. I find I don't typically need any other 32-bit libs - but that may be just my needs. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On 3/17/12 8:25 PM, Bruce Dubbs wrote: > Jeremy Huntwork wrote: >> I killed the jh branch some weeks back (I don't think I had touched it >> since 2008) but we could re-create it again, if you like. > > Sure. I just re-created it. Great, thanks. > Do you want me to set up a daily build? Not just yet. When I'm ready for that I'll reach out, thanks. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On 3/17/12 5:38 PM, Bruce Dubbs wrote: > Until gcc-4.7 comes out I'm recommending we use the exiting jh branch of > lfs and go ahead and put in these changes now with the release candidate > packages. Then we can do some jhalfs style builds and test things out > from there. When the new tool chain packages are released, we can then > merge them into svn with more confidence. I killed the jh branch some weeks back (I don't think I had touched it since 2008) but we could re-create it again, if you like. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On 3/16/12 3:22 AM, Bryan Kadzban wrote:
> Removing the need for adjusting the toolchain does seem to hurt
> teaching; we're using some magic flags instead of editing the specs
> file. (OTOH the specs file is now more of a builtin thing in the gcc
> driver. I do still think it's useful to know about it, though.) We're
> still rebuilding ld, though.
And we adjust the toolchain still in chapter 6, using the specs file, so
this knowledge isn't lost.
> That being said, is editing the pass1 gcc sources with sed (editing the
> STANDARD_STARTFILE_PREFIX_? values, and the header directories) better,
> or worse, than reverting upstream changes in pass2? I don't suppose
> there's a way to avoid both; that'd be too easy. :-)
The word revert alone should raise red flags. :) Also, keep in mind that
with the current build method, even after we adjust the toolchain, we
_still_ have to use -B to get the compiler to work properly. I'm not
saying there's something inherently wrong with -B, but I think it shows
that the method is broken - our compiler should be fully configured to
know and find our temporary libc on its own.
> (And I don't know enough about what limits.h is doing to know whether
> that edit is a good one or not.)
This is because gcc always searches its internal fixed headers first -
and those headers will always include a version of limits.h, even if we
aren't running the fixincludes script. If, when building gcc, it finds a
copy of limits.h in its search path, then it will append and prepend to
its limits.h logic to have it include_next the system limits.h
I actually see this as a good thing. GCC is so confined to the sysroot
location that it _can't_ pick up anything from the host, it just adds a
minimal limits.h file instead.
The second pass of gcc (the full one with shared libgcc and c++)
actually needs things defined from libc so you need to do one of two things:
1) Hard code an include to /tools/include/limits.h in gcc's code
2) Do what gcc would have done on the first round if it found the system
limits.h and append and prepend the logic to include_next
Here's the actual code in gcc that does this:
# Test to see whether exists in the system header files.
LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ]
...and then...
if $(LIMITS_H_TEST) ; then \
cat $(srcdir)/limitx.h $(srcdir)/glimits.h
$(srcdir)/limity.h > tmp-xlimits.h; \
else \
cat $(srcdir)/glimits.h > tmp-xlimits.h; \
fi;
> As for searching the host, I'm not entirely sure which way to go there.
> What does the current-book pass1 gcc binary say, if you do something like:
>
> echo 'main(){}' | /whatever/gcc -v -xc -Wl,-verbose -
>
> for the include path order and the linker SEARCH_DIR()s? Where does it
> find crt1.o, libgcc, libc, ld-linux.so.2 (or the 64-bit ld.so), etc.?
> How does that compare to the sysroot pass1 build? (I assume there's no
> change in the chapter 6 build, or ICA should pick it up. The pass2
> build is not likely to be that different, although that might be
> interesting to double check as well.)
I had this, but can't seem to find the logs at the moment... I'll try to
re-gen and provide an answer shortly.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On 3/14/12 11:32 PM, Bryan Kadzban wrote: > It *almost* looks like sysroot is the equivalent of a DESTDIR install, > where all the libs are installed into/whatever/path, > but ask for /whatever/path at runtime (e.g. when ld.so is looking for > DT_NEEDED entries, or in DT_RPATH entries in libs themselves, or when > the new compiler is run and it tries to find includes) -- is that > accurate, or not really? Yes, it's like that. If you configure sysroot to be /mnt/lfs then by default gcc will look in /mnt/lfs/usr/include, etc. for system headers and so on. But in the proposed method, because we've also swapped out all hard coded instances of /usr and /lib to be /tools and /tools/lib, then sysroot is actually configured for /mnt/lfs/tools/include etc. Which is all good, it's just enough to get our libc running and then we build a native compiler and linker that looks in /tools and not /mnt/lfs/tools > (I assume your home directory on quantum still has the current proposed > diffs?) Yes. http://linuxfromscratch.org/~jhuntwork/sysroot/ > > > If upstream does endorse sysroot as the way all cross compilers should > be built, I'm not sure I buy that argument. (But that might just be > because it's different. :-/) I'm also not sure if they actually do; > I've heard both this and its opposite asserted. It's true, we aren't building a full cross compiler, nor am I proposing we make full advantage of what sysroot is intended for (although it is conceivable to cross build your entire system and bypass chapter 5 completely, I think CLFS has done this). However, upstream has provided the functionality, and their devs have evaluated our cross->native build method and said 'use sysroot'. Greg says I'm hanging on to this fact 'doggedly', but I think it's an important consideration. And I disagree that our needs are so foreign to toolchain devs - they may not have the same goals and motivation as we do, but they will definitely understand what we are trying to achieve and are therefore some of the best people to offer technical opinions. > If I understand what it is, then I think sysroot is a good idea for real > cross compilation, where the host can't execute binaries built for the > target, because you'll need a different ld.so. But we're not doing > that, either, except possibly when converting from a 32-bit system under > a 32-bit kernel, to a 64-bit system (either multilib or pure64); the old > kernel won't load the new binaries. No, we're not - but we are trying to keep anything from the host 'out'. We go to great lengths to make sure that the toolchain is kept 'clean' from the host system and from what I've seen, this is the best way to do it. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On 3/17/12 12:26 PM, Bruce Dubbs wrote: > Jeremy Huntwork wrote: > >> Everyone else, please do review all of the links and posts that Greg >> provided. It was mostly reading those (and bits of the source) as well >> as the tests/experimentation that convinced me that the proposed method >> is solid. > > Jeremy, > Matt and I are very reluctant to change a working implementation. > From what we can gather, gcc-4.7/glibc-2.15(?) changes things and will > require some LFS changes. We need to be concentrating on that. Actually now is a great time to change. I bet you'll have less issues trying to get the proposed method to work with the new versions of gcc and glibc than you will with the current method. In fact, I've just tested my proposed changes with the gcc-4.7.0 release candidate and the tagged glibc-2.15 branch and it went beautifully. I even get to remove one of the seds I proposed because gcc-4.7.0 is not using the STANDARD_INCLUDE_DIR macro. The only things I had to do differently was re-gen the cpuid patch for glibc and add libc_cv_ctors_header=yes to the end of the glibc configure (as per this thread: http://www.linuxfromscratch.org/pipermail/lfs-dev/2011-August/064955.html), things that would need to be done regardless. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] I give a try with glibc 2.14.1 and gcc 4.7.0-RC-20120314
On Mar 17, 2012, at 11:11 AM, Thierry Nuttens wrote: > It's not easy to find the right mail about Jeremy's new build method. http://linuxfromscratch.org/pipermail/lfs-dev/2012-February/065826.html JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On 3/15/12 4:51 PM, Greg Schafer wrote: > On Wed, 14 Mar 2012 20:32:36 -0700, Bryan Kadzban wrote: > >> It seems that Greg never got the time to comment any more thoroughly on >> the modifications, either. I'd kinda like to hear what he has to say, > > Well, I've been doing a lot of reading in order to get back up-to-speed. > One of the reasons I haven't commented yet is that nothing has really > changed since the last time Ryan and myself debated this back in 2009. > And this is one of the big objections I have - the proposed changes are > not even based on Jeremy's work, but Ryan's. It's like Jeremy has been > waiting around for a few years for me to go away so that he can quietly > "drop it in". Is Ryan still around to pick up the pieces if things fall > apart? AFAIK he hasn't been spotted in the wild for a few years, but then > again, I don't hang around in IRC circles so I wouldn't know... Greg, there's no need to make this personal. My motives for bringing this up again had nothing to do with you - and if you re-read the initial post on this thread you'll see I credited Ryan as being the source of the general build method. So instead of making your arguments attempts to discredit me, why not try being objective and evaluate it solely on a technical basis? Bryan, I think you brought up some good questions, but I only quickly scanned through your post. I've been super busy with work these past few days. I'll try to get you a real reply soon. Everyone else, please do review all of the links and posts that Greg provided. It was mostly reading those (and bits of the source) as well as the tests/experimentation that convinced me that the proposed method is solid. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc cross patch in pass1
On 3/14/12 7:20 PM, Matt Burgess wrote: > On Wed, 2012-03-14 at 23:11 +, Andrew Benton wrote: > >> With the full gcc-4.6.3 tarball I get the same results as everybody > > Wonderful! I'll sleep easier tonight now :-) I'm glad this has finally > been solved. Nice! Glad we got that one nailed down. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Build method revisions
On 3/8/12 4:24 PM, Bruce Dubbs wrote: > Jeremy Huntwork wrote: >> On 3/2/12 11:10 AM, Bruce Dubbs wrote: >>>> --- binutils-build-sysroot-libdir/ld/eelf_x86_64.c 2012-03-01 >>>> 23:31:31.789317951 -0500 >>>> +++ binutils-build-nosysroot-nolibdir/ld/eelf_x86_64.c 2012-03-02 >>>> 00:29:16.117697363 -0500 >>> Yes, I saw that. Reviewing. >> >> How is that coming along? > > Not well, sorry. I've got some personal things going on right now and > can't get to it. I'll look as soon as I get some time. Has anyone else had a chance to try out the build fully and compare? I'm waiting to hear more of a consensus from others who have tested it before I drop this in, although I'm confident it's sound. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc cross patch in pass1
On Mar 13, 2012, at 6:03 PM, Andrew Benton wrote: > On Tue, 13 Mar 2012 17:40:03 + > Bruce Dubbs wrote: > >> I'm having a problem with why this is happening. > > Me too... > >> The jhalfs vanilla LFS >> svn build worked perfectly for me. >> >> http://www.linuxfromscratch.org/~bdubbs/033-gcc-pass1 > > Looking at your log I see: > *** This configuration is not supported in the following subdirectories: > target-libquadmath gnattools target-libada target-libstdc++-v3 > target-libgfortran target-libgo target-libffi target-zlib target-libjava > target-libobjc target-libgomp target-libmudflap target-libssp target-boehm-gc >(Any other directories should still work fine.) > > Notice the target-zlib in there? For me I get: > *** This configuration is not supported in the following subdirectories: > target-libquadmath target-libstdc++-v3 target-libgomp target-libmudflap > target-libssp >(Any other directories should still work fine.) > > So it would seem that for you, configure sees that target-zlib will not > work and doesn't try to compile gcc-build/x86_64-lfs-linux-gnu/zlib > For me, configure thinks target-zlib will work and it has a go. What's your CPU? Can you test on another CPU? JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc cross patch in pass1
On 3/13/12 1:21 PM, Andrew Benton wrote:
> ... and then I tried jhalfs with the vanilla LFS svn book and of
> course, I was wrong again, it failed in exactly the same way! Looking
> at the differences between the book and the scripts that work for me,
> the book has --disable-target-libiberty --disable-target-zlib and my
> scripts have --without-target-libiberty --without-target-zlib (it took
> me a while to see the difference...) If I edit the LFS xml and change
> `disable' to `without' and start again, then it works. It seems that the
> gcc-4.6.3-cross_compile-1.patch does not recognise
> --disable-target-libiberty or --disable-target-zlib
I am completely confused with where we are at here. I want to get to the
bottom as to why the switches are required at all - it shouldn't be a
problem to cross-build zlib or libiberty for x86{,_64}. Can we get back
to comparing notes on builds without the patch and switches?
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] gcc cross patch in pass1
On 3/13/12 12:27 PM, Pierre Labastie wrote: > Le 13/03/2012 16:18, Andrew Benton a écrit : >> >> I was unwilling to use jhalfs as I dislike sudo. However, needs must, >> and the result? >> [...] >> This was using Jeremy's sysroot.diff on top of the LFS xml files. I >> think vanilla LFS will work for me as it has the patch and >> --disable-target-zlib >> > So we should be able to compare our logs. Mine is in > /mnt/lfs/jhalfs/logs/033-gcc-pass1. > I can send it to you or converse (or both)... Here's my log: http://linuxfromscratch.org/~jhuntwork/033-gcc-pass1 And the script that generated it: http://linuxfromscratch.org/~jhuntwork/033-gcc-pass1.sh JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] gcc cross patch in pass1
On 3/12/12 11:14 AM, Andrew Benton wrote: > Fedora-16-x86_64-Live-Desktop.iso > > FWIW I can do you sysroot method if I patch gcc with the cross_compile > patch and add these options to configure: >--without-ppl --without-cloog \ >--without-target-libiberty --without-target-zlib > > I'm not sure if the --without-ppl --without-cloog were needed. Alright, I grabbed the iso above from Fedora's site, started it up in a vm, ran 'yum install gcc patch texinfo bison subversion wget -y', grabbed jhalfs trunk, set it up to build the book with my additions... ...and built gcc pass1 without the patch and without any issues. I'm not sure what you're doing differently, but I can't replicate. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
