Re: Bootstrappable bitcoin release builds with Guix

[Ludovic Courtès]

Hello Carl!

Carl Dong <address@hidden> 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 address@hidden
>
> 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’.