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. 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. > 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... Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
