Re: Default value for CFLAGS/LDFLAGS set by dpkg
- To: firstname.lastname@example.org, email@example.com
- Cc: Raphael Hertzog <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com
- Subject: Re: Default value for CFLAGS/LDFLAGS set by dpkg
- From: Steve Langasek <firstname.lastname@example.org>
- Date: Fri, 28 Mar 2008 18:18:51 -0700
- Message-id: <20080329011851.GA3367@dario.dodds.net>
- Mail-followup-to: email@example.com, firstname.lastname@example.org, Raphael Hertzog <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- In-reply-to: <20080328094258.GA10149@artemis.madism.org>
- References: <20080328090307.GB23166@ouaza.com> <20080328094258.GA10149@artemis.madism.org>
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...
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/