Re: glibc build error: linking nptl static - V2.17

["Carlos O'Donell" <carlos at systemhalted dot org>]

>> Undefined references to weak symbols do not cause the static linker to
>> include an object file to satisfy the undefined reference.
> ----
> Oi! ... wish that worked for dynload as well -- i.e. just because a sym
> is referenced ldd will fail if it can't find it -- even if the program
> itself
> doesn't seem like it would make use of such (maybe it is and I don't
> know it).

If the program had an undefined reference to a symbol it must have a
definition somewhere at link time otherwise it would fail to build.

At runtime the situation is slightly different because lazy symbol
resolution means that shared library you need might not exist, and the
failure is only detected at the time the function symbol is called.

Lastly use --as-needed in the link command to reduce the set of
required dynamic libraries to the minimum needed to resolve undefined
references.

>>  The goal is
>> to reduce the size of the static program.
> ...
>>  So you minimize the static application size by not including
>> code you don't need.
>>
> yes -- that's why i was disabling alot of things --

The most space savings is had by restructuring the code.

>>> note -- from below, it appears this message is taken when it is doing
>>> the SHARED version
>>>
>>
>> Right, so either --disable-hidden-plt is breaking this code, because
>> __GI_* is the "hidden global internal" name of the function that we
>> expect to call via PLT, or your static build is somehow broken.
>>
> ----
>     The only reason  I included that option was because I thought
> (perhaps backwards), that not hiding symbols would allow more things
> to link successfully -- but it may be just the opposite -- it may pull
> more symbols in?

It has nothing to do with static linking. You should not use it.

> Also wasn't sure what the --enable-bind-now option did or if I should
> leave it or not.

Leave out any configure options you don't understand :-)

Cheers,
Carlos.