Re: Statically building when curl is present

I should add - I get a warning about missing gpgme in this scenario.  I
see you disabled it in your dar_static build, presumably for the same
reason?  I guess gpgme must use dlopen() or something.

I have chosen to document this for the moment; the warning is harmless.
But I could also disable gpgme linking as you did in yours.

- John

On Tue, Jun 20 2023, John Goerzen wrote:

> 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