On Sat, Mar 29, 2008 at 08:38:58PM +0100, Pierre Habouzit wrote: > 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 ?
Can I suggest you take this discussion to debian-devel instead dpkg and release lists? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]