$ pkg-config --modversion libunbound
Package libcrypto was not found in the pkg-config search path.
Perhaps you should add the directory containing `libcrypto.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libcrypto', required by 'libunbound', not found
Package 'libssl', required by 'libunbound', not found
Even if no package is using libunbound, having invalid dependencies listed in .pc files greatly slows down the start up time of JHBuild from 2 seconds to 340 seconds.
Qt also has a similar problem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212216.
I don't consider this a problem that the unbound port can resolve
A file like libcrypto.pc is something that should be installed by openssl. These *.pc files are apparently not delivered with the bases systems, but
if you install openssl from the ports, it will also install a libcrypto.pc.
(In reply to jaap from comment #1)
Since Libs.private already includes -lssl and -lcrypto, shouldn't it remove libcrypto and libssl from Requires when building with OpenSSL from base? I don't think it is useful to install a .pc file which nobody can use. Installing another copy of openssl for .pc files sounds like a workaround.
(In reply to Ting-Wei Lan from comment #2)
People have been complaining to the upstream about the lack of the .pc files so they decided to put the in.
Lots of ports install them. For now, I'll follow the upstream
(In reply to jaap from comment #3)
Having a .pc file is useful, but a broken .pc file is usually not. I don't know why FreeBSD base doesn't include .pc files for OpenSSL or whether OpenSSL in base will be made private libraries in future releases. I think currently the best solution may be asking the upstream to add a FreeBSD-specific workaround to replace 'libcrypto' and 'libssl' in Requires with '-lcrypto' and '-lssl' in Libs. If the upstream doesn't accept the workaround, we can still keep it as a downstream patch.
Can we close this one ?
(In reply to Martin Wilke from comment #5)
Do you mean that we should move this issue to upstream instead of keeping it here?
(In reply to Ting-Wei Lan from comment #6)
Yes, we should move it to upstream (and I did a coupled of hours ago, they got pointed to this discussion). They can better judge (i think) the consequences for other system.
and took over the suggestion for now.
So, to answer Martin, Let's close it for now.
(In reply to jaap from comment #7)
Is there any progress on this issue? I saw that unbound was updated in ports, but the latest version still has the same problem.