This package fails to build on an unstable system. Attached relevant logs and emerge --info
Created attachment 745212 [details] emerge_info emerge --info
Created attachment 745215 [details] openjdk-17_p35:20211016-203104.log.xz build log (compressed because it exceeds attachment limit, use 'xzless' to read it)
Created attachment 745431 [details, diff] Proposed fix
I can't reproduce that. any ideas what triggers it?
Seems to be triggered by -fexceptions in *FLAGS. Maybe we should filter this out?
Build system uses ... -fno-rtti -fno-exceptions ..., but before user's ${CXXFLAGS} which can override build system's defaults...
I think that users should not add -frtti / -fno-rtti / -fexceptions / -fno-exceptions to *FLAGS. Upstreams should know better if their packages want RTTI / handling of exceptions or not.
^ I agree with that. well I can add a filter, but we don't generally add a filter for every flag that may break the build, unless it's common one or in special cases. users are free to shoot their knees. problem is that it's being reported as legitimate bug. I'll leave ebuild as is for now. from gcc manual: Mixing code compiled with -frtti with that compiled with -fno-rtti may not work. For example, programs may fail to link if a class compiled with -fno-rtti is used as a base for a class compiled with -frtti. fexeptions is tricky too. leave it alone, unless you know what you are doing. it's already enabled by default for c++ and disabled for C. here I see it enabled in cflags too... from manual: -fexceptions Enable exception handling. Generates extra code needed to propagate exceptions. For some targets, this implies GCC generates frame unwind information for all functions, which can produce significant data size overhead, although it does not affect execution. If you do not specify this option, GCC enables it by default for languages like C++ that normally require exception handling, and disables it for languages like C that do not normally require it. However, you may need to enable this option when compiling C code that needs to interoperate properly with exception handlers written in C++. You may also wish to disable this option if you are compiling older C++ programs that don’t use exception handling.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dc9101977f7d37c51a360b1353736441b225d17b commit dc9101977f7d37c51a360b1353736441b225d17b Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2021-10-19 18:23:05 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2021-10-19 18:23:34 +0000 dev-java/openjdk: filter out -fexceptions Bug: https://bugs.gentoo.org/818502 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-java/openjdk/openjdk-11.0.11_p9-r1.ebuild | 3 +++ dev-java/openjdk/openjdk-11.0.12_p7.ebuild | 3 +++ dev-java/openjdk/openjdk-17_p35.ebuild | 3 +++ dev-java/openjdk/openjdk-8.292_p10.ebuild | 3 +++ dev-java/openjdk/openjdk-8.302_p08.ebuild | 3 +++ 5 files changed, 15 insertions(+)
changed my mind and added a filter. but still, please don't set those flags globally and may be don't set at all.
(In reply to Georgy Yakovlev from comment #10) > changed my mind and added a filter. > but still, please don't set those flags globally and may be don't set at all. Right. Generally, in Gentoo, we try to embrace quirky configurations _if people explain them well and have rationale_. We cannot and will not support random *FLAGS which look interesting that people decided to use globally. A lot of interesting optimisations (and in this case, they're not even always optimisations, just.. weird changes) don't makes sense globally and nor do these options. Right now, your bugs tend to be "here's my box, a bunch of stuff is different about it which I won't explain, and I've made no attempt to narrow down which of my crazy options is relevant". It's very hard to act on them. Plus they're automated and usually lacking in any commentary at all. Please take the time to file more detailed bugs, with fewer options set, and/or an attempt to isolate the problematic feature(s). A bug report that something fails with -Os -fexceptions, slibtool, -native-symlinks, dash, and custom bashrc is not actionable. Even better, if you can identify something is broken with something simple like dash, please provide a patch. If something looks harmless and has a patch, we're far more willing to apply it than dspend time debugging something with not much information.
