[lfs-dev] More on static libs

Douglas R. Reno renodr2002 at gmail.com
Thu Mar 12 19:54:50 PDT 2015


On Thu, Mar 12, 2015 at 9:36 PM, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:

> Ken Moffat wrote:
>
>> On Thu, Mar 12, 2015 at 08:04:37PM -0500, Bruce Dubbs wrote:
>>
>>> Bruce Dubbs wrote:
>>>
>>> Interesting:
>>>
>>> $ cat /usr/lib/libc.so
>>> /* GNU ld script
>>>     Use the shared library, but some functions are only in
>>>     the static library, so try that secondarily.  */
>>> OUTPUT_FORMAT(elf64-x86-64)
>>> GROUP ( /lib64/libc.so.6 /usr/lib64/libc_nonshared.a  AS_NEEDED (
>>> /lib64/ld-linux-x86-64.so.2 ) )
>>>
>>> So  libc_nonshared.a is *really* needed.
>>>
>>> On 686:
>>>
>>> OUTPUT_FORMAT(elf32-i386)
>>> GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED (
>>> /lib/ld-linux.so.2 ) )
>>>
>>>    -- Bruce
>>>
>>>  As you say, "Interesting", but at the moment my take is "some
>> packagages *may* need libc_nonshared.a".  My build has started,
>> let's see if it gets through chapter 6 without these static libs.
>>
>> And worst case, I will find some of the packages where libc_nonshared
>> is used.
>>
>
> I can tell you right now.  In the adjusting section, cc dummy.c fails.
>
>   -- Bruce
>
>
>
>
> I know that I am hopping into this conversation a little late (and without
too much prior knowledge of the discussion), but I would definitely suggest
leaving things from Binutils, GCC, Glibc, GMP, Zlib, MPFR, and MPC alone.
There is just too much that can go wrong if we remove those libraries.
(Example, Bruce's libc_nonshared.a removal causing a failure with "cc
dummy.c"). Although I suppose that we could just leave things from GCC,
Glibc, and Binutils alone. I have followed that some distributions have
them and some don't, but I understand that the real question is whether or
not we need them.

Douglas R. Reno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20150312/60e352cd/attachment.html>


More information about the lfs-dev mailing list