| View previous topic :: View next topic |
| Author |
Message |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3465
|
 Posted: Fri Nov 29, 2024 1:36 pm Post subject: Firebird build fail / must be enabled with the -std=c++11 |
 |
|
I'm doing a pretty big rebuild on my ~amd64, and I can't recompile firebird. Looks like it fails due to gcc version bump.
Is there any portage variable I can use to overwrite this flag locally? What's the correct way to do that?
| Code: | db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/src/common/unicode_util.cpp -o /tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/temp/Release/common/unicode_util.o
x86_64-pc-linux-gnu-g++ -I/tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/src/include/gen -I/tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/src/include -ggdb -DFB_SEND_FLAGS=MSG_NOSIGNAL -DLINUX -DAMD64 -pipe -MMD -fPIC -fmessage-length=0 -fno-delete-null-pointer-checks -O2 -pipe -fno-strict-aliasing -fno-lifetime-dse -fno-rtti -std=gnu++03 -c /tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/src/common/sha.cpp -o /tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/temp/Release/common/sha.o
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/type_traits:35,
from /usr/include/unicode/ucol.h:1526,
from /tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/src/common/unicode_util.cpp:46:
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
32 | #error This file requires compiler and library support \
| ^~~~~
In file included from /usr/include/unicode/utrans.h:23, |
_________________
Make Computing Fun Again |
|
| Back to top |
|
 |
asturm
Developer
Joined: 05 Apr 2007
Posts: 9313
|
| Posted: Fri Nov 29, 2024 2:11 pm Post subject: |
|
|
| Do you actually need dev-db/firebird for anything? It is optional in all revdeps as far as I can see. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1725
Location: South America
|
| Posted: Fri Nov 29, 2024 2:26 pm Post subject: Re: Firebird build fail |
|
|
| szatox wrote: | | Code: | | x86_64-pc-linux-gnu-g++ -I/tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/src/include/gen -I/tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/src/include -ggdb -DFB_SEND_FLAGS=MSG_NOSIGNAL -DLINUX -DAMD64 -pipe -MMD -fPIC -fmessage-length=0 -fno-delete-null-pointer-checks -O2 -pipe -fno-strict-aliasing -fno-lifetime-dse -fno-rtti -std=gnu++03 -c /tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/src/common/sha.cpp -o /tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0/temp/Release/common/sha.o |
|
You'd have to find out where that -std=gnu++03 is coming from. If it's Firebird's build system, it's a problem, since there seems to be a dependency that needs at least C++ 2011 support (and current GCC defaults to C++ 2014 or later, I don't remember exactly, without an explicit -std option).
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3465
|
| Posted: Fri Nov 29, 2024 3:09 pm Post subject: |
|
|
| asturm wrote: | | Do you actually need dev-db/firebird for anything? It is optional in all revdeps as far as I can see. |
I'm actually in the middle of figuring that out. I have added it for libreoffice base, so it's going to take a while.
Still, I recall I've run into a similar thing with a different package some time ago, tried to patch things up I think with package.env, and failed miserably, so I thought I should take it as an opportunity to learn something.
| Quote: | | You'd have to find out where that -std=gnu++03 is coming from |
Yeah, I wonder if there is a standard way of doing this, or is it just grepping time.
_________________
Make Computing Fun Again |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22745
|
| Posted: Fri Nov 29, 2024 3:28 pm Post subject: |
|
|
I would start by checking the full build.log for the earliest instance of -std=gnu++03. If you are lucky, that instance will have some surrounding text that explains why it is there. If you are unlucky, it might just be the first source file compiled with that flag, and no indication why. I checked the firebird ebuild and did not spot that flag. It might be coming from an eclass, but it's probably from something in the firebird source.
From the header path that gcc showed, I suspect that firebird was previously built using a unicode/ucol.h that did not use <type_traits>, and that a subsequent update of dev-libs/icu brought in a newer header that now requires C++11 (or later). |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2463
|
| Posted: Fri Nov 29, 2024 3:29 pm Post subject: |
|
|
Libreoffice base does not require firebird. It's an optional dependency. If you enabled it you should know very well why, because nothing could have possibly made you do it. No required use, nothing.
| Code: |
>>> Completed (4 of 4) dev-db/firebird-3.0.10.33601.0-r2::gentoo
|
GCC 14 here. std=gnu++03 mus come from within your /etc/portage. It's nowhere to be found in the ebuild, eclasses or profiles.
EDIT: actually gnu++03 appears quite a few times in the build log. Gnu++11 appears twice.
Best Regards,
Georgi |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1725
Location: South America
|
| Posted: Fri Nov 29, 2024 5:02 pm Post subject: |
|
|
| szatox wrote: | | Yeah, I wonder if there is a standard way of doing this, or is it just grepping time. |
grep -r in the source directory (/tmp/portage/dev-db/firebird-3.0.10.33601.0-r2/work/Firebird-3.0.10.33601-0 for you apparently) before the src_compile() phase starts might actually be the fastest way if the build system is under suspicion. For example, using ebuild /pathname/of/ebuild prepare and then grepping.
_________________
| NeddySeagoon wrote: | | I'm not a witch, I'm a retired electronics engineer |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
|
Portage & Programming
