The botan library has the version appended to the name. I'm not sure if this is upstream problem or ebuild bug, but this way the library is unusable, because: • botan-config no longer exists, only botan-config-1.10, so configure scripts can't find it. • Even after manually symlinking botan-config-1.10 to botan-config, it doesn't work, since the headers are put into /usr/include/botan-1.10/botan. It is common programs do #include <botan/botan.h>, but the libraries won't be found, since botan-config --cflags returns nothing (it should output -I/usr/include/botan-1.10 in this case). If this is upstream backward-incompatible change (eg. to rename the library on purpose to distinguish it from previous versions), maybe the versions should be slotted? I encountered this problem when trying to compile out-of-portage application I develop (bind10). Also, bugs #380257 and #380445 might be somehow related to this. Reproducible: Always
Created attachment 284461 [details] emerge --info output, if it is of any help
*** Bug 380257 has been marked as a duplicate of this bug. ***
*** Bug 380445 has been marked as a duplicate of this bug. ***
Hmpf, I don't see any big problem. Upstream decided to use version in the package information so the buildsystems that search for the botan should be adapted. Also botan-config usage is bit moot as one should use something like: scarab@ugly-elf: ~/gentoo-x86/dev-libs/botan $ pkg-config --cflags botan-1.10 -I/usr/include/botan-1.10 I tested it only with the softhsm itself but it worked quite fine and was found.
Even tho I would really like to fix the issue botan configure script is some custom made configure.py. I already mailed the maintainer (here in cc) offering him that I would autotoolify the thing. Since even other distros ship botan like this with the version included, I think the patches should be done on the failing packages side.
(In reply to comment #4) > Also botan-config usage is bit moot as one should use something like: > scarab@ugly-elf: ~/gentoo-x86/dev-libs/botan $ pkg-config --cflags botan-1.10 > -I/usr/include/botan-1.10 Well, even this is slightly problematic for configure script. Notice that you still need to know the package version beforehead. Anyway, one of my colleges already asked the author about it. We'll do whatever we can in bind10, but I still find the current situation inconvenient. Thanks for your fast replies.
(In reply to comment #6) > (In reply to comment #4) > > Also botan-config usage is bit moot as one should use something like: > > scarab@ugly-elf: ~/gentoo-x86/dev-libs/botan $ pkg-config --cflags botan-1.10 > > -I/usr/include/botan-1.10 > > Well, even this is slightly problematic for configure script. Notice that you > still need to know the package version beforehead. You would probably check for all supported versions in sequence until you find one that fits.
The issue still persists today: dev-vcs/monotone-0.99.1 still does not build against dev-libs/botan-1.10.1 with following errors [excerpt]: x86_64-pc-linux-gnu-g++ -I. -I/usr/include/botan-1.10 -pipe -O2 -march=athlon64-sse3 -ftree-vectorize -Wall -W -Wno-unused -c -o transforms.o transforms.cc transforms.cc: In function ‘std::string xform(const string&, origin::type) [with XFM = Botan::Gzip_Compression, std::string = std::basic_string<char>]’: transforms.cc:198:1: error: cannot allocate an object of abstract type ‘Botan::Gzip_Compression’ gzip.hh:36:7: note: because the following virtual functions are pure within ‘Botan::Gzip_Compression’: /usr/include/botan-1.10/botan/filter.h:25:27: note: virtual std::string Botan::Filter::name() const /usr/include/botan-1.10/botan/filter.h:32:20: note: virtual void Botan::Filter::write(const byte*, size_t)
The same happens with monotone-1.0.
(In reply to comment #0) > • Even after manually symlinking botan-config-1.10 to botan-config, it > doesn't work, since the headers are put into /usr/include/botan-1.10/botan. > It is common programs do #include <botan/botan.h>, but the libraries won't > be found, since botan-config --cflags returns nothing (it should output > -I/usr/include/botan-1.10 in this case). It's fixed in botan-1.10.3, see bug #434050. (In reply to comment #8) > The issue still persists today: dev-vcs/monotone-0.99.1 still does not build > against dev-libs/botan-1.10.1 with following errors [excerpt]: > > (...) It's unrelated to this bug.
scarabeus: except of the version specific suffixes, any other issue? I could not figure it out.
Please reopen if any more input.
