Jeremy Huntwork wrote: > On Sep 3, 2011, at 12:58 PM, Matthew Burgess wrote: >> Confirmed here with popt-1.16. It seems odd that pkg-config >> bundles a version of popt known to be broken, and requires a >> configure switch (with-installed-popt) to use a system-installed >> version. popt is certainly small enough to bring over to LFS to >> fix this issue properly. Either that, or remove the sed as it is >> completely bogus, and just inform the reader that 1 test is known >> to fail. > > Eek, 1 test known to fail means that popt is not working as expected, > and therefore some pkg-config functionality is broken. If you don't > want to include popt in the base system, then I think it's better to > track down what is broken in the bundled version shipped with > pkg-config and fix it.
There are 4 subtests in the check-cmd-options test: pkg-config --define-variable=a=b --atleast-pkgconfig-version=999.999; echo $? 1 pkg-config --define-variable=a=b --atleast-pkgconfig-version 999.999; echo $? 0 pkg-config --define-variable a=b --atleast-pkgconfig-version 999.999; echo $? 1 pkg-config --define-variable a=b --atleast-pkgconfig-version=999.999; echo $? 1 Only the second fails as all should return 1. Checking BLFS, it looks like popt is used for Hd2u, pilot-link, libbonobo, rsync, samba, and libdv. I also know it is needed for rpm. I am reluctant to add packages to LFS and cause 'bloat'. In this case, I don't see any packages that I would term 'critical' from BLFS that need popt. Since popt is, by default, linked statically into pkg-config, the question is whether this error in command options parsing worth fixing? I lean towards not fixing this, but could be persuaded otherwise. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
