On Sat, Mar 29, 2008 at 01:18:51AM +0000, Steve Langasek wrote: > On Fri, Mar 28, 2008 at 10:42:58AM +0100, Pierre Habouzit wrote: > > On Fri, Mar 28, 2008 at 09:03:07AM +0000, Raphael Hertzog wrote: > > > I'd like to suggest an intermediary solution: we don't revert the feature > > > but we remove the default value for LDFLAGS. I think that most run-time > > > and build-time failures have been caused by the change on this variable. > > > > Does that seem acceptable? For lenny+1, we can reintroduce the original > > > default value. > > > I believe it to be the reasonable course of actions. For those > > following at home, LDFLAGS default value was proposed to be > > -Wl,-Bsymbolic-functions. If that's a safe idea for sloppily written > > libraries, it adds nothing to those already using symbol versioning > > where it can *only* break things. > > No, this has nothing to do with symbol versioning. Its purpose is to > optimize symbol lookups by binding them to the local symbols, allowing > faster start times. Well, what I meant is that libraries that use symbol versioning also use weak-aliases and already bind to local private symbols. At least it's what the libc and a couple of other library do. So indeed symbol versioning has nothing to do with it directly, but usual practices that go with it do :) > However, as Thiemo notes, this does break the expectation that LD_PRELOAD > will be allowed to intercept symbols; so this is definitely a behavior > change with some possibly subtle consequences. Well, it breaks LD_PRELOAD (if I don't get it wrong) in the very same way that libraries using local weak symbols to allow overloading (without LD_PRELOAD) would break right ? But it does not break LD_PRELOAD to replace how external symbols are bound, does it ? > > The *VERY* nasty part about that change is that it not only breaks > > things at build-time (that thanks to lucas or constant reuploads of some > > important packages) is easy to spot, it also breaks things at *runtime* > > for libraries that *mean* their users to fiddle with their symbols (like > > the glibc sometimes does, as it guards its vital parts using internal > > symbols only when needed). > > Well, if the glibc test suite were in good enough shape to be used as input > for package build success/failure, that would be caught at build time too... Well, if we had a decent upstream, maybe we would. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgptGFFCoDwRY.pgp
Description: PGP signature