This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Incorrect IFUNC use in libpthread for fork, vfork wrapper [BZ #19861]
- From: Florian Weimer <fweimer at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>, Szabolcs Nagy <nsz at port70 dot net>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>
- Date: Mon, 11 Apr 2016 11:34:00 +0200
- Subject: Re: Incorrect IFUNC use in libpthread for fork, vfork wrapper [BZ #19861]
- Authentication-results: sourceware.org; auth=none
- References: <56FBD238 dot 1010101 at redhat dot com> <56FC032B dot 6040700 at redhat dot com> <20160330191045 dot GN9862 at port70 dot net> <56FC2E3D dot 4020901 at redhat dot com>
On 03/30/2016 09:51 PM, Richard Henderson wrote:
Come to think of it, we had the same situation of the same symbol version being
provided by two libraries prior to removing fork from libpthread too, so when
providing compatibility symbols we must be mindful of that -- proper
dependencies on libpthread may well not exist.
Considering that libpthread has a DT_NEEDED entry for libc.so.6, doe we
actually need the compatibility wrapper?
I removed it, built a special libdofork.so which has a DT_NEEDED entry
for libpthread.so.0 only, and got this with a glibc built that doesn't
have the compatibility wrapper:
12074: symbol=fork; lookup in file=/tmp/boom [0]
12074: symbol=fork; lookup in file=./nptl/libpthread.so.0 [0]
12074: symbol=fork; lookup in file=./libdofork.so [0]
12074: symbol=fork; lookup in file=./libc.so.6 [0]
12074: binding file ./libdofork.so [0] to ./libc.so.6 [0]:
normal symbol `fork' [GLIBC_2.2.5]
So it seems to work just as before.
The difference will be visible with dlopen, but will that matter?
Florian