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