Re: Problems with remote repository access via sftp

Hi,

finally I succeeded building dar_static on Void Linux with musl as 
standard C library.

It was not a easy path as most dependencies lacked statically linked flavor.

Anyway, the result sounds good, I have no more the segfault I hit with 
gettext, I strongly hope you will not have neither a problem with your 
cloud provider ssh server, let me know!

the build is available here:

https://dar.edrusb.org/dar.linux.free.fr/Specific_builds/dar_static_2.7.8.RC3_x86_64_GNU_Linux_musl

and its signature

https://dar.edrusb.org/dar.linux.free.fr/Specific_builds/dar_static_2.7.8.RC3_x86_64_GNU_Linux_musl.sig


For further reference to whom might be interested in building its own 
dar_static on void+musl, here is what I had to do:

Some libraries had to be compiled by hand to get a static version:
gmplib, libnettle, are necessary for gnutls. Then you can build gnutls 
but you need to disable p11-kit at configure time of gnutls, using 
--without-pk11-kit, as this one refuses to build as static library. At 
first I tried openssl in place of gnutls but it became a nightmare in 
term of dependencies below that library... finally I could build libcurl 
on top (specifying to rely on gnutls and libssh2 which I also had to 
build manually earlier). Libthreadar was also necessary of course.

Other libraries came as static from the disto with the following packages:
bzip2-devel-1.0.8_1
e2fsprogs-devel-1.46.5_1
gmp-devel-6.2.1_1
libargon2-devel-20190702_3
libblkid-devel-2.38.1_1
libevent-devel-2.1.12_2
libgcc-devel-10.2.1pre1_3
libgcrypt-devel-1.10.1_2
libgpg-error-devel-1.45_1
libidn2-devel-2.3.3_1
liblz4-devel-1.9.4_1
liblzma-devel-5.2.7_1
libssh-devel-0.9.6_1
libssh2-devel-1.10.0_1
libssp-devel-10.2.1pre1_3
libstdc++-devel-10.2.1pre1_3
libtasn1-devel-4.18.0_1
libunistring-devel-1.0_1
libuuid-devel-2.38.1_1
libzstd-devel-1.5.2_1
lz4-devel-1.8.3_1
lzo-devel-2.10_2
musl-devel-1.1.24_11
nettle-devel-3.8_1
nghttp2-devel-1.51.0_1
openssl-devel-1.1.1s_1
p11-kit-devel-0.23.22_3
trousers-devel-0.3.15_1
unbound-devel-1.17.0_1
zlib-devel-1.2.13_1
(well this is a raw copy of the -devel packages installed at this time 
on the system: openssl and p11-kit are not necessary, they are just the 
traces of my tentatives.

For compilation a lot of packages go by default to /usr/local I needed 
to set the environment variable PKG_CONFIG_LIBDIR at the beginning of 
this compilation process adding /usr/local/lib/pkgconfig to the 
defaults, for it works flawlessly:

export 
PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig:/usr/share/pkgconfig:/usr/local/lib/pkgconfig

Cheers,
Denis


On 20/11/2022 21:40, Denis Corbin wrote:
> On 16/11/2022 21:14, Martin Michel wrote:
>> Hi Denis,
>>
>>> looking at the stack at the time of the segfault, we saw this
>>> occurring "below" libcurl in getaddrinfo() call (part of glibc). There
>>> is a bug
>>> in that part that could explain this problem (affecting only
>>> statically linked binaries in multi-threaded context).
>>
>> Interesting.  I remember statically compiling against getaddrinfo() from
>> glibc has some issues.  Wasn't it the case that those binaries only work
>> if you run them on the same glibc version?
> 
> well, normally a statically linked binary has only the kernel as 
> interface nothing else of the operating system...
> 
>>  In my case it was not about
>> multi-threading though.  My workaround back at that time was that I
>> resorted to musl libc, compiled the binary on Alpine Linux and shared it
>> from there.
>>
> 
>> [...]
>>
>> Note that I am using Void glibc version, there is also a musl one.  If
>> the bug is due to the glibc stuff, I would guess, it will work with
>> musl.
> 
> Good idea. I'm now currently doing that, already spent some time 
> discovering Void Linux distro, installing adding the necessary packages, 
> and building the static flavors of needed libraries that were not 
> provided. Well, I'm still having some issue building a static libcurl 
> version but that's a matter of time.
> 
>>
>> Best regards,
>> Martin
>>
> 
> Cheers,
> Denis
>