On July 23, 2016 3:33:10 PM CDT, "Armin K." <[email protected]> wrote:
>On 23.07.2016 21:04, Douglas R. Reno wrote:
>> Armin K. wrote:
>>> On 23.07.2016 20:59, Douglas R. Reno 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.
>>>>>
>>>> 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 sane distro ships *.la files in /usr/lib, and most of them
>respect FHS. So no, it wouldn't.
>>>
>>>
>> I am specifically talking about the /lib64 and /usr/lib64 symlinks.
>Those are required by the FHS, if I am not mistaken. I am not opposed
>to removing the *.la files, but where would we tell users to do that?
>The issue with these warnings is that they detract from useful build
>output altogether. We already know that many users don't read the
>introductory chapters and jump straight into the build instructions.
>> 
>
>/lib64 is required, specifically because 64 bit programs look for
>dynamic linker there.

Oap! Yes, I had forgotten about the arch spec in my previous message. This is 
mandated by the LSB AMD64 spec.

http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-AMD64/LSB-Core-AMD64/requirements.html#RLIBRARIES

Sorry about that. At least Arch users a symlink to /usr/lib for both. Suspect 
the same for Debian. 

>
>As for /usr/lib64, I'm not sure whether other distros ship the symlink.
>I do know that
>Fedora explicitly uses /lib64 and /usr/lib64 on 64 bit systems and /lib
>and /usr/lib
>on 32 bit system, as is correct by FHS. 

That's not required anymore by FHS-3.0, but was the reason for RH vs Debian 
debate a few years back (2005?->current), well before the upstart and systemd 
debate.

> LFS and some other distros
>don't follow this
>convetion, but instead keep /usr/lib64 and /lib64 as a symlink to their
>non-lib64
>counterparts.
>
>Possible third solution to the ones above is to explicitly use
>--libdir=/usr/lib switch
>on the packages whose *.la files reference /usr/lib64.
>

Correct solution, but is a lot of work for little gain. This should be done 
regardless over time.


--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

Reply via email to