Re: Regarding whole-archive linking libc.a into a shared lib

[Szabolcs Nagy <nsz@port70.net>]

* Jason Ramapuram <jason.ramapuram@gmail.com> [2016-07-14 12:49:31 +0200]:
> Thanks for the link. Just went through the entire thread. I think we can
> solve the problems as such though:
> 
>    1. Have some form of linker that mangles all the symbols internally in
>    the newly linked shared library, eg: FILE* --> FILE_mangled* so that
>    internally it has it's own libc calls that are independent from anything
>    that a binary might require.
>    2. Block allocate a chunk of memory internally in the library so that
>    allocations are now using that internal block and not malloc-ing.
> 
> However, I'm not quite sure how 1) could be solved at this time.
> 

1) libc maintains global state which will be duplicated in your
shared lib (e.g. envvars, stdio buffers, timezone, locales)
name mangling does not fix their behaviour (they will behave
inconsistently with other parts of the application).

2) brk is not the only global state that can only have one owner,
the thread pointer is another example: if your shared lib does
any tls access (e.g. errno, stack canary) then it has to match
the internals of the libc in the main application (won't work
across libc versions).

static linking libc into a shared lib simply does not make sense.