ELF linking question related to symbol collisions
Florian Weimer
fweimer@redhat.com
Wed Dec 18 18:44:00 GMT 2013
On 12/18/2013 07:18 PM, Carlos O'Donell wrote:
>> Or more to the point, I'm not sure if the current linking algorithm
>> is what we need. Something like -B direct might be a better fit for
>> our current needs.
>
> I assume we're talking about some of the features present in Solaris?
Correct.
>> Unless that function references static symbols, then it may or may
>> not be safe. If everything ends up being interposed, it is okay, but
>> if not, code might hit different static symbols.
>
> That is correct. If the API has state then it would not work to use
> a mixed implementation as you point out.
It's also common to have code like this:
static const char * msg = "some string";
void
foo_close (struct foo *pfoo)
{
if (pfoo->msg != msg)
free (pfoo->msg);
free (pfoo);
}
I think this is what sometimes break the Lua interpreter when interposed.
>> Sure, but I think static linking has no future. If it reappears, it
>> will be in the form of LTO object files.
>
> Static has use cases that will never go away.
>
> I plan to support it in glibc forever or until some new method is
> as easy as static linking to solve the same use cases.
Yes, from a toolchain standpoint, it's absolutely true. I was concerned
with the distribution POV and didn't make that clear.
> I agree that toolchain features for managing namespaces are
> important.
>
> However, no amount of tooling will fix people from breaking
> the namespace. The tooling only helps you resolve the breakage.
>
> There must be a higher level analysis and policy at the distribution
> level.
>
> Do you disagree with that last statement?
I agree completely. As a distribution, we also need some way to detect
upstream surprises and override their decisions if necessary.
--
Florian Weimer / Red Hat Product Security Team
More information about the Libc-help
mailing list