[Development] Making a vcpkg port of qtwebengine on Linux with dynamic linking

2024-05-20 Thread Thomas Sondergaard

Hi, I'm trying to fix the vcpkg version of qtwebengine so it works with dynamic linking on Linux, and I am almost ready to give up. I reach out to get some much needed help The problem that I run into during the 
build of qtwebengine is that during the qtwebengine build it also executes some of the executables that it has built. One example is the executable gen-regexp-special-case which links with the vcpkg port of 
libicuuc.so.74. This library cannot be found as no rpath has been set on the executables that have been written. The error looks like this [8173/41435] ACTION 
//v8:run_gen-regexp-special-case(/home/neumann/vcpkg/buildtrees/qtwebengine/x64-linux-dyn-rel-rel/src/core/target_toolchain:target) FAILED: gen/v8/src/regexp/special-case.cc 
/home/neumann/vcpkg/buildtrees/qtwebengine/x64-linux-dyn-rel-venv/bin/python ../../../../../src/here-src-6-88b84a07f4/src/3rdparty/chromium/v8/tools/run.py ./gen-regexp-special-case 
gen/v8/src/regexp/special-case.cc ./gen-regexp-special-case: error while loading shared libraries: libicuuc.so.74: cannot open shared object file: No such file or directory Return code is 127 If I set 
LD_LIBRARY_PATH to vcpkg_installed//lib where libicuuc.so.74 can be found when running the whole build it to address this problem, it makes me very uneasy because all the dynamically linked 
executables that are run during the build could pick up the version of libraries that I have in vcpkg_installed//lib . An of course this actually causes a problem in practice as the RHEL 9 version 
of /usr/bin/readelf depends on libdebuginfod.so.1 which depends on a ton of other things that are in my prefix. The problem that actually manifests is that my vcpkg packaged version of openssl doesn't have 
EVP_md2which causes the build wrapped in LD_LIBRARY_PATH to fail with this error: [2536/40167] SOLINK ./libvulkan.so.1 FAILED: libvulkan.so.1 libvulkan.so.1.TOC 
"/home/ts/src/vcpkg/buildtrees/qtwebengine/x64-linux-dynamic-venv/bin/python" "../../../../../src/ here-src-6-b81b710668.clean/src/3rdparty/chromium/build/toolchain/gcc_solink_wrapper.py " 
--readelf="readelf" --nm="/usr/bin/nm" --sofile="./libvulkan.so.1" --tocfile="./libvulkan.so.1.TOC" --output="./libvulkan.so.1" -- /usr/bin/c++ -shared 
-Wl,-soname="libvulkan.so.1" -Wl,--build-id -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -m64 -rdynamic -Wl,-z,defs -Wl,--as-needed -o "./libvulkan.so.1" @"./libvulkan.so.1.rsp" 
readelf: symbol lookup error: /lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0 [2537/40167] ACTION 
//extensions/common/api:generated_api_types_schema_generator(/home/ts/src/vcpkg/buildtrees/qtwebengine/x64-linux-dynamic-dbg/src/core/target_toolchain:target) [2538/40167] CC 
obj/third_party/webrtc/modules/audio_coding/isac_vad/filter_functions.o I currently have that fixed in my branch by adding a directory to the PATH with a readelf shim with this content: #!/bin/sh unset 
LD_LIBRARY_PATH exec /usr/bin/readelf.orig "$@" So I need something better than just setting LD_LIBRARY_PATH when running the qtwebengine build. I guess what I need to do is set a RUNPATH on 
gen-regexp-special-case and probably other tools that are built and executed during the build.I am not too familiar with GN and the Chromium build system. Is there anyone that can provide me with instructions 
for getting the proper RUNPATH arguments passed down to these build tools from the qtwebengine conflgure script? I need something a la "-Wl,-rpath,${CURRENT_INSTALLED_DIR}/lib" passed down there. 
Thanks, Thomas-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


[Development] Making a vcpkg port of qtwebengine on Linux with dynamic linking (2)

2024-05-20 Thread Thomas Sondergaard

Hi, I'm resending this as the first mail I sent came out as a single line in https://lists.qt-project.org/pipermail/development/2024-May/045311.html . Hopefully it comes out better this time, although icloud.com 
gives me limited control over the format it sends in. I'm trying to fix the vcpkg version of qtwebengine so it works with dynamic linking on Linux, and I am almost ready to give up. I reach out to get some much 
needed help The problem that I run into during the build of qtwebengine is that during the qtwebengine build it also executes some of the executables that it has built. One example is the executable 
gen-regexp-special-case which links with the vcpkg port of libicuuc.so.74. This library cannot be found as no rpath has been set on the executables that have been written. The error looks like this [8173/41435] 
ACTION //v8:run_gen-regexp-special-case(/home/neumann/vcpkg/buildtrees/qtwebengine/x64-linux-dyn-rel-rel/src/core/target_toolchain:target) FAILED: gen/v8/src/regexp/special-case.cc 
/home/neumann/vcpkg/buildtrees/qtwebengine/x64-linux-dyn-rel-venv/bin/python ../../../../../src/here-src-6-88b84a07f4/src/3rdparty/chromium/v8/tools/run.py ./gen-regexp-special-case 
gen/v8/src/regexp/special-case.cc ./gen-regexp-special-case: error while loading shared libraries: libicuuc.so.74: cannot open shared object file: No such file or directory Return code is 127 If I set 
LD_LIBRARY_PATH to vcpkg_installed//lib where libicuuc.so.74 can be found when running the whole build it to address this problem, it makes me very uneasy because all the dynamically linked 
executables that are run during the build could pick up the version of libraries that I have in vcpkg_installed//lib . An of course this actually causes a problem in practice as the RHEL 9 version 
of /usr/bin/readelf depends on libdebuginfod.so.1 which depends on a ton of other things that are in my prefix. The problem that actually manifests is that my vcpkg packaged version of openssl doesn't have 
EVP_md2which causes the build wrapped in LD_LIBRARY_PATH to fail with this error: [2536/40167] SOLINK ./libvulkan.so.1 FAILED: libvulkan.so.1 libvulkan.so.1.TOC 
"/home/ts/src/vcpkg/buildtrees/qtwebengine/x64-linux-dynamic-venv/bin/python" "../../../../../src/ here-src-6-b81b710668.clean/src/3rdparty/chromium/build/toolchain/gcc_solink_wrapper.py " 
--readelf="readelf" --nm="/usr/bin/nm" --sofile="./libvulkan.so.1" --tocfile="./libvulkan.so.1.TOC" --output="./libvulkan.so.1" -- /usr/bin/c++ -shared 
-Wl,-soname="libvulkan.so.1" -Wl,--build-id -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -m64 -rdynamic -Wl,-z,defs -Wl,--as-needed -o "./libvulkan.so.1" @"./libvulkan.so.1.rsp" 
readelf: symbol lookup error: /lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0 [2537/40167] ACTION 
//extensions/common/api:generated_api_types_schema_generator(/home/ts/src/vcpkg/buildtrees/qtwebengine/x64-linux-dynamic-dbg/src/core/target_toolchain:target) [2538/40167] CC 
obj/third_party/webrtc/modules/audio_coding/isac_vad/filter_functions.o I currently have that fixed in my branch by adding a directory to the PATH with a readelf shim with this content: #!/bin/sh unset 
LD_LIBRARY_PATH exec /usr/bin/readelf.orig "$@" So I need something better than just setting LD_LIBRARY_PATH when running the qtwebengine build. I guess what I need to do is set a RUNPATH on 
gen-regexp-special-case and probably other tools that are built and executed during the build.I am not too familiar with GN and the Chromium build system. Is there anyone that can provide me with instructions 
for getting the proper RUNPATH arguments passed down to these build tools from the qtwebengine conflgure script? I need something a la "-Wl,-rpath,${CURRENT_INSTALLED_DIR}/lib" passed down there. 
Thanks, Thomas-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] Making a vcpkg port of qtwebengine on Linux with dynamic linking (2)

2024-05-21 Thread Thomas Sondergaard

I forgot, this is the github issue where I have documented the challenges: 
https://github.com/microsoft/vcpkg/issues/38497 Best, Thomas-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


Re: [Development] ActiveQt AxServer with CMake

2014-02-13 Thread Thomas Sondergaard
On 2014-02-13 13:47, Fricot, Daniel wrote:
> Rob,
> Your cmake snippet is basically what I do in my build.
> Idc is the problem. This gives the " Timers can only be used with
> threads started with QThread" error.
> After some more playing around, I noticed something. If I place a
> breakpoint in the beginning of my main, I got the following stacktrace
> (build with cmake, without IDL commands):
>  0main main.cpp44 0x81ea7
>  1__tmainCRTStartupcrtexe.c5360xafad9
>  2mainCRTStartup   crtexe.c3770xafc1d
>  3BaseThreadInitThunk  kernel32   0x76f8336a
>  4__RtlUserThreadStart ntdll  0x77979f72
>  5_RtlUserThreadStart  ntdll  0x77979f45
> If I do the same with something I build with qmake (which does the IDL
> commands for you), I got:
>  0main main.cpp   2520x1002ad6
> *1WinMain  qaxservermain.cpp  2600x101bdb1*
>  2__tmainCRTStartupcrtexe.c   5280x102fb62
>  3WinMainCRTStartupcrtexe.c   3770x102f92d
>  4BaseThreadInitThunk  kernel32  0x76f8336a
>  5__RtlUserThreadStart ntdll 0x77979f72
>  6_RtlUserThreadStart  ntdll 0x77979f45
> (Note that the main.cpp in the two stacktraces are two different files,
> so don’t mind the difference in line numbers in main.cpp)
> As you can see, in the activeqt server, build with qmake, the main is
> called from WinMain in qaxservermain.cpp. I don’t know if this is the
> result of the IDL commands (in which case, the cmake build obviously
> does not have the WinMain in the stacktrace) or this should also be in
> the stacktrace of the cmake build, even before running the IDL commands?
> Thanks,
> Daniel


It looks like you are building a .exe. Do you have WIN32 in your 
add_executable statement? qaxservermain.cpp (in the Qt 4.8 source I have 
lying around) provides a WinMain() that will call ::main().

Regards,
Thomas


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Disabling exception support in QtCore?

2013-10-01 Thread Thomas Sondergaard
On 2013-10-01 21:20, Thiago Macieira wrote:
> Since we decided to roll back support for exceptions in our container classes,
> the only thing that currently needs exception support is the mainloop allowing
> std::bad_alloc through.
>
> Is it worth it?
>
> Should we disable exceptions in QtCore?
>

As an outside voice, I'd like to point out that the rest of the world is 
using exceptions and removing whatever exception support there is in 
QtCore seems like a step in the wrong direction.

Regards,
Thomas



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development