Alexander Neumann

Hmm reached: ``` [22585/41446] CXX obj/ui/gl/gl/gl_display.o FAILED: obj/ui/gl/gl/gl_display.o /usr/bin/c++ -MMD -MF obj/ui/gl/gl/gl_display.o.d -DGL_IMPLEMENTATION -DUSE_UDEV -DUSE_AURA=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DUSE_GLX -DUSE_EGL -DSK_ENABLE_SKSL...

``` [41275/41446] CXX obj/QtWebEngineCore/autofill_client_qt.o FAILED: obj/QtWebEngineCore/autofill_client_qt.o /usr/bin/c++ -MMD -MF obj/QtWebEngineCore/autofill_client_qt.o.d -DCHROMIUM_VERSION=118.0.5993.220 -DUSE_UDEV -DUSE_AURA=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD -DTOOLKIT_QT -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DQT_NO_KEYWORDS -DQT_USE_QSTRINGBUILDER -DQTWEBENGINECORE_VERSION_STR=6.7.0 -DQTWEBENGINEPROCESS_NAME=QtWebEngineProcess -DBUILDING_CHROMIUM...

https://github.com/Neumann-A/vcpkg/tree/fix_qtwebengine_linux_dyn builds qtwebeninge just without libevent since this is not getting the correct includes into the build. ``` Installing 1/1 qtwebengine[core,default-features]:[email protected]... Building qtwebengine[core,default-features]:[email protected]... /home/neumann/vcpkg/triplets/community/x64-linux-dyn-rel.cmake: info: loaded community triplet from here....

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...

> 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...

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...

> This must be a consequence of setting LD_LIBRARY_PATH [here](https://github.com/Neumann-A/vcpkg/commit/20a110dcaebe797799d1b9cdcd6b5db42948d553#diff-6e5ddc0efbab6def6b64e4abe4818e162f38e55207f9ca8f91f6c207b20137aeR56) or [here](https://github.com/Neumann-A/vcpkg/commit/20a110dcaebe797799d1b9cdcd6b5db42948d553#diff-f30195c1a428cdb75ea43ba78b1741037cfb1dc81fc9dcfffd38b199ea23971aR114). Is it too risky to set LD_LIBRARY_PATH for the whole build - it seems likely to cause problems...

Ah ok so the problem is that `readelf` wasn't build with proper `rpath` flags (also I did not see such problems in the build). So the only option then is...

So this is my analysis: ``` # Required fails due to broken openblas:x64-android=fail # broken! ######### Why is this broken but arm64-android works ? lapack-reference:arm-neon-android=fail # broken! clapack:x64-android=skip lapack-reference:x64-android=fail #...

Furthermore: If Android uses GCC then the Fortran flags for Android are probably not being setup by the Android toolchain? So switching to clapack could solve that issue maybe.