As currently packaged, the davix_copy library is neither build nor installed. -DENABLE_THIRD_PARTY_COPY=TRUE fixes that, potentially should be USE-flagged. The davix_copy library is for example required by gfal2 (not packaged for Gentoo yet).
What should the USE flag be? Would there be any drawback to just leave it always enabled instead of providing the USE flag for it?
Dear Guilherme, seeing that e.g. Debian appears to have this on by default in their main package, and since it only "adds" a library without extra dependencies as far as I can see, I believe there is no real drawback from just having this always enabled. There's also no global USE flag this would cleanly match. Checking the upstream source, it's also always on for their rpmbuild (davix.spec) and their Debian code (debian/rules), their test-suite (test/run-tests.sh) and those mycompile.sh / myasan.sh files shipped with the source. So in fact, it's rather astonishing the default in CMakeLists.txt is FALSE ;-). Cheers, Oliver
This does add a new dependency on net-libs/gsoap[ssl]. If it works on macOS, which I cannot test right now, unfortunately, then I will add the dependency without a USE flag. If gsoap doesn't work on macOS, then I will add with a USE flag, to allow davix and ROOT to be built for macOS as well later.
Thanks, I missed that additional dependency indeed!
Ping! Any news on this, Guillherme? BTW. Having just locally patched a davix ebuild to enable third-party copies I discovered that if net-libs/gsoap has been emerged with USE=gnutls, it causes the linking of davix to fail due to a lot of GnuTLS-related symbols not being resolved. Not sure if this is a problem with gsoap pkg-config files or that it is necessary for both packages to be linked against the same SSL library.
(In reply to Marek Szuba from comment #5) > Ping! Any news on this, Guillherme? BTW. Having just locally patched a davix > ebuild to enable third-party copies I discovered that if net-libs/gsoap has > been emerged with USE=gnutls, it causes the linking of davix to fail due to > a lot of GnuTLS-related symbols not being resolved. Not sure if this is a > problem with gsoap pkg-config files or that it is necessary for both > packages to be linked against the same SSL library. There is a new version of davix out (0.7.6). I will try to fix this bug when doing the version bump, but any help is welcome. If you have a patched ebuild and want to push the modification to the tree, feel free to do it, just refer to this bug in the commit message. I guess we will need to find a way to make sure the same ssl library is used in both. I've built davix with the tools before, and didn't have problems with missing symbols.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=92334172cbbf1d15d0ee90c20f4af7f5c26b0062 commit 92334172cbbf1d15d0ee90c20f4af7f5c26b0062 Author: Guilherme Amadio <amadio@gentoo.org> AuthorDate: 2020-06-07 12:15:47 +0000 Commit: Guilherme Amadio <amadio@gentoo.org> CommitDate: 2020-06-07 12:16:09 +0000 net-libs/davix: version bump to 0.7.6 This ebuild enables libdavix_copy by default. Closes: https://bugs.gentoo.org/689556 Package-Manager: Portage-2.3.100, Repoman-2.3.22 Signed-off-by: Guilherme Amadio <amadio@gentoo.org> net-libs/davix/Manifest | 1 + net-libs/davix/davix-0.7.6.ebuild | 81 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 82 insertions(+)
@marecki Davix only has logic for OpenSSL, so I required gsoap with OpenSSL and not libressl or gnutls for the moment. If it becomes a problem, we can change that later. I enabled davix_copy by default without adding a USE flag.
