Not in the (good) sense of making something that a fool won’t be able to break, but in the negative sense of something being a proof that you are a fool.
When I check bugs that seem far-fetched or silly or I cannot reproduce after a few tries, I have one very easy way to close the bug as invalid with a very low false positive ratio usually: I check the linker flags (LDFLAGS). I don’t rule out bugs depending on the compiler flags usually, it takes a lot of bogus stuff for me to ignore your bug for that; I’m the first one to use excessive flags to test stuff and I rarely find them to be extremely bad behaving. But there is one thing I can see in LDFLAGS that does taint the bugs as coming from an user with not enough clue.
I don’t want to insult anybody, but I do think that if you do that mistake, you seriously should think again about what you are doing.
The tainting flag is --enable-new-dtags; yeah the same --enable-new-dtags that I’ve blogged about almost three years ago in relation to the stupid hacks for “kdenewldflags USE flag”.
This is an interesting linker flag that does… nothing useful. Well, not exactly okay. It does usually enable some new tags for the .dynamic section, in particular the DT_RUNPATH that replaces DT_RPATH for security reasons. But it doesn’t make any sense when using the Gentoo version of binutils: we force the new dtags on! Now if you were to have vanilla binutils installed I could understand your use of the flag, but given you shouldn’t be bothering us with bugs if you were using that (the vanilla USE flag is useful when reporting bugs upstream), it is a nice way to cut you out anyway.
Why do I use that has a “PEBKAC flag”, given it doesn’t do anything bad in particular? Indeed I have been told that the ld man page still said (and for most users still say) that new dtags are disabled by default, and I actually went around to add a patch in the latest masked binutils to change the man and info pages reflecting this. My reasoning is that most people would have this flag in because it was spread around by people reading (without understanding) the above-noted KDE macro.
So almost all people who has --enable-new-dtags in their LDFLAGS variable are people who didn’t understand a bit what LDFLAGS really is and just copied the list of entries out of a forum post, an uninformed blog, or maybe the old Gentoo Wiki. I don’t really want to care, if you cannot get that the flag is pointless, you don’t get your non-obvious bugs serviced by me.
A similar thing is up for those who have -Wl,-O2 .. considering that the linker has no optimisation level beside the one.
Is this stated clearly enough?
hmm, I seem to recall that LDFLAGS=”-Wl,-O1,–hash-style=gnu,–as-needed” was going to be the suggestion for Gentoo profiles in the whole –as-needed by default debate. Is this wrong? Should I drop -Wl,-O1 ?
Nope don’t worry, @-Wl,-O1@ is working, and safe. It’s just that @-Wl,-O2@ does not exist, it’s either optimised or not…It’s nothing major either way, but still…
what are the default LDFLAGS used in gentoo?
I cannot agree with your arguments. Indeed, I do have “–enable-new-dtags” and even “-Wl,-O9” in my LDFLAGS for most packages despite I know that currently it makes no difference. However, it is some sort of lazyness: When a new binutils version comes out, I do not to check whether Gentoo still applies the patch (either because it was forgotten or because perhaps Gentoo changed its policy). Similarly, for -O9: Currently, there is only one optimisation level in ld, but this might be different in a future version of binutils. So why should I not use flags which are more future-safe if they do no harm now?It is similarly with activating CFLAGS optimizations implied by -O2: There are several reasons why one might want to have such a flag enabled explicitly, one of them being that one wants to make sure that the flag is enabled also in the next compiler release even if the gcc maintainers decide to exclude the flag from the defaults.Moreover: I would not say that it is a hint to PEBKAC if somebody did not take the time to read all the gentoo patches. I stumbled over it before by accident, but I would not hold it against any gentoo user/developer or his experience with CFLAGS/LDFLAGS if he does not know about gentoo’s introduction of the automatic “–enable-new-dtags”.
Okay let’s say that ld introduces an unsafe optimisation level of @-Wl,-O2@ that assumes that all the symbols have proper visibility, kinda like in Windows, and thus that it can play with them as much as it wants.And you got it enabled globally by @-Wl,-O9@.And your system breaks in all the most absurd ways.And you start wasting our time reporting bugs we don’t give a damn about because you enabled optimisations that you shouldn’t have.Now that’s the reason why you shouldn’t be trying to “future proof” them!And if the compiler were to decide to get rid of some feature at an optimisation level (which I think is mostly uncalled for, the other way around is much much more likely!) then it probably has a very good reason that you shouldn’t try to sidestep.At any rate, I hope you never file a real bug with my packages, since I’d be closing it without even looking at it.
> ld introduces an unsafe optimisation level of -Wl,-O2Of course, there is no setting which is guaranteed to be future-proof. There is no guarantee either that -Wl,-O1 will in future version of ld not be unsafe. Every speculation about behavior of cflags/ldflags in future versions of compiler/linker is a game with probabilities. I am just claiming that it is not possible to judge the technical competence of somebody just because he estimates these probabilities differently – simply, because this is not a technical question.> And if the compiler were to decide to get rid of some feature […] probably has a very good reason that you shouldn’t try to sidestep.This was not a theoretical remark, this already happened e.g. to some -fgcse* options; IIRC was the main argument that it slows down compilation too much compared to the advantage. (Maybe now in times of tree optimization and graphite there are other arguments against it, but these were not valid when -fgcse* was removed from -O?).> since I’d be closing it without even looking at it.Of course, I cannot prevent you from doing so, as well as I couldn’t prevent you from closing bugs of all people which wear red socks (if you can find out) or which have a “p” in their email adress. However, from what I know from your blogs and other postings (which I usually highly value), I estimate you for sane enough to understand that a differing taste/probability estimation (and nothing else is the question when redundant flags are used) should not be a reason to ignore perhaps a perfectly valid technical problem.
another point is the lack of information from the emerge command, in particular “emerge –info” do not shows “–enable-new-dtags” as a global default value.p.s.: you can not blame people for not knowing the existence of NON documented default values, and i’m quite sure that it’s not an isolated case. one good way to get ride all of the useless reporting bugs is to better document the optimizations done by the gentoo devels (they also remains for new future devels as the dev-ml is quite bloated and impossible to search trought).