Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
tsondergaard opened this issue Feb 19, 2024 · 3 comments
Closed
Labels
category:community-triplet A PR or issue related to community triplets not officially validated by the vcpkg team. Stale

Comments

@tsondergaard
Copy link
Contributor

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

  • OS: AlmaLinux 9.3 (RHEL 9.3)
  • Compiler: gcc 11.4.1

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.

@JonLiu1993 JonLiu1993 removed their assignment Feb 20, 2024
@JonLiu1993 JonLiu1993 added the category:community-triplet A PR or issue related to community triplets not officially validated by the vcpkg team. label Feb 20, 2024
@SchaichAlonso
Copy link
Contributor

SchaichAlonso commented Feb 21, 2024

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
Copy link
Contributor Author

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 bb7ccc4 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 #21281 (comment) 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.

Copy link

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.

@github-actions github-actions bot added the Stale label Aug 21, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:community-triplet A PR or issue related to community triplets not officially validated by the vcpkg team. Stale
Projects
None yet
Development

No branches or pull requests

3 participants