[PATCH] manual: Document replacing malloc [BZ #20424]

[Florian Weimer]

On 04/19/2017 11:20 PM, DJ Delorie wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
> 
>> * DJ Delorie:
>>
>>> fweimer@redhat.com (Florian Weimer) writes:
>>>> +linked programs, this happens through ELF symbol interposition.  For
>>>> +static linking, the @code{malloc} replacement library must be linked in
>>>> +before linking against @code{libc.a} (explicitly or implicitly).
>>>
>>> Note that in statically linked cases, it's important to make sure that
>>> ALL your API functions are linked in.  If your allocator is a library,
>>> with one function per object, you might get only some of your functions
>>> - and then try to get the rest from glibc, which will of course fail.
>>
>> That's what I meant with “linking failures and crashes at run time”
>> below.
>>
>> I don't think it matters whether you have one object file or multiple
>> ones.
> 
> My point was, just putting your *.a first in the link line is
> insufficient to make sure all your *.o are included, and if
> some-but-not-all of your *.o are pulled from your library, that's an
> additional problem for you to solve.  Or at least watch out for.

Ahh, you mean this:

     “Normally, an archive is searched
      only once in the order that it is specified on the command line.
      If a symbol in that archive is needed to resolve an undefined
      symbol referred to by an object in an archive that appears later on
      the command line, the linker would not be able to resolve that
      reference.”

I think this falls under correctly using the static linker.  I'm not 
sure if we should go into that level of detail in the malloc documentation.

> That would do.  Maybe one general warning about static linking rather
> than repeating it throughout, though?

I added a Note: in the attached patch.

Thanks,
Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: malloc.patch
Type: text/x-patch
Size: 4009 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170420/6b450a07/attachment.bin>