public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jason dot vas dot dias at gmail dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP Date: Sun, 19 Apr 2009 08:46:00 -0000 [thread overview] Message-ID: <20090419084612.4249.qmail@sourceware.org> (raw) In-Reply-To: <20090414185756.10071.jason.vas.dias@gmail.com> ------- 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.
next prev parent reply other threads:[~2009-04-19 8:46 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-04-14 18:58 [Bug libc/10071] New: " jason dot vas dot dias at gmail dot com 2009-04-14 19:01 ` [Bug libc/10071] " jason dot vas dot dias at gmail dot com 2009-04-14 19:08 ` drepper at redhat dot com 2009-04-15 0:14 ` jason dot vas dot dias at gmail dot com 2009-04-15 11:11 ` pasky at suse dot cz 2009-04-19 7:28 ` jason dot vas dot dias at gmail dot com 2009-04-19 8:46 ` jason dot vas dot dias at gmail dot com [this message] [not found] <bug-10071-131@http.sourceware.org/bugzilla/> 2014-07-01 7:07 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20090419084612.4249.qmail@sourceware.org \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).