Re: Default value for CFLAGS/LDFLAGS set by dpkg
- To: email@example.com, firstname.lastname@example.org
- Cc: Raphael Hertzog <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- Subject: Re: Default value for CFLAGS/LDFLAGS set by dpkg
- From: Steve Langasek <email@example.com>
- Date: Sat, 29 Mar 2008 15:14:42 -0700
- Message-id: <20080329221442.GC6576@dario.dodds.net>
- Mail-followup-to: firstname.lastname@example.org, email@example.com, Raphael Hertzog <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com
- In-reply-to: <20080329193858.GA9654@artemis.madism.org>
- References: <20080328090307.GB23166@ouaza.com> <20080328094258.GA10149@artemis.madism.org> <20080329011851.GA3367@dario.dodds.net> <20080329193858.GA9654@artemis.madism.org>
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 :)
No, glibc is the only common example I know of that does this. There is
really no correlation between use of weak aliases and use of symbol
> > 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 ?
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/