[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Default value for CFLAGS/LDFLAGS set by dpkg

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 ?

> >   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...

  Well, if we had a decent upstream, maybe we would.

·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgpMrko5HlfXz.pgp
Description: PGP signature

Reply to: