This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP
- From: "jason dot vas dot dias at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 19 Apr 2009 08:46:12 -0000
- Subject: [Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP
- References: <20090414185756.10071.jason.vas.dias@gmail.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From jason dot vas dot dias at gmail dot com 2009-04-19 08:46 -------
To clarify :
Only relinking after ldconfig(1) with new glibc and recompilation
of app now containing __getdelim references, with SAME gtk+ objects - why ?
my app MUST be linked with '-z muldefs' because it MUST use another stdio
implementation .
For some reason, ONLY replacing the new glibc installed objects and running
ldconfig(1), without rebuilding, causes gtk+ to link to newer versions of
libselinux.so.1 that use __getdelim() that gets invoked in its init() section.
But ld(1) and ld.so(1) on Solaris are capable of detecting such mistakes
at link time - why can't Linux ld(1) and ld.so(1) be equally capable?
Because on Solaris you can define the SFIO libraries as an "interposer" so
that if objects are not found within them to satisfy links required by other
groups of objects before libc objects are used could trigger a link time error.
Then the whole app could be linked with '-z,defs' (the default) and just
the linkage order is enough to ensure that ONLY SFIO objects are used for
SFIO input/output; use of the SFIO object returned by fopen() with glibc
stdio triggers an early stack corruption on new glibc UNLESS __getdelim() is
defined - it now is!
If ld(1) and perhaps also ld.so(1) had some kind of "--interposer" or
"--dynamic-(no?)muldefs" option that both honored, then if a symbol not
found in that module did not satisfy the load requirments of another
group, then ld.so(1) could raise an error with '--dynamic-nomuldefs' if
a symbol that is defined or by in an object in a interposer group ( eg.
SFIO's stdio file descriptor global definitions ( or perhaps even
was created by malloc within the scope of functions defined in
objects in that group!)) and is then found ONLY in glibc
then an error could be raised ; with '--dynamic-muldefs', the FIRST
interposer for eg the 'stdio' group of objects will always be
used ( the current default ). ie. by including the SFIO module first, while
with the required '--whole-archive,-z,muldefs' ld option + ld.so
--dynamic-muldefs option, all of its objects MUST override the references to
them in all subsequent load modules, including in init() sections. Possible?
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10071
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.