Open kone-tlammi opened 5 days ago
IIRC the problem here is that cmake dependency lookup only exposes the absolute path to a library. Meson tries to avoid this whenever it can, but "whenever it can" means when using find_library or dependency.
For OpenSSL in particular meson has a method: 'system'
that will probably in most cases yield a superior result rather than using cmake. The example only works because it hardcodes an (unlikely) method. Other dependencies especially where the upstream project doesn't provide pkgconfig files at all and the only dependency finder is cmake, would make a more useful example.
Yeah I thought this might be a cmake issue. In my actual use case the OpenSSL is not a direct dependency but acquired via paho-mqtt-c. I avoided the issue by replacing the dependencies with bunch of calls to cpp.find_library
. I guess there is no better approach here?
Well, https://github.com/eclipse-paho/paho.mqtt.c/pull/756 might help.
Describe the bug When using
pkgconfig
module to generate .pc files for a project that depend on cmake projects the resulting .pc file has absolute paths to libraries.This behavior causes issues with Yocto builds where resulting .pc files have absolute paths pointing to a different sysroot which might not exist when some other component is consuming the said .pc.
To Reproduce
meson.build
Resulting
lib.pc
Expected behavior Libs field should have
-lcrypto -lssl
or there should be some more manual way to avoid the current behavior.system parameters
meson --version
ninja --version
if it's a Ninja build