sys-apps/paludis does not emerge with LDFLAGS="-Wl,--as-needed" set: checking for posix_openpt... yes checking for ptsname... yes checking for grantpt... yes checking for unlockpt... yes checking for go faster stripes... as-needed configure: error: Bad ricer. No bagel. !!! Please attach the following file when filing a report to bugs.gentoo.org: !!! /var/tmp/portage/paludis-0.6.7/work/paludis-0.6.7/config.log !!! ERROR: sys-apps/paludis-0.6.7 failed. Is it possible to either correct the linking and remove the check from configure or let the ebuild filter out that linking-flag?
The linking can't (reasonably) be fixed since as-needed is broken by design. I could add filtering in the ebuild, but there was resistance to that idea last time it was mentioned so I haven't yet.
Ebuild filtering should only be done for reasonable flags that happen to break in certain weird situations. It's not reasonable to filter -ffast-math or -fno-enforce-eh-specs or --as-needed, since anyone using these globally is deliberately instructing the toolchain to produce broken code anyway.
Well now, let's see what is broken by design... --as-needed? No, read http://www.gentoo.org/proj/en/qa/asneeded.xml. What's broken are applications which don't compile with it. There's even a likelyhood that in the not so far future you'll need --no-as-needed because the default will switch. (At least there are gcc developers who want to go into this direction once it's common enough.) sys-apps/paludis? For sure! You know what the reason for the error is? They check for compiler/linker flags they don't like and instead of simply filtering them out they abort configure. That's braindead! And now to the real fun: I patched configure.ac to stop filtering on as-needed and visibility. I use -fvisibility-inlines=hidden which should be safe as well as long as there are no GCC bugs and everything is compiled with the same version of it. Nothing for binary distribution because of the latter restriction but fine for Gentoo where you can do an emerge -e world on a new version. Patched the ebuild and ran emerge again to see why they filter it - result: none! It went through without any additional changes. Now try to explain me why paludis isn't doing complete nonsense here. At the very least they should change their code to filtering instead of stopping without sane reason.
Created attachment 98943 [details, diff] A patch which should have no need to exist. :-(
Created attachment 98944 [details] Updated ebuild which uses the patch.
BTW I don't use paludis myself, I just fixed this bug because -as-needed bugs get less attention then I'd like them to get and I didn't replace their configure check with a sane filtering for the remaining stuff they filter since those are at least flags like -ffast-math which are really no good idea.
(In reply to comment #3) > Well now, let's see what is broken by design... > > --as-needed? No, read http://www.gentoo.org/proj/en/qa/asneeded.xml. See bug #148879. > What's broken are applications which don't compile with it. Not true. Read http://ciaranm.org/show_post.pl?post_id=13 and don't say anything else until you understand it. > sys-apps/paludis? For sure! You know what the reason for the error is? They > check for compiler/linker flags they don't like and instead of simply filtering > them out they abort configure. That's braindead! Wrong. We check for a few flags that tell the toolchain to produce broken code, and abort rather than screwing up at runtime. > And now to the real fun: I patched configure.ac to stop filtering on as-needed > and visibility. I use -fvisibility-inlines=hidden which should be safe as well > as long as there are no GCC bugs and everything is compiled with the same > version of it. Actually, visibility on inlines can break arbitrarily too. In C++, inlining is a guideline, not a requirement, and the compiler is free to ignore it as necessary. We're going full out -fvisibility=hidden for 0.8. For 0.6, you shouldn't mess with visibility at all because it can cause breakages that are the fault of the toolchain, not the code. > Now try to explain me why paludis isn't doing complete nonsense here. We're protecting you from your own stupidity. (In reply to comment #6) > BTW I don't use paludis myself, I just fixed this bug because -as-needed bugs > get less attention then I'd like them to get and I didn't replace their > configure check with a sane filtering for the remaining stuff they filter since > those are at least flags like -ffast-math which are really no good idea. -ffast-math is equally as bad as --as-needed.
nothing to be done here
So you're telling me that --as-needed can break applications which use certain dynamic modules methods. Right, it does. But the conclusion is done the wrong way. That behaviour is used only by a selected few programs which should simply filter --as-need or add -Wl,--no-as-needed at the end of the command line to be sure. Visibility on inlines can break, yes and I do know that it's only a hint to the compiler. Which happens to be the same one which decides wheter to mark this particular method hidden. It's not as if everything that could be made inline is marked as hidden but rather that only methods which actually are inlined all the time get it. If GCC marks a method inline with this flag and then doesn't inline it at a certain call that's a bug in GCC. Plain and simple. You're protecting me from my own stupidity? Sorry to say, but I'm a reasonable individual and like to make my own decisions. I've activated --as-needed, -fvisibility-inlines=hidden and even -ftree-vectorize globally and so far I've only encountered problems with applications which didn't build, no runtime errors at all. Seems like those flags are not as dangerous as some people want you to believe and applications which actually do break on them are filtering already. But mainly - protecting me by aborting instead of simply filtering the flag is stupid. You're trying to force your opinion on me without good reason. If you're really convinced you should filter, print a warning that you filtered a flag, delay for a few seconds, beep, print a link or whatever but then continue! A user who's got such flags set has made a deliberate decision usually and is stating that (s)he's willing to take the risk of applications breaking. If you know that yours does, protect but don't decide for others. Of course it would be best if applications selectively activated such a flag if it doesn't hurt them but this is unrealistic. It's much easier to filter / patch the much smaller number of applications which break. PS: I'm sorry to see such ignorant people around here. You've provided nothing which makes me believe that the behaviour of paludis is correct. I'm happy that I've got no need to use it and knowing this I certainly won't use it ever unless there's a really compelling reason.
(In reply to comment #9) > So you're telling me that --as-needed can break applications which use certain > dynamic modules methods. Right, it does. But the conclusion is done the wrong > way. That behaviour is used only by a selected few programs which should simply > filter --as-need or add -Wl,--no-as-needed at the end of the command line to be > sure. And I suppose you think upstream should add -fno-fast-math (another GNU specific switch) as well, right? > But mainly - protecting me by aborting instead of simply filtering the flag is > stupid. You're trying to force your opinion on me without good reason. If > you're really convinced you should filter, print a warning that you filtered a > flag, delay for a few seconds, beep, print a link or whatever but then > continue! Doing that in an ebuild is a possibility. Doing it upstream is not. However, Gentoo policy says that flag filtering in ebuilds for flags that are known to be broken and unsafe for global use (e.g. --as-needed) is optional, and something that ebuild maintainers *may* put in if asked nicely, not something that *should* be done. You might want to consider what kind of impression you're creating by ranting, making outright incorrect assertions and blaming other people for your mistakes. Were I spb, I'd leave this bug as INVALID and not even consider adding flag filtering to the ebuild until you apologise and ask again nicely. > PS: I'm sorry to see such ignorant people around here. You've provided nothing > which makes me believe that the behaviour of paludis is correct. I'm happy that > I've got no need to use it and knowing this I certainly won't use it ever > unless there's a really compelling reason. Which part of http://ciaranm.org/show_post.pl?post_id=13 didn't you understand? The only ignorant person around here is you, as demonstated by your lack of knowledge of how --as-needed is unsafe.
(In reply to comment #10) > And I suppose you think upstream should add -fno-fast-math (another GNU > specific switch) as well, right? No, I think --as-needed is about the only one where this makes sense. -ffast-math is a flag which is usefull only for a few programs like --as-needed is dangerous only for a few programs. > > But mainly - protecting me by aborting instead of simply filtering the flag is > > stupid. > Doing that in an ebuild is a possibility. Doing it upstream is not. I remain of the opinion that the upstream behavious is wrong. Filter as much as you like but don't abort configure without good reason. At the very least change your senseless error message. How should I gather from "Bad ricer. No bagel." that you consider as-needed a bad flag and did abort for this reason? You should at the very least write something like "paludis doesn't support the flags mentioned above. Please remove them from your CFLAGS/LDFLAGS and call configure again." > However, Gentoo policy says that flag filtering in ebuilds for flags that are > known to be broken and unsafe for global use (e.g. --as-needed) is optional, > and something that ebuild maintainers *may* put in if asked nicely, not > something that *should* be done. I don't want the ebuild to filter the flag actually. I consider it best when this is done by applications which actually do break upstream. > You might want to consider what kind of impression you're creating by ranting, > making outright incorrect assertions and blaming other people for your > mistakes. Were I spb, I'd leave this bug as INVALID and not even consider > adding flag filtering to the ebuild until you apologise and ask again nicely. It's not my mistake. I've just searched for an open as-needed bug trying to fix it. Looking into configure.ac did shock me. > Which part of http://ciaranm.org/show_post.pl?post_id=13 didn't you understand? > The only ignorant person around here is you, as demonstated by your lack of > knowledge of how --as-needed is unsafe. None, actually it didn't tell me anything I didn't know. Optimal solution would be for GCC and binutils to improve to the point where it doesn't happen anymore. It still remains the case that the vast majority of programs has no need for static initialization of external modules which leads to this problem. as-needed has too much on the positive side to be removed just for the few programs which break at it. Unfortunately you can't hope for application designers to use it wherever possible unlike -ffast-math which is usually activated by the programs which may use it safely. But truth to be told, I see no chance that you'll convince me of your opinion and none that I'll convince you of mine either. Upstream should just consider to go more towards the Gentoo way of allowing people to burn themself if they want. Filter the flags, print a warning but no more. I'm using AMD64 so I always get a warning about -fvisibility-inlines=hidden. Right, it's good to warn a user that it's risky in case it's not used without knowing the risk. But I know what I'm doing and in the very rare case that an application breaks with it, I remove it and compile again. I'm investigating a little more time and accept a small risk of runtime breakage but I get a faster system for it. It's a trade-off which I calculated and considered good for me. It's even nicer on Gentoo which usually does filter the flags where they're harmful already but again: in this case, I clearly see the error in the behavious mandated by configure.ac. BTW I accept that applications which don't work with it are not actually broken but well maintained ones should simply add filtering for it. Anyone with enough knowledge to use such rather advanced C++ methods should have no problems with this at all.
Actually, maybe I should have been more specific. I've got no problem with paludis not supporting some flags. But I do have huge problems with the way it handles them. Breaking hard instead of filtering is bad enough but together with this rather ironic if not sarcastic error message which doesn't even strongly hint on the problem I call it ignorant and stupid. Might be that the message is easy to understand for a native speaker but to me it makes no sense at all.
