Re: Default value for CFLAGS/LDFLAGS set by dpkg
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