zlib link errors with master branch in a conan recipe
jonasgreen88 opened this issue · 4 comments
Hi,
If I download the conan nodesetloader recipe (https://github.com/matkonnerth/conan-nodesetloader) and changes the recipe to download the master branch of nodesetloader and depend on a recipe with open62541 v1.2-rc2 (based on https://github.com/matkonnerth/conan-open62541) I get link errors against the zlib library when it builds the examples.
The commands executed after updating the recipe:
- conan export . <user>/<channel>
- conan install nodesetloader/master@<user>/<channel> --build=nodesetloader
I execute the commands from an Ubuntu WSL terminal.
Output when linking dataTypeImport:
/usr/bin/cc -m64 -O3 -DNDEBUG -rdynamic CMakeFiles/dataTypeImport.dir/dataTypeImport.c.o -o ../../../bin/dataTypeImport -L/home/jgr/.conan/data/open62541/1.2-rc2/hms/testing/package/176b7bd27fb0759a69f81f0746a288d1ce945b98/lib -L/home/jgr/.conan/data/libxml2/2.9.10/_/_/package/27b6df5a2d9a2fd95169242269c283e3749e9459/lib -L/home/jgr/.conan/data/zlib/1.2.11/_/_/package/6af9cc7cb931c5ad942174fd7838eb655717c709/lib -L/home/jgr/.conan/data/libiconv/1.16/_/_/package/6af9cc7cb931c5ad942174fd7838eb655717c709/lib -Wl,-rpath,/home/jgr/.conan/data/open62541/1.2-rc2/hms/testing/package/176b7bd27fb0759a69f81f0746a288d1ce945b98/lib:/home/jgr/.conan/data/libxml2/2.9.10/_/_/package/27b6df5a2d9a2fd95169242269c283e3749e9459/lib:/home/jgr/.conan/data/zlib/1.2.11/_/_/package/6af9cc7cb931c5ad942174fd7838eb655717c709/lib:/home/jgr/.conan/data/libiconv/1.16/_/_/package/6af9cc7cb931c5ad942174fd7838eb655717c709/lib:/home/jgr/.conan/data/nodesetloader/master/hms/testing/build/8a1923fd3378d42bc4771c384609bcb6593ec82c/lib ../../../lib/libNodesetLoader.so /home/jgr/.conan/data/open62541/1.2-rc2/hms/testing/package/176b7bd27fb0759a69f81f0746a288d1ce945b98/lib/libopen62541.so.1.2.0 -lm -lpthread -lrt
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `gzclose'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `inflate'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `crc32'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `gzdopen'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `deflate'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `deflateInit2_'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `libiconv'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `gzopen64'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `gzread'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `inflateEnd'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `libiconv_open'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `deflateEnd'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `gzwrite'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `libiconv_close'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `inflateInit2_'
/usr/bin/ld: ../../../lib/libNodesetLoader.so: undefined reference to `gzdirect'
The examples are only linked with nodesetloader and open62541 (if BUILD_BACKEND_OPEN62541 is set).
The nodesetloader itself is linked with libxml2 but that link is defined as PRIVATE and not available for other targets (e.g. the exampels) linked to nodesetloader.
https://github.com/matkonnerth/nodesetLoader/blob/ca69ac446b17eacbc82a485893181372a5113ecc/CMakeLists.txt#L102
If I change PRIVATE to PUBLIC the issues is gone.
The same issue occurs if I have a project that depends on e.g. nodesetloader/master@<user>/<channel> in its conanfile.txt.
I will publish a PR with my solution soon.
hm, that sounds interesting, I cannot reproduce the issue at the moment (on a machine with Debian 10).
Libxml2 should be a private link dependency of the the libNodesetLoader but not of consumers of libnodesetloader.
I will try to reproduce this, maybe in an automated build here.
Is the libNodesetLoader.so built, can you provide me an ldd of it, like that:
matzy@debian:~/git/nodesetLoader/build$ ldd lib/libNodesetLoader.so
linux-vdso.so.1 (0x00007ffdb6eed000)
libxml2.so.2 => /home/matzy/.conan/data/libxml2/2.9.9///package/1c57c154c009cd61cac09788ade7ecc2322e9ae1/lib/libxml2.so.2 (0x00007f6b3ce2c000)
libopen62541.so.1 => /home/matzy/.conan/data/open62541/master/matkonnerth/testing/package/9ad98336482871f1fac7295c2c4309b923587c4c/lib/libopen62541.so.1 (0x00007f6b3c891000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6b3c69b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6b3c696000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6b3c511000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6b3c507000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6b3d310000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6b3c4e6000)
@jonasgreen88 : any news on this issue?
@jonasgreen88 : any news on this issue?
Sorry I forgot to post the ldd output. I tried to reproduce the issue but it works fine now. We do most development on Windows but now it builds fine on Linux as well. For my point we can close this issue.
ok, I have little to no experience with software development on windows, so if you have any tests/PRs regarding Windows support dont hesitate to provide them ;)