Hello Carl! Carl Dong <[email protected]> skribis:
>> > 1. libstdc++ would not link statically even with "-static-libstdc++". The >> > hack >> > was to remove the .la file under $LIBRARY_PATH. >> > >> >> Weird. Could you send a small test case for this [email protected]? > > I realized afterwards that this is actually another problem. The real problem > is that configure insists on adding `-lstdc++` to `config.status` and > `libtool` even when `-static-libstdc++` is in `LDFLAGS`. I will do some more > digging but it seems to only happen in Guix environments. I would appreciate > any insight. Weird. You did check ‘gcc -dumpspecs’ already, right? >> > 2. Upon inspection of the binaries produced at the end of this process, >> > they all >> > had rpaths. The hack was to use patchelf --remove-rpath on them. >> > >> >> Yes, ‘ld-wrapper’ and our ‘gcc’ packages add those on purpose; they’re >> required for dynamically-linked binaries. But you’re producing >> statically-linked executables in the end, right? > > We're producing a executable that's dynamically linked in the end, we perform > a few checks to make sure that only the libraries we want to dynamically link > to are dynamically linked to: > https://github.com/bitcoin/bitcoin/blob/40a720acb8472f6e8afdf8b8d1897f35d58daf1f/contrib/devtools/symbol-check.py#L57. > I have resorted to modifying the default gcc package to omit the > `GNU_USER_TARGET_LIB_SPEC` substitute which is how the rpaths sneak in. I > suspect that using a specfile would have also worked? Yes I think so. >> > 3. Upon inspection of the binaries produced at the end of this process, >> > their >> > interpreters all had a `/gnu/store/blahblah-glibc-2.28' prefix. The >> > hack was >> > to use patchelf --set-interpreter on them. >> > >> >> To use /lib/ld-linux-x86-64.so.2 instead? >> >> You can do that, but there’s a risk: this is assuming that the loader >> and libc on the user’s machine are compatible with those you built >> against. > > Right. This is why we check our libc version is one that is reasonably old to > work on old systems: > https://github.com/bitcoin/bitcoin/blob/40a720acb8472f6e8afdf8b8d1897f35d58daf1f/contrib/devtools/symbol-check.py#L38. > I'm not familiar with how the loader might be incompatible? I don’t have any specific example in mind and the risk is probably low given that it’s a stable piece of software. The loader does know and use libc internals, so there could be problems in theory. Thanks, Ludo’.
