Summary: | sys-libs/libstdc++-v3 doesn't build | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | stefan11111 <stefan11111> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | arsen, chewi, gentoo+bugs, stefan11111 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 618550 | ||
Attachments: |
build.log
build.log.unoptimized build.log.flto config logs |
Description
stefan11111
2024-01-28 10:34:22 UTC
Seems like this is a bigger problem that just -flto. It fails to build even with CFLAGS="" CXXFLAGS="" The way to build was to put: CFLAGS="-O3 -pipe -march=native" CXXFLAGS="-O3 -pipe -march=native" in /etc/portage/env/sys-libs/libstdc++-v3. And to put this patch: --- a/gcc/cp/except.c 2024-01-28 13:17:40.624860056 +0200 +++ b/gcc/cp/except.c 2024-01-28 13:18:00.367901034 +0200 @@ -890,8 +890,7 @@ /* Can't be a C library function. */ return 0; - id = DECL_ASSEMBLER_NAME (fn); - return !!libc_name_p (IDENTIFIER_POINTER (id), IDENTIFIER_LENGTH (id)); + return 1; } /* Returns nonzero if an exception of type FROM will be caught by a in /etc/portage/patches/sys-libs/libstdc++-v3. (In reply to stefan11111 from comment #1) > Seems like this is a bigger problem that just -flto. > It fails to build even with CFLAGS="" CXXFLAGS="" > That is usually expected to fail because of no optimisation. Would help to see the log. Created attachment 883458 [details]
build.log.unoptimized
Created attachment 883459 [details]
build.log.flto
(In reply to Sam James from comment #2) > (In reply to stefan11111 from comment #1) > > Seems like this is a bigger problem that just -flto. > > It fails to build even with CFLAGS="" CXXFLAGS="" > > > > That is usually expected to fail because of no optimisation. Would help to > see the log. Didn't think that something could fail to build because of too little optimization. Seems like it does build correctly with: CFLAGS="-O3 -pipe -march=native" CXXFLAGS="-O3 -pipe -march=native" even without patching. the compiler is highly restrained when not optimizing.. why are you building this, btw? (In reply to Arsen Arsenović from comment #6) > the compiler is highly restrained when not optimizing.. > > why are you building this, btw? https://github.com/anyc/steam-overlay/issues/354 can you post the config.log(s)? Created attachment 884078 [details]
config logs
Configure logs
The endianness test fails because it's looking for an "endian:" string in conftest.o that isn't there when using -flto. There are instances of this issue in other projects. You can either perform the link by changing -c to -shared or you can add the -ffat-lto-objects flag. You don't want to do the latter everywhere though. Need to find out how best to fix it in this case. I found that the only sane way to do this is to just patch gcc/configure to add -ffat-lto-objects to ac_compile for this specific test. Presumably we don't care about also patching configure.in, which isn't really viable in this case. Once you fix that, you have to do the same thing for the floating point format test immediately afterwards. It's all for nothing though because xgcc eventually fails because it doesn't understand -flto. We have previously stripped out new flags for this reason, but this one probably has the greatest potential impact on performance. Even if we just strip out -flto entirely, configure dies almost immediately with GCC 14. :( -flto is just a symptom of a bigger problem. I was about to report a nearly identical bug for "-mno-omit-leaf-frame-pointer" and found a few dozen more. So I went and looked into it and the package is using flag-o-matic as a source of truth, i.e. anything the *host* CC thinks is valid gets passed to gcc-3.3.6, minus a very short hand-picked list of exclusions. So that's obviously wrong, and it's only going to be whack-a-mole until the end of time as new C compilers add new switches. There's no reasonable way to work around that to do the right thing either - you'd have to stop the build between stage 1 and 2, find the xgcc binary, re-test the current cflags against it, then resume the build. I've looked at the option-parsing code in gcc itself and trying to extract valid flags from there is completely out of the question. There *is* a static list of valid options in the tarball though: the manpage. Do a `grep -o ' "\(-[^=, ]*\)"' "${S}"/gcc/doc/gcc.1 | sort -u` and it pulls out a list of 955 flags that don't take params. That might be a good starting point, and it's not going to change in future. (Yeah, this doesn't magically make LTO work, but this is a compatibility lib for 20 year old binaries. My 24-core desktop isn't exactly struggling to run UT2004 for lack of it.) |