[qtwebengine] Build failure on x64-linux-dynamic #38497
Labels
category:community-triplet
A PR or issue related to community triplets not officially validated by the vcpkg team.
Stale
Comments
|
This is two errors in one, I think. It says "WARNING: QtWebEngine won't be built. Unmodified ffmpeg >= 5.0 is not supported." so it won't actually build QtWebEngine, but the thing that makes it fail is this bit: |
|
So the question is why does the libxml2 fail. The reason can probably be found in the yaml file in the subdir CMakeFiles of the buildtree |
|
There is no trace of libxml in vcpkg/buildtrees/qtwebengine/x64-linux-dynamic-dbg/CMakeFiles/CMakeConfigureLog.yaml: CMakeConfigureLog.yamlDoes that perhaps indicate that it doesn't even find libxml2 when it tries with pkg-config? The test in The test macro appears to be defined in https://github.com/qt/qtbase/blob/24859d7deaf995e992f0d9439a1c476126d5f654/cmake/QtFeature.cmake#L907 |
|
So how did you even get so far? I get errors due to nss being missing. |
|
nss and nspr in vcpkg.git strangely are not available on other platforms than Windows, so you have to use the distro version of these libraries. On RHEL I used |
Yeah no. Just build the dependencies in vcpkg itself. I am already at that point |
|
I cannot parse your response 🤷 |
|
I am building everything externally required within vcpkg itself. |
|
All the X11 dependencies too? Impressive! 💪 |
The x11 deps are already all in vcpkg. I could do that but that is not the aim currently. (see #27279 for that) |
|
If you get to the point it is building you get: |
But as no-ops outside windows. |
|
So figured out that the build is using node from the system behind my back which is why it failed. Setting LD_LIBRARY_PATH seems to kill the compiler just a bit later so trying rpath now somehow. |
|
hmm ok maybe I am just running out of ram for the build |
|
Hmm reached: probably a missing include |
|
Merged
|
https://github.com/Neumann-A/vcpkg/tree/fix_qtwebengine_linux_dyn |
|
I've cherry-picked the commit at fix_qtwebengine_linux_dyn from https://github.com/Neumann-A/vcpkg on top of master and I have tried building qtwebengine on AlmaLinux 9.4. First issue I run into is this, if I don't have the Is this expected? I made the following change which appears to fix it to use the vcpkg version of gyp: diff --git a/ports/nss/portfile.cmake b/ports/nss/portfile.cmake
index 0972e0758e..4a9562e438 100644
--- a/ports/nss/portfile.cmake
+++ b/ports/nss/portfile.cmake
@@ -79,7 +79,7 @@ set(GYP_NEXT_ROOT "${CURRENT_HOST_INSTALLED_DIR}/tools/gyp-next")
if (VCPKG_HOST_IS_WINDOWS)
find_file(GYP_NEXT NAMES gyp.bat PATHS "${GYP_NEXT_ROOT}" NO_DEFAULT_PATH REQUIRED)
else()
- find_program(GYP_NEXT NAMES gyp REQUIRED)
+ find_program(GYP_NEXT NAMES gyp PATHS "${GYP_NEXT_ROOT}" NO_DEFAULT_PATH REQUIRED)
endif()
vcpkg_add_to_path(PREPEND "${GYP_NEXT_ROOT}")
diff --git a/ports/nss/vcpkg.json b/ports/nss/vcpkg.json
index 35a9706a7e..62346a0e50 100644
--- a/ports/nss/vcpkg.json
+++ b/ports/nss/vcpkg.json
@@ -10,8 +10,7 @@
"sqlite3",
{
"name": "vcpkg-tool-gyp-next",
- "host": true,
- "platform": "windows"
+ "host": true
},
{
"name": "vcpkg-tool-mozbuild", |
|
Tools on linux should normally come from the system unless there is a reason not to do it. If it works using the vcpkg version great but i did not bother to test that approach. |
I'd normally prefer things to be the same across platforms (windows and linux) if there is no reason to make them different. |
|
@Neumann-A, you commit, Neumann-A@20a110d, does a lot:
I expect this is too busy to become a PR directly, or does vcpkg.git accept PRs that makes multiple changes like that? I expect cups is optional and qt5-webengine currently requires the OS provided version of nss and nspr on Linux (along with all the X11/XCB stuff). Would it make sense to make a pull-request that just makes the following changes:
I ask because I am not yet accustomed to making PRs against vcpkg.git and normally the projects that I work on like multiple smaller PRs that fix one problem each rather than one that does a lot of different stuff. EDIT: Hm, looks like cups is not optional. |
|
With the new package, On the other hand, if qtwebengine cannot be built without cups on Linux. cups should perhaps also be an official dependency for qtbase? |
I think those are two completely separate systems. The internal chromium build probably requires cups and not the external qt build. |
Technically the two systems for detection is indeed separate, but that is not my point. My point is that if there is a |
|
I going to fix the qtbase issues. However, cups needs some solution for all the absolute paths it has and nss/nspr a) need to be made available on linux and b) need to be refactored on windows. I am pretty sure mozbuild is completely useless and it can be ported to using only the msys from vcpkg without adding an additional dependency. |
|
@Neumann-A, with the qtbase fixes and using your fixed qtwebengine branch I get to this build error: The readelf on my system links a ton of libraries so it is sensitive to LD_LIBRARY_PATH. This must be a consequence of setting LD_LIBRARY_PATH here or here. Is it too risky to set LD_LIBRARY_PATH for the whole build - it seems likely to cause problems as a lot of tools link e.g. libz. |
Looks more like it is linking more stuff from your system instead of vcpkg. The setting of LD_LIBRARY_PATH is certainly not the problem here. |
When you say it with such conviction I almost back off, but your conclusion is incorrect. readelf is an executable run by the chromium build and unlike most other tools that is run during a build it has quite a lot of shared library dependencies. In my comment above I showed you the list of dynamic link libraries it depends on, when it is not affected by LD_LIBRARY_PATH. See below how they are affected by setting it: Very clearly it is picking up the vcpkg versions of libssl.so.3 which apparently is built without EVP_md2. |
|
Ah ok so the problem is that |
On RHEL/Fedora, at least, it is unusual for distribution provided executables in /usr/bin to have RPATH or RUNPATH set. And of course RUNPATH is searched after LD_LIBRARY_PATH, so setting it doesn't help. I don't know about other Linux distributions. |
|
If I drop the icu dependency then interestingly to avoid qtwebengine/src/3rdparty/chromium/v8/src/regexp/gen-regexp-special-case.cc depending on icu, I get the following error. I have no idea why: Further removing The qtwebengine port is a little strange. It has a ton of dependencies that are EDIT: After removing most of the ``! windows |
|
I think the dependencies must be added (devendored) on both systems... (if not the whole chromium). |
Upstream Qt and Chromium itself does not a provide a way to de-vendor (on windows). You can spend the time trying but be aware that the windows build creates a self contained |
|
And still it is double maintainance. Including security. |
|
Just dropping my comment here on building QtWebEngine: #32303 (comment) May be helpful in resolving some of the difficulties in building it! |
|
I just looked how I added PKG_CONFIG_PATH and LD_LIBRARY_PATH and I added it to the WebEngine CMake files instead of the portfile.. not sure anymore whether that makes any difference. But executing the system's "readelf" shouldn't load the vcpkg-build shared libraries, surely. Not sure whether that's also the case with my patch. |
I believe it will as you set LD_LIBRARY_PATH on the whole invocation of ninja: The readelf executable is executed from ninja so it will inherit LD_LIBRARY_PATH and it will be affected by it. Same as the compiler, linker and ton of other executables executed by ninja. |
|
@tsondergaard Have you opened an issue in the Qt Jira for the problem? |
I would vote to persue the rpath approach.. Looking through GN files I see a bunch of functionality to this end. |
|
We already know that the rpath approach is the one to solve the problem. We just don't know how to add it to the build. I already tried e.g. editing/appending to the args.gn file from cmake or setting LDFLAGS etc. but somehow the flags won't reach the |
So the plan is to add the rpath entry globally with an absolute path, and then in the portfile remove it for the installed libraries again? Because it sounds like you do not want to add the rpath to only the binaries that are used during the build only (maybe GN doesn't support that?). Is that what the "Adjusted RPATH of ..." output of the portfile is about? Sounds reasonable. Another approach could be to add the relevant LD_LIBRARY_PATH setting to run.py and gn_run_binary.py and hope that's the only place you need to touch. But I suspect it's more complicated than that.. most often it is. |
|
Have you looked at Yocto for inspiration? I've had a quick look.. It defines an own GN toolchain file here: https://github.com/OSSystems/meta-browser/blob/master/meta-chromium/recipes-browser/chromium/gn-utils.inc#L77 . Apparently you can specify a host toolchain ("native" in yocto parlance) different from the target toolchain . The BUILD_LDFLAGS used in that code is defined here: https://github.com/OSSystems/meta-browser/blob/master/meta-chromium/recipes-browser/chromium/chromium-gn.inc#L276 and you can tell GN about the host toolchain using the host_toolchain value. See https://github.com/OSSystems/meta-browser/blob/master/meta-chromium/recipes-browser/chromium/chromium-gn.inc#L284 . Specifying an entirely custom toolchain maybe is overkill for VCPKG. Maybe you can add the extra_ldflags value somehow from the GN command line. Or maybe you can inherit the default toolchain and only modify extra_ldflags...? Not sure whether this is helpful at all. If you are fluent with yocto, maybe you can figure things out from there. |
Tried this already did not work. |
|
created https://bugreports.qt.io/browse/QTBUG-125619 to have it solved by upstream |
|
@Neumann-A How did you manage to get past this error ? I tried to apply the patch from your fork ( |
|
Check the yaml file with the test Code it should tell you why it fails. |
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Package: qtwebengine[core,default-features]:x64-linux-dynamic@6.6.1#5
Host Environment
vcpkg-scripts version: c561d1e 2024-04-29 (15 hours ago)
To Reproduce
vcpkg installFailure logs
/home/ts/src/example/vcpkg/buildtrees/qtwebengine/config-x64-linux-dynamic-dbg-err.log
/home/ts/src/example/vcpkg/buildtrees/qtwebengine/config-x64-linux-dynamic-dbg-out.log
/home/ts/src/example/vcpkg/buildtrees/qtwebengine/config-x64-linux-dynamic-dbg-CMakeCache.txt.log
Additional context
vcpkg.json
The text was updated successfully, but these errors were encountered: