Re: Statically building when curl is present

John Goerzen <[email protected]> Tue, 20 Jun 2023 19:28:02 -0500
Newsgroups gmane.comp.sysutils.backup.dar.support
Message-ID <[email protected]>
On Fri, Jun 16 2023, Denis Corbin wrote:

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

This is what I wound up doing, though I didn't have to copy.  It turns
out there is precedent in Debian for doing this using most
autoconf-based tools' capability to have a build directory separate from
the source directory, so I do it that way.

>> 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.

Yes, but I believe there is no reason to statically link any of those,
so they could all use libdar.so.

Incidentally, I copied the dar_static built on a system with glibc,
inside an Alpine Linux docker container (which has only musl libc) and
it worked fine.  I'm not sure what dar is using getpwnam() for, since it
appears to store numeric uids/gids anyhow, but at least I created,
listed, and extracted archives and dar_static preserved numeric
uids/gids as expected.  So I think the solution I've got in Debian is
good to go.

- John