Summary: | dev-util/ccache-4.10.1: fails tests w/ mold | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sam James <sam> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | holger, rui314 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704 https://bugs.gentoo.org/show_bug.cgi?id=761220 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 830404 |
Description
Sam James
2024-08-10 23:23:42 UTC
``` # valgrind ./unittest ==678830== Memcheck, a memory error detector ==678830== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==678830== Using Valgrind-3.24.0.GIT and LibVEX; rerun with -h for copyright info ==678830== Command: ./unittest ==678830== ==678830== Invalid read of size 8 ==678830== at 0x4EBF92E: widen (locale_facets.h:297) ==678830== by 0x4EBF92E: std::basic_ios<wchar_t, std::char_traits<wchar_t> >::init(std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >*) (basic_ios.tcc:150) ==678830== by 0x4E41896: basic_ostream (ostream:93) ==678830== by 0x4E41896: Init (ios_init.cc:106) ==678830== by 0x4E41896: std::ios_base::Init::Init() (ios_init.cc:78) ==678830== by 0x4E1D5AF: UnknownInlinedFun (ios_base_init.h:12) ==678830== by 0x4E1D5AF: _GLOBAL__sub_I.00090_globals_io.cc (globals_io.cc:109) ==678830== by 0x400487D: call_init.part.0 (dl-init.c:74) ==678830== by 0x4004982: call_init (dl-init.c:120) ==678830== by 0x4004982: _dl_init (dl-init.c:121) ==678830== by 0x401F82F: ??? (in /usr/lib64/ld-linux-x86-64.so.2) ==678830== Address 0x43 is not stack'd, malloc'd or (recently) free'd ``` I have a feeling this might be because I just tried mold, actually... Yeah, building ccache with bfd works. I think it's related to -static-libstdc++ in our ebuild for ccache but I haven't yet reproduced it manually. Ah, mold use was being overridden by cmake/FindFastestLinker.cmake. The key is indeed -static-libstdc++. In a git checkout of `v4.10.2`: ``` $ export CFLAGS="-O3" CXXFLAGS="-O3" $ export LDFLAGS="-fuse-ld=mold -static-libstdc++" $ cmake -B build -S . -GNinja -G Ninja -DDISABLE_FASTEST_LINKER=ON $ ninja -C build $ build/unittest/unittest # crash ``` (In reply to Sam James from comment #5) > $ cmake -B build -S . -GNinja -G Ninja -DDISABLE_FASTEST_LINKER=ON Needs an additional -DWARNINGS_AS_ERRORS=OFF to build, otherwise it might die on libfmt. With that it builds & passes the test using gcc-14.2.0 + mold-2.23. (In reply to Holger Hoffstätte from comment #6) > mold-2.23. *2.33* It only shows up if I build GCC 15 with mold too. It bisects to r15-510-g23ef0f68ad5fca (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704). As an aside and regardless of the underlying cause of the crash I was wondering a bit more about the issue of multiple libstdc++ instances, both statically and dynamically linked. The original motivation for linking ccache statically still seems valid, but to me somehow seems moot as long as other libs pull in libstdc++ dynamically..or is it? As mentioned on IRC it's easy to use bundled libfmt. I gave it a try and as it turns out then it's cpp-httplib's turn to pull in libstdc++. With those two set to bundled, the dependency is gone. Executable size increased by a mere ~40k. Also we have two fewer dependencies - always good for toolchain parts (see cmake vs. json-cpp requiring each other). Would this be a useful change? If so I can file a separate bug and make a patch. |