| Summary: | K3b breaks due to -fvisibility-inlines-hidden -fvisibility=hidden, this should be filtered! | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Markus Gothe <nietzsche> |
| Component: | New packages | Assignee: | Gentoo KDE team <kde> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | minor | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Don't use daft CXXFLAGS. They are cool and all you need to do is to add 'filter-flags to the ebuild' Ciaran: Get a f*ckin' clue about diplomacy! ;p Nah, really - is this a contest between you and vapier? I don't agree with you here, btw. Hiding symbols is a good thing. What about your "supported compiler flags" document? There are too much "-ffast-math -fanother-blackhole-flag" guys. Markus: It's not that this can't be done, but all this little things take a little bit of time. This is something you should report to the k3b developers - at best with a patch included. -fvisibility*, like -ffast-math, is something that should never be set globally by the user. Any app that wants these will set them itself. Ciaran: I don't think so. By default everything should be hidden. It's the job of the developer to explicitly define the public api - not of the user (otherwise he should fork). This is what I think about it and the gcc man page states nothing else. Is there something I'm missing or is this just against your idea of *nix? Changing -fvisibility* is arsing around with the basic behaviour of the compiler. That's something for upstream to deal with, not something the user specifies. So, I thought that was the fundamental idea of gentoo... Compiling and defining the flags to use. Not really. You get to build with flags appropriate to your CPU. Personally I'd rather have it controlled purely by profile, so that daft ricer flags aren't even a possibility, but that's kinda infeasible with our current single inheritance profile setup. >Changing -fvisibility* is arsing around with the basic behaviour of the compiler. If a developer of a shared lib has to think about the API he exposes and the developer who uses the not well documented library, has an explictly made public API at least, so he can be somewhat sure he'll not be using functions which will be dead with the very next version, I call this two good things. And the user benefits by less symbols, too. >That's something for upstream to deal with, not something the user specifies. Of course it has to be fixed upstream. Nevertheless, if an application does not support this properly, I consider this as a valid bug. It's bad design. Hiding symbols should always work fine. Ahhh, then I get why it has to be fixed upstream.. Thx |
It breaks due to -fvisibility-inlines-hidden -fvisibility=hidden, this ought to be filtered! Reproducible: Always Steps to Reproduce: 1. Set CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fvisibility=hidden" 2. emerge k3b Actual Results: It breaks Expected Results: It should compile