On Sun, 14 May 2006 12:46:23 +0200 Harald van Dijk <[EMAIL PROTECTED]> wrote:
> The idea of filter-ldflags is a bad one, IMO. There are an infinite > number of ways to enable a flag (for -z now: -Wl,-z,now; > -Wl,-z -Wl,now; -Xlinker -z -Xlinker -now; -Wl,-O1,-z,now; ...). Even > if you restrict yourself to the sane ones, you can't reasonably catch > them all. That's true enough, however if people follow the QA instructions they'll do the -Wl,-z,now version. People doing other variations can get picked up when they raise a bug with emerge --info. Or we could make filter-ldflags more intelligent, of course. > Normally, the proper fix would be `append-ldflags -Wl,-z,nonow` Ideally, yes - but as you note, "-z nonow" does not exist. BTW '-nonow' is a separate thing (note, no '-z'), added by us to the hardened compiler specs to switch off the automatic -z,now we do on links. > but as binutils completely ignores > this, that's not going to work either (as also noted earlier). I > think the only sane thing to do (treating -Wl,-z,now -Wl,-O1 > differently from -Wl,-z,now,-O1 is not sane) is to give a warning > message telling users not to enable -z now even if portage states > otherwise. Ideally, binutils would also be patched to support -z > nonow, and -Wl,-z,nonow would be appended to LDFLAGS, but that's > something for later concern. -- Kevin F. Quinn
signature.asc
Description: PGP signature
