Re: [lfs-dev] chapter 6 readline slightly incorrect
On 4/9/20 11:38 AM, Tadeus Prastowo via lfs-dev wrote: On Thu, Apr 9, 2020 at 9:12 AM Pierre Labastie wrote: On Wed, 2020-04-08 at 23:27 +0200, Tadeus Prastowo wrote: Perhaps you need to check with a program that links to libreadline using the --if-needed option. I think you are right and this needs some testing. Actually, this is my question: are there still packages using --if- needed? Not in lfs for sure. I'll do a full build of blfs to make sure. If you can point me to a package using that (even outside blfs), please do. The OP of the first link mentions `GNU parted-1.8.6'. I haven't checked whether the latest version of parted still does it. OTOH, is -L/tools/lib needed? I hate the idea of putting a reference to /tools in final lfs builds. I have to try, but I think that just using SHLIB_LIBS=-lncursesw will add libncursesw to the list of needed ibraries, without resolving the above names at static link time (having them resolved at dynamic link time instead). AFAIK, -L will not embed anything in the resulting shared library. Correct. It just tells the linker where to look. rpath does embed the location of dynamic libraries. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] chapter 6 readline slightly incorrect
On Thu, Apr 9, 2020 at 9:12 AM Pierre Labastie wrote: > > On Wed, 2020-04-08 at 23:27 +0200, Tadeus Prastowo wrote: > > > > Perhaps you need to check with a program that links to libreadline > > using the --if-needed option. > > > > I think you are right and this needs some testing. > Actually, this is my question: are there still packages using --if- > needed? Not in lfs for sure. I'll do a full build of blfs to make sure. > > If you can point me to a package using that (even outside blfs), please > do. The OP of the first link mentions `GNU parted-1.8.6'. I haven't checked whether the latest version of parted still does it. > OTOH, is -L/tools/lib needed? I hate the idea of putting a reference to > /tools in final lfs builds. I have to try, but I think that just using > SHLIB_LIBS=-lncursesw will add > libncursesw to the list of needed ibraries, without resolving the above > names at static link time (having them resolved at dynamic link time > instead). AFAIK, -L will not embed anything in the resulting shared library. > Pierre -- Best regards, Tadeus -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] util-linux depends optionally on udev
Changed the subject to reflect what is really going on... On Thu, 2020-04-09 at 11:56 +0200, Pierre Labastie via lfs-dev wrote: > [...] > Sometimes I wonder why I assume something without checking! It > happens > to me too often that it then proves wrong! > > Here it is: I've discovered that findmnt was linked to libudev after > second pass, and not after thefirst pass. But why have I assumed that > findmnt was coming from e2fsprog > > e2fsprog does not even test libudev, and the only reference to udev > is > a reference to udev's rules directory needed for e2scrub. > > findmnt is from util-linux, and that one links to libudev if it is > present. So eudev should be before util-linux, but I have to test > that > nothing depends on util-linux in eudev... > > Trying a build with eudev before util-linux ATM. > No joy, eudev depends on libblkid (more exactly, cdrom_id, ata_id, xxx_id, ...). So this is a circular dependency, and I'd say that having functional xxx_id is more important than having libudev in findmnt (but this depends on use cases, I guess). Anyway, I think I'll try a new build adding util-linux in chap 5, as we do in systemd book. That might be the best solution. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] e2fsprog depends optionally on udev
On Sun, 2020-04-05 at 09:37 +, DJ Lucas via lfs-dev wrote: > On April 3, 2020 2:17:29 PM CDT, Pierre Labastie via lfs-dev < > lfs-dev@lists.linuxfromscratch.org> wrote: > > On Fri, 2020-04-03 at 13:27 -0500, Bruce Dubbs via lfs-dev wrote: > > > On 4/3/20 12:33 PM, Pierre Labastie via lfs-dev wrote: > > > > I've reinstated the ICA system in jhalfs, in order to test the > > > > builds > > > > with the sysroot/cross-compile system. > > > > > > This is really cool, and necessary from time to time (as you've > discovered). > > > > > For those who haven't folowed lfs in the 200x years, ICA > > > > (iterative > > > > comparison analysis) is a way to rebuild the system with > > > > itself, > > > > and > > > > compare the results. There used to be another system, "farce", > > > > written > > > > by Ken, which had to be removed from jhalfs for licensing > > > > problems. > > > > I > > > > think this sytem is still accessible at Ken's home on > > > > www.linuxfromscratch.org. > > > > > > > > Anyway, I found that e2fsprogs was linked against libudev on > > > > the > > > > second > > > > build, and not on the first. The reason is that eudev is uilt > > > > after > > > > eudev. > > > > > > > > Maybe we could exchange eudev and e2fsprogs? > > > > > > How about just moving eudev to between util-linux and e2fsprogs? > > When reordering here, be careful not to adjust systemd > (udev/systemd). It's all a few years of fuzzy, but the interaction of > those three packages was a bit of a nightmare when merging the two > books. IIRC, that was what prompted the extra partial build of util- > linux in chapter 5 for systemd, so we could keep the build order > roughly the same across the two books (difference in systemd deemed > acceptable because systemd gets reinstalled early in BLFS - and I'm > pretty sure this will still show up if you run ICA on systemd). I > want to say something to do with a disk geometry library that got > moved from e2fsprogs to util-linux (or maybe vice versa), but it is > all so long ago, I'm unsure. > > Anyway, if running a comparison build, it'll reveal itself, so it's > really cool that this is working again! > > --DJ > Sometimes I wonder why I assume something without checking! It happens to me too often that it then proves wrong! Here it is: I've discovered that findmnt was linked to libudev after second pass, and not after thefirst pass. But why have I assumed that findmnt was coming from e2fsprog e2fsprog does not even test libudev, and the only reference to udev is a reference to udev's rules directory needed for e2scrub. findmnt is from util-linux, and that one links to libudev if it is present. So eudev should be before util-linux, but I have to test that nothing depends on util-linux in eudev... Trying a build with eudev before util-linux ATM. Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
