search

microsoft / vcpkg

C++ Library Manager for Windows, Linux, and MacOS
MIT License
23.26k stars 6.41k forks source link

qt5-webengine links many system libraries that it should get from vcpkg #36854

Closed tsondergaard closed 2 months ago

tsondergaard commented 9 months ago

Describe the bug qt5-webengine picks up many system libraries that it should get from vcpkg. It also picks up both vcpkg and system libraries of some libraries, at least in debug configuration where it links both system libfreetype.so.xx and libfreetyped.so.

Environment

To Reproduce Steps to reproduce the behavior:

  1. sudo dnf install freetype-devel
  2. ./vcpkg install qt5-webengine --triplet x64-linux-dynamic
  3. ldd .../x64-linux-dynamic/debug/lib/libQt5WebEngine.so.5 Repro code when

Expected behavior Vcpkg should not link system versions of

Failure logs

$ ldd vcpkg_installed/x64-linux-dynamic/debug/lib/libQt5WebEngine.so.5 |grep -v home/ts
        linux-vdso.so.1 (0x00007ffed53a6000)
        libGL.so.1 => /lib64/libGL.so.1 (0x00007f489d81d000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f489d31f000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f489d244000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f489d229000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f489d01e000)
        libicui18n.so.67 => /lib64/libicui18n.so.67 (0x00007f489cd18000)
        libicuuc.so.67 => /lib64/libicuuc.so.67 (0x00007f489cb2d000)
        libicudata.so.67 => /lib64/libicudata.so.67 (0x00007f489b014000)
        libsmime3.so => /lib64/libsmime3.so (0x00007f489afe9000)
        libnss3.so => /lib64/libnss3.so (0x00007f489aeb4000)
        libnssutil3.so => /lib64/libnssutil3.so (0x00007f489ae7e000)
        libplds4.so => /lib64/libplds4.so (0x00007f489ae79000)
        libplc4.so => /lib64/libplc4.so (0x00007f489ae72000)
        libnspr4.so => /lib64/libnspr4.so (0x00007f489ae2f000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f489ae1b000)
        libX11.so.6 => /lib64/libX11.so.6 (0x00007f489ac09000)
        libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00007f489ac04000)
        libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f489abff000)
        libXext.so.6 => /lib64/libXext.so.6 (0x00007f489abea000)
        libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f489abe1000)
        libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f489abd4000)
        libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f489abc5000)
        libXtst.so.6 => /lib64/libXtst.so.6 (0x00007f489abbc000)
        libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f489ab85000)
        libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f489a9d4000)
        libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f489a25a000)
        libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f489a22f000)
        libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f489a1ea000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f48baf56000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f489a0ef000)
        libGLX.so.0 => /lib64/libGLX.so.0 (0x00007f489989e000)
        libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007f48997e4000)
        libXi.so.6 => /lib64/libXi.so.6 (0x00007f48997d2000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f48997b5000)
        libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f48997a5000)
        libXau.so.6 => /lib64/libXau.so.6 (0x00007f48996a1000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f489945c000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f4899441000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f489943a000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f4899429000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f4899422000)
        libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f48993ff000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f48992f4000)
        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f4899258000)

The X11 and OpenGL libraries are fine to be system, but ICU, png, bz2, pcre2 and many other should not be picked up from the host system.

Additional context Add any other context about the problem here.

SchaichAlonso commented 8 months ago

Is this problem specific to vcpkg deployed libraries or are the targets your project generates using add_executable and add_library, while using the vcpkg toolchain, also affected?

The vcpkg libraries themselves don't contain location information because that data is stripped out of the libraries when they are packaged. RPATHs are counter-intuitive in packages, as they would describe a build agent's setup, but the setup they need to abide to is the deploy target's one instead.

On systems supporting RPaths, cmake will instruct the linker to embed rpath data into each executable and library it emits. This will allow you to execute a binary linked against vcpkg provisioned libraries without having to override LD_LIBRARY_PATH.

EDIT: x64-linux-dynamic triplet results in executable with rpath data having been embedded into it for vcpkg libraries on github actions:

2: Test command: /usr/bin/ldd "vcpkg-sqlite-demo"
2: Working Directory: /home/runner/work/vcpkg-sqlite-demo/vcpkg-sqlite-demo/build
2: Test timeout computed to be: 10000000
2:  linux-vdso.so.1 (0x00007fff8a7e8000)
2:  libsqlite3.so => /home/runner/work/vcpkg-sqlite-demo/vcpkg-sqlite-demo/build/vcpkg_installed/x64-linux-dynamic/debug/lib/libsqlite3.so (0x00007fa802113000)
2:  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa801e00000)
2:  /lib64/ld-linux-x86-64.so.2 (0x00007fa8022e6000)

Project: https://github.com/PurpleFlowerGarden/vcpkg-sqlite-demo/tree/29c80a73aa49cd0fddac616a33134b028feeb9dd Workflow Reference: https://github.com/PurpleFlowerGarden/vcpkg-sqlite-demo/actions/runs/7992423522/job/21825874115#step:5:28

tsondergaard commented 8 months ago

This is a problem with the qt5-webengine vcpkg port itself and doesn't involve my own project. Since opening this bug I have noticed that this problem is a known issue in the port, as is evident from this line: qt5-webengine/portfile.cmake:15. This comment is from commit bb7ccc4b90d6 but it does not provide a reason for why qt5-webengine should rely on system provided packages such as icu, and nss from the system rather than using vcpkg provided ports. I little bit more digging shows that the ports of nss and its dependency nspr are currently windows only and it looks from https://github.com/microsoft/vcpkg/pull/21281#issuecomment-964826255 that this is just because no one has done the work yet to enable them on other platforms.

I've also noticed that qt5-webengine is an experimental package: qt5-webengine/portfile.cmake:10.

I'm new to Vcpkg and I'm currently just evaluating it (vs Conan), but I will see if I can find time to fix the qt5-webengine port on Linux so it doesn't require system provided libraries and hereunder make the nss and nspr ports work on Linux too.

github-actions[bot] commented 2 months ago

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 180 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.