Re: Statically building when curl is present

On 15/06/2023 20:41, John Goerzen wrote:
> Thanks Denis!  Replies below...
> 
> On Thu, Jun 15 2023, Denis Corbin wrote:

[...]

> 
>> so you miss a static libgssapi_krb5 (kerberos) or miss linking with it, which
>> library dar does not use by the way... but which is very probably needed by a
>> dependency below openssl I guess.
> 
> Below curl, but yes, that's the situation.  There is no static
> libgssapi_krb5 available.

OK

> 
>> I guess they rely on what I provide at
>> https://dar.edrusb.org/dar.linux.free.fr/Releases/Dar_static/
> 
> I can't do that in Debian, for a couple of reasons:
> 
> 1) policy requiring binaries shipped by Debian must be built by Debian,
> 
> and 2) Debian supports a dozen archs beside x86_64.

Yes, I had not thought about that...

> 
>>> My best guess is that maybe they're on
>>> platforms where curl itself was compiled with fewer features.
>>
>> Well, if you build a static binary/library you can temporarily build
>> dependencies that even may be of a different version than the corresponding
>> packaged dynamically libraries available on the distro, at the end of the
>> process you get the static binary (which you can eventually strip to reduce its
>> size), then the rest goes to trash.
> 
> For lots of complex reasons, having a stripped-down curl is probably
> impractical but I could investigate I suppose. 

Sorry, I meant stripping the resulting dar_static binary

> I guess a static rb5
> may also be a possibility.  I previously got the static librsync in
> Debian, but I don't know how easy that will be for krb5.
> 
>>> Anyhow, then the question becomes: how to resolve this?
>>> As far as I can tell, the only solution is to not link dar_static with
>>> curl.  I don't see that option in configure, though; it's all or
>>> nothing with that one.
>>
>> this is an option. But try building a static flavor of libcurl based on gnutls
>> rather openssh (see the script I mentionned) it should be a bit more simple I
>> guess...
> 
> I think there are two ways forward:
> 
> 1) The dar build system is adapted to support building the
> dynamically-linked executable with curl, and the static without;

Yes It is: you could do it in two passes:

first the dynamically linked flavor

./configure --enable-shared --disable-static --disable-dar-static ... 
other options if needed
make
make DESTDIR=... install-strip

then, static one:

make clean
make distclean
./configure --disable-shared --enable-static --enable-dar-static 
--disable-curl-linking
make
make DESTDIR=... install-strip

> 
> or 2) During the build, I copy the source tree and build the entire
> thing twice, with different configure parameters.

you can avoid copying the source code, using "make clean distclean"

> 
> I have option 2 already working, I think (haven't tested it yet).
> Option 1 would be a lot more elegant on my end but possibly not on
> yours, especially given the config.h(pp) problem I mention below.
> 

from my point of view (thus not the Debian/distro point of view), the 
configure script build dar/libdar according to the provided parameters.
In consequence the static and binary flavors if built at the same time 
are expected to have the save feature set.

If you want/need different feature set for dynamic vs statically linked, 
you have to make build them independently (as proposed above).

> Both have the potential for causing problems for things that use libdar,
> as I note libdar_config.h has #define LIBDAR_HAS_CURL_CURL_H and
> LIBDAR_HAS_LIBCURL.  If the libdar.so is built with different configure
> settings than libdar.a, the headers will be incorrect for one of them.

yes, LIBDAR_HAS_CURL_CURL_H is true if the <curl/curl.h> include file is 
present in the system. It drives #include of such file.

But the configure script also validates that the library (not only its 
included file) is valid and can be linked against for a simple code. 
This advances test relies on the first (as well as dar/libdar code) to 
include or not the <curl/curl.h> file.

If the include file is not needed (for some reason, I'll get back on 
this) and the advanced test suceeded, the LIBDAR_HAS_LIBCURL macro is 
set. And this is based on that one (plus the presence of 
LIBTRHEADAR_AVAILABLE macro) that the curl feature is activated in 
libdar or not.

back to the included file aspect:
Depending on the operating system some symbols are present here or there 
or require even extra macro to be defined... to get to portability, this 
is much easy to only include files when they exist and never fail 
compilation because of a missing include file, but activate a feature 
not only based on the presence of a given include file, but on the 
effectiveness of the compilation, linking and execution of a small 
example. This is what the configure script does (see 
src/build/configure.ac template).

> 
> On the other hand, there are presently no users of libdar.a in Debian
> other than dar_static itself, and I think it highly unlikely that there
> ever would be, so perhaps I could just hand-wave that problem away.

there is webdar in conception/development phase on which I am currently 
working (libthreadar comes from a split of its code). Webdar relies on 
both libthreadar and libdar.

AFAIK, gdar also relies on libdar, maybe not (yet) packaged by Debian.

> 
>> Maybe also I could be good to ask some Debian Guru, if this is acceptable in
>> regard the Debian policy, to have inside dar_static a gnutls library compiled
>> with slightly different options gnutls vs openssl, but using the same source
>> code, same version as the official one...
> 
> Generally no (the problem would be with curl, not gnutls)...  I would
> need to get the curl source package to build a different set of library
> and dev packages.

OK

> 
>>> BTW on a totally different topic, just wanted to verify you saw
>>> https://github.com/Edrusb/DAR/issues/50
>>
>> Yes, and I think I have answered you by email... let me double check... I will
>> update the github issue... :)
> 
> Perfect, thank you!  That's one more bug closed.
> 
> - John
> 

Cheers,
Denis