On Wed, Apr 3, 2024, at 8:05 AM, Jonathan Wakely wrote:
> TBH I'd just build GCC twice and copy the .a from one build into the installed tree from the other build (renaming it to _pic.a if desired). You could then use a spec file to select the right one based on other options such as -shared or -fPIC being used.
Thanks for the advice. Very helpful.
I was getting some spooky crashes in iostream code (segfault putting a uint16_t to cerr for example) that ended up being due to a different issue (a 3rd-party library pulling in the system libstdc++.so and that clashing with my static non-PIC build). Not sure if that's maybe supposed to work, but luckily I was able to recompile that library as well and sub in my build of libstdc++.
Along the way to debugging that though, I diffed across the two gcc build tree and noticed some differences in bits/c++config.h
diff -r include/c++/13.2.0/x86_64-pc-linux-gnu/bits/c++config.h include_pic/c++/13.2.0/x86_64-pc-linux-gnu/bits/c++config.h
973c973
< /* #undef _GLIBCXX_HAVE_EXCEPTION_PTR_SINCE_GCC46 */
---
> #define _GLIBCXX_HAVE_EXCEPTION_PTR_SINCE_GCC46 1
1296c1296
< /* #undef _GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT */
---
> #define _GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT 1
1762c1762
< /* #undef _GLIBCXX_SYMVER */
---
> #define _GLIBCXX_SYMVER 1
1768c1768
< /* #undef _GLIBCXX_SYMVER_GNU */
---
> #define _GLIBCXX_SYMVER_GNU 1
I think most of them end up being no-ops as far as the include headers, but there is a difference in whether _GLIBCXX_SYMVER_GNU is defined. And that one *is* used in the iostream header.
// For construction of filebuffers for cout, cin, cerr, clog et. al.
// When the init_priority attribute is usable, we do this initialization
// in the compiled library instead (src/c++98/globals_io.cc).
#if !(_GLIBCXX_USE_INIT_PRIORITY_ATTRIBUTE \
&& __has_attribute(__init_priority__))
static ios_base::Init __ioinit;
#elif defined(_GLIBCXX_SYMVER_GNU)
__extension__ __asm (".globl _ZSt21ios_base_library_initv");
#endif
So the libstdc++ headers are ultimately slightly sensitive to whether the library was built for shared or not. And it is an iostream initialization difference, so I may ultimately have been seeing a manifestation of a similar issue. Anyways, the point for anybody else who stumbles across this is that in addition to installing the pic build of the archive, it seemed like I *also* needed to install a separate copy of the headers to use with my pic builds (via --nostdinc++).
> No, using LTO for libstdc++ is not possible. We rely on the compiler not being able to see past the boundary between translation units. It might be possible to disable LTO just for the relevant files, but somebody would have to do the work to determine which ones are the relevant ones.
I'd be happy to help, though I can't say I understand what types of issues require avoiding cross-unit visibility.
