Re: [Dar-support] Build with Remote Repository Support

[Denis C. <dar...@fr...>]

Le 17/06/2022 à 22:07, Martin Michel a écrit :
> Hey Denis,
> 
> Thanks for your quick reply and, even more important, thanks for giving
> us dar! 

you are welcome! :)

>I have not used it so far but it really looks like all I have
> ever needed for my backups. And I am looking forward to get it
> implemented soon.
> 
> 
>> you probably miss libthreadar
>>
>> http://dar.linux.free.fr/doc/from_sources.html
> 
> Yes, that was the missing piece. Sorry to bother you with me not reading
> the documentation properly. I overlooked the entry as my eyes were stuck
> in the table showing the dependencies in distro packages. Here "Embedded
> sftp/ftp support" just showed libcurl-dev, but the sections before give
> enough details.

no problem, I admit I hit the same when looking to anwer you with a
reference to the documentation.

A table is missing: from features to requirements. I will ad or replace
this part of the document as it may make more sense than the way the
information is shown today.

> 
> 
> Before I go into a rabbit hole of trying to compile the statically
> linked dar_static, does it make sense at all to do this with the
> sftp/ftp support enabled via libcurl?

it depends on what you need to restore your data. But if you need
libcurl to restore on a system where you have no enough space to store
the backup, or do not want to slice it up (dar_xform can do it
afterward) and then have to upload slice by slice, this may be interresting.

>  There is an upfront warning on the
> curl homepage
> () and my
> experiences with other more or less complex software applications were
> also not promising.

the configure script provided with dar makes a lot of testing to
validate that the requirement are satisfied for it activate a given
feature when you will run "make" / "make install-strip" eventually with
other options. So I'm confident you should not find more block on the
road than expected.


> My distro does not provide the libgpgme.a archive,
> so I would have to build custom packages all the way and I would not go
> down this path if libcurl will be another show-stopper. 

To build a static dar version, it is not necessary to build a package of
the missing static libraries, they must just be available at the time of
compilation/linking. You can build and install them in some particular
directory (/opt/libcurl for example) and then use the following to build
dar:

adapt the /opt/libcurl/{lib,include} paths to where are located the
header and static library:

export LDFLAGS="-L/opt/libcurl/lib -L/opt/other/lib ..."
export CXXFLAGS=-I/opt/libcurl/include -I/opt/other/include ..."
export CFLAGS="$CXXFLAGS"

./configure
make
make install-strip

preferably install as static library versions required by dar the same
version as the one your system provides as dynamic, else you should also
play with LD_LIBRARY_PATH at building time and any time to execute dar.

> I definitely
> want the sftp feature but I am not sure about the need for dar_static. I
> assume it is best practice to have a static executable along (old)
> archives, what are other use cases?

that's effectively a good thing to have.

Last, note that I provide statically linked dar binaries for
Linux/x86_64 kernel/CPU at:

https://dar.edrusb.org/dar.linux.free.fr/Releases/Dar_static/x86_64_GNU_Linux/

> 
> Kind regards,
> Martin
> 
>