[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Nov 2013 21:55:40 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: libc.so symbols that are not reserved
On Tue, Nov 12, 2013 at 02:39:47AM +0100, Szabolcs Nagy wrote:
> i filtered nm -D libc.so for posix name space violations
> and compared the results (weak symbols were omitted), some
> of these should be fixed
I'm unclear on why you consider them violations. They do not conflict
with symbols in the application or in third-party libraries. This can
easily be verified. Basically, symbols in shared libraries always act
like weak symbols would in static linking (this may be a poor
approximation of the reality, but it's close enough to be a useful way
of thinking about it).
What would in principle be problematic is if standard C or POSIX
functions in libc depended on any of these symbols, since an
application could interpose unrelated functionality with the same
name. In practice that doesn't matter for dynamic linking since
-Bsymbolic is used, but it would matter for static linking of course.
As far as I know musl has no such issues (except for treating dup3,
pipe2, etc. as if they were in POSIX since they will be in the next
issue; if you object to that I'm not opposed to adding __-prefixed
versions).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
