Re: Problems building dar_static

Mihai Moldovan <[email protected]> Thu, 18 Jul 2019 13:28:13 +0200
Newsgroups	gmane.comp.sysutils.backup.dar.support
Message-ID	<[email protected]>
* On 7/18/19 1:01 PM, Matus UHLAR - fantomas wrote:
> i have updated to debian 10 and this is in news (apt-listchanges shows it at
> upgrade time):
>
>   * From Linux 4.10, the old 'virtual syscall' interface on 64-bit PCs
>     (amd64) is disabled.  This breaks chroot environments and containers
>     that use (e)glibc 2.13 and earlier, including those based on Debian 7
>     or RHEL/CentOS 6.  To re-enable it, set the kernel parameter:
>     vsyscall=emulate
>
>> The static binary might run fine if it's not bundling a libc,
>> but that's more or less just a guess. Users should be aware that even static
>> binaries can problematic sometimes.

Right. I learned that the hard way when upgrading to a buster-based kernel from
stretch-backports a month ago or so. I also don't know what that means for the
static dar binary, though. Since the VSYSCALL interface is typically used by the
libc, and the libc is not bundled in static binaries as far as I remember, this
might not be too problematic. It totally depends on what the compiler generated
there when compiling dar. Even so, that's just ONE example of things blowing up
unexpectedly.

I mainly wanted to bring attention to the fact that building a static binary
does not necessarily mean that it will be easily portable forever; neither
forwards nor backwards.


> btw, debian already has dar-static binary package for some time ;-)

Yes, it does, but it also was useless *for me* the last time I tried it - just
like the default shared binary in Debian.


OP is looking for remote repository support and the chances of this more exotic
feature not being available in the packaged static binary isn't slim.

I just checked the control file and it looks like it doesn't have an explicit
dependency upon libcurl4-*-dev, BUT conflicts with at least
libcurl4-{gnutls,openssl}-dev. libcurl4-nss-dev MIGHT hence be getting pulled in
a dependency of something else, but I wouldn't bet on it. Since there are also
no dependencies on libcurl4-nss-dev on either the dar or libdar64-6000 packages,
I'll assume that remote repository support is disabled by default in the Debian
packages.


The part that made it useless for me is that neither dar nor dar-static are
built using ifinitint support. My file system has a lot of files. Apparently
more than would fit in a native 64-bit integer at least.

I typically build a slightly modified version of the Debian package for local
use whenever needed (properly, via sbuild in a clean build chroot), since the
default one sadly doesn't fit my use case.


Mihai

_______________________________________________
Dar-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dar-support
signature.asc (application/pgp-signature, 899 B)