On July 23, 2016 1:59:09 PM CDT, "Douglas R. Reno" <[email protected]> wrote: >Armin K. wrote: >> On 21.07.2016 23:59, via blfs-book wrote: >>> Author: renodr >>> Date: Thu Jul 21 14:59:16 2016 >>> New Revision: 17603 >>> >>> Log: >> >>> Added seds to subversion, libva, and libX11 to silence more libtool >warnings >>> Typo fixes >>> >> Are you really going to add this to every package, just because it's >anoying? >Not to *every* package. Most of them that I have run across don't >complain whatsoever. I would say 75% of packages I have built haven't >complained. That said, 15% have complained, and 10% don't use Libtool >whatsoever. >> If you want to get rid of it, use a more elegant solution: >> >> Remove /usr/lib64 symlink when starting lfs build. Make sure nothing >gets installed >> there by using apropriate switches to point to /usr/lib. I think I've >ironed out all >> the cases that I've found when I was around, or >> >> Remove all *.la files in /usr/lib (but not its subdirectories). They >are useless anyways.
Yes! >> >If we weren't in the second half of the last month before release, I'd >consider suggesting that. That would require a bit more testing than I >can muster at the moment. Wouldn't that violate the FHS as well? >> No, /lib<qual> is optional now. Pretty much has been since the FHS discussions in 2013/2014, and officially for a year. :-) /lib, /bin, and /sbin can even be a symlink to somewhere else now, and /lib32 is a perfectly valid target for x86 compat libs. At one point, this didn't jive with LSB, but there was an effort to bring POSIX 2003, SUS v3, FHS-3.0 and LSB-5.0 into agreement. Current FHS: http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html Current LSB: http://refspecs.linuxfoundation.org/lsb.shtml That symlink dates back to when 64bit Linux was first introduced to LFS, and made a good deal of sense at the time. The toolchain used to be a PITA WRT changing the default lib search paths. Not so much anymore. We should probably take a look at that on next release cycle, make sure lib is preferred, maybe even drop /lib64 completely, even if we don't kill the compatibility symlink (which I'd personally like to see go). --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
