This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP


------- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]