[qt5-declarative] Build error with arm64 on macOS crosscompiled on x64 since #26354

[daschuer]

Host Environment

• OS: macOS

To Reproduce

Steps to reproduce the behavior:

./vcpkg install qt5-declarative:arm64-osx

Running on a x64 hardware

Failure logs

CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:131 (message):
    Command failed: /usr/bin/make -j 4
    Working Directory: /Users/runner/mixxx-vcpkg/buildtrees/qt5-declarative/arm64-osx-min1100-dbg
    See logs for more information:
      /Users/runner/mixxx-vcpkg/buildtrees/qt5-declarative/package-build-arm64-osx-min1100-dbg-out.log
      /Users/runner/mixxx-vcpkg/buildtrees/qt5-declarative/package-build-arm64-osx-min1100-dbg-err.log

Additional context

This is the failing Run on GitHub:

• https://github.com/daschuer/vcpkg/actions/runs/3868940153

Her it works again after reverting #26354:

• https://github.com/daschuer/vcpkg/actions/runs/3873496046

The issue is that the build flags are applied twice. During the build of qt5-base the flags are collected in qtconf: -qtconf /Users/runner/mixxx-vcpkg/buildtrees/qt5-declarative/arm64-osx-min1100-dbg/qt.conf

But due to the change in configure_qt.cmake they are applied again in collision with the original Qt flags. Wen calling https://github.com/daschuer/vcpkg/blob/arm64-osx-min1100-qt5.15.7/ports/qt5-base/cmake/qt_build_submodule.cmake#L12

[daschuer]

Unfortunately the logs are too long to attache. You find them in the workflow links above. Her only the relevant lines:

cd src/ && ( test -e Makefile || /Users/runner/mixxx-vcpkg/installed/x64-osx-min1012/tools/qt5/bin/qmake -o Makefile /Users/runner/mixxx-vcpkg/buildtrees/qt5-declarative/src/5.12.5-197f948223.clean/src/src.pro CONFIG-=release CONFIG+=debug QMAKE_CC=cc QMAKE_CXX=c++ QMAKE_AR=ar QMAKE_RANLIB=ranlib QMAKE_STRIP=strip QMAKE_NM=nm QMAKE_RC= QMAKE_MT= QMAKE_AR+=qc QMAKE_LINK=c++ QMAKE_LINK_SHLIB=c++ QMAKE_LINK_C=cc QMAKE_LINK_C_SHLIB=cc 'QMAKE_CFLAGS_DEBUG+=-fPIC -mmacosx-version-min=11.0 -arch arm64 -isysroot /Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -mmacosx-version-min=11.0 -g' 'QMAKE_CXXFLAGS_DEBUG+=-fPIC -mmacosx-version-min=11.0 -arch arm64 -isysroot /Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -mmacosx-version-min=11.0 -g' 'QMAKE_LFLAGS+=-arch arm64 -isysroot /Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -mmacosx-version-min=11.0' 'QMAKE_LFLAGS_SHLIB+=-arch arm64 -isysroot /Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -mmacosx-version-min=11.0' 'QMAKE_LFLAGS_PLUGIN+=-arch arm64 -isysroot /Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -mmacosx-version-min=11.0' CONFIG-=shared 'CONFIG*=static' -qtconf /Users/runner/mixxx-vcpkg/buildtrees/qt5-declarative/arm64-osx-min1100-dbg/qt.conf ) && /Applications/Xcode_12.4.app/Contents/Developer/usr/bin/make -f Makefile 

c++ -stdlib=libc++ -arch arm64 -isysroot /Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -mmacosx-version-min=11.0 -headerpad_max_install_names  -arch x86_64 -Wl,-syslibroot,/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -mmacosx-version-min=10.12 -Wl,-dead_strip -Wl,-rpath,@executable_path/../Frameworks -o ../../bin/qmlcachegen .obj/qmlcachegen.o .obj/resourcefilter.o .obj/generateloader.o .obj/resourcefilemapper.o   /Users/runner/mixxx-vcpkg/buildtrees/qt5-declarative/arm64-osx-min1100-dbg/lib/libQt5QmlDevTools.a /Users/runner/mixxx-vcpkg/installed/x64-osx-min1012/tools/qt5/lib/libQt5Bootstrap.a -framework Foundation -framework CoreServices   

make[1]: *** [sub-qmlmin-make_first] Error 2
ld: warning: ignoring file .obj/main.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file /Users/runner/mixxx-vcpkg/buildtrees/qt5-declarative/arm64-osx-min1100-dbg/lib/libQt5QmlDevTools.a, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file /Users/runner/mixxx-vcpkg/installed/x64-osx-min1012/tools/qt5/lib/libQt5Bootstrap.a, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: entry point (_main) undefined. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [../../bin/qmlimportscanner] Error 1
make[1]: *** [sub-qmlimportscanner-make_first] Error 2
ld: warning: ignoring file .obj/qmlcachegen.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file .obj/resourcefilter.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file .obj/generateloader.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file .obj/resourcefilemapper.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
ld: warning: ignoring file /Users/runner/mixxx-vcpkg/buildtrees/qt5-declarative/arm64-osx-min1100-dbg/lib/libQt5QmlDevTools.a, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: warning: ignoring file /Users/runner/mixxx-vcpkg/installed/x64-osx-min1012/tools/qt5/lib/libQt5Bootstrap.a, building for macOS-arm64 but attempting to link with file built for macOS-x86_64
ld: entry point (_main) undefined. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [../../bin/qmlcachegen] Error 1
make[1]: *** [sub-qmlcachegen-make_first] Error 2
make: *** [sub-tools-make_first] Error 2

[daschuer]

You see concurrent -arch arm64 and -arch x86_64 in the linker code which cause the failure.

[daschuer]

My workaround is to use the a custom configure_qt from qt_build_submodule that doe not add any additional flags except qt.conf. https://github.com/daschuer/vcpkg/commit/7cbfaed7e1b7d3a12aaa2122e4148387f37b1b2e

Could this be an upstream solution?

[Neumann-A]

So stupid question: where does -arch x86_64 come from ? Is x64-osx your host triplet? If yes i assume the wrong qt.conf is used? Screw that https://github.com/microsoft/vcpkg/blob/5bb5f3923a33d862b25c18fd4514e08c74c698e1/scripts/cmake/vcpkg_configure_qmake.cmake#L85 uses INSTALLED not HOST_INSTALLED

[Neumann-A]

Also are you sure that your qt5-base build is build for the correct architecture? It might be because we apply the flags now but I think that the qt.conf generated for arm64-osx does not know about that. which means qt itself does not know about it.

[autoantwort]

Also are you sure that your qt5-base build is build for the correct architecture?

I mean there is a post build check that verifies that.

[daschuer]

This is my target triplet: https://github.com/daschuer/vcpkg/blob/arm64-osx-min1100-qt5.15.7/overlay/triplets/arm64-osx-min1100.cmake

This is my host triplet: https://github.com/daschuer/vcpkg/blob/arm64-osx-min1100-qt5.15.7/overlay/triplets/x64-osx-min1012.cmake

The it uses the qt.conf from the target triplet: `/Users/runner/mixxx-vcpkg/buildtrees/qt5-declarative/arm64-osx-min1100-dbg/qt.conf``

The arch setting is comming from here: https://github.com/microsoft/vcpkg/blob/master/ports/qt5-base/portfile.cmake#L278 and form vcpkg_configure_qmake.cmake via QMAKE_LFLAGS

qmlcachegen is a build tool, which requires the host triplet. This was working before the blamed patch

It receives the wrong flags form: 'QMAKE_LFLAGS+=-arch arm64 -isysroot /Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -mmacosx-version-min=11.0'

And uses in addition the concurrent fags correctly configured via qt5-base: -arch x86_64 -Wl,-syslibroot,/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -mmacosx-version-min=10.12

The issue is only one in case of cross compile, but even in the native case the fags are applied twice, which should not happen.

All Qt modules needs the same set of flags. This is realized by collecting them for qt5-base and reuses them for the submodules. If we apply additional flags to submodules it brakes that trick

Conclusion: We must only apply the flags from cmake once, during configuring qt5-base. Submodules can rely on qt.conf. Implemented in https://github.com/daschuer/vcpkg/commit/7cbfaed7e1b7d3a12aaa2122e4148387f37b1b2e

[Neumann-A]

in the native case the fags are applied twice, which should not happen.

That is a consistency check. QMAKE_LFLAGS come from the toolchain while qt.conf comes from the qt5-base build itself using the toolchain flags. From what you tell me: You target arm64 and the host is x64 -> so the x64 flags are wrong. This is a bit strange since the qt.conf for the target (CURRENT_INSTALL_DIR) should be passed to qmake.

Submodules can rely on qt.conf.

From your description the qt.conf is the one bringing the wrong x64 flags since your target is arm64. vcpkg should only ever build for the specified target triplet. The host is pulled in via a host dependency with the host target triplet.

It could very well be that qt5 requires more work to correctly reflect vcpkgs host/target style.

[daschuer]

You target arm64 and the host is x64 -> so the x64 flags are wrong.

No, x64 is correct in this case, because in that particular call, we link a build tool that requires host architecture.

It could very well be that qt5 requires more work to correctly reflect vcpkgs host/target style.

Yes, from that point of view we need to split qt5-declarative into qt5-declarative and qt5-declarative-tools. The following tools are effected:

• qmllint
• qmlmin
• qmlimportscanner
• qmlcachegen

But that fixes only a symptom of the root cause. Even if this is fixed we still have duplicated flags in the command line. This is clearly introduced by the blamed PR and need to be fixed as well. If you like my proposal for it, I will issue a PR Do you?

[Neumann-A]

Yes, from that point of view we need to split

No need to split (see qt6). Just declare a host dependency on itself. That being said I never actually designed qt5 to be cross buildable and the fact that it worked was just by coincidence and not design.

Even if this is fixed we still have duplicated flags in the command line.

That did not create the error. As I said it is a consistency check and the flags should be equal. If at all the flags in the qt.conf needs to be removed since they are related to the toolchain used for qt5-base instead for qt5-declartive (which would still leave you with the wrong flags for your use case).

[daschuer]

That did not create the error.

At least removing the double flag generation makes the port working again. That solves the error that beaks the port.

The case that the port builds host tools is orthogonal. There are by the way a few other ports building host tools.

As I said it is a consistency check and the flags should be equal.

I strongly disagree. I have never heard of a practice to apply command line flags twice as a consistency check. Normally the last flag wins there is no checking facility in the compiler. But we should pass the flags correctly in the first attempt and not rely on this compiler nature.

In addition each port should be able to apply it's own special case handling regarding flags. In case of Qt this is done only once in the qt5-base ports. The other ports are re-using this. Applying the flags again blindly in the submodules without the sanity checks breaks this concept.

[daschuer]

Aside from this discussion, what are your plans to make qt5-declatative build again?

[Neumann-A]

Aside from this discussion, what are your plans to make qt5-declatative build again?

I don't do cross builds and such issues need to be resolved by a person doing cross builds. Most of the qt5 stuff was designed before --host-triplet existed and was never meant for cross builds. I mean I can remove the flags from qt.conf but that probably won't help your case.

There are by the way a few other ports building host tools.

it is against vcpkg policy to do so. You need to declare a host dependency and pull in host tools in that way.

... apply it's own special case handling regarding flags .... .... Normally the last flag wins....

That is how it should be designed.

But we should pass the flags correctly in the first attempt and not rely on this compiler nature.

Unfortunately, that is not always possible.

[daschuer]

I mean I can remove the flags from qt.conf but that probably won't help your case.

That will not work, because in qt5-base uses the qt.conf as well which it is properly configured from the flags discovered from CMake. It does not use vcpkg_configure_qmake.cmake(). Please explain why you propose to alter the established way how Qt is build, instead of removing one set of the recently introduced flags and carry on?

That is how it should be designed.

OK, but instead of design it the desired way, https://github.com/microsoft/vcpkg/pull/26354 applied the flags twice. This is also an issue in non crosscompile builds using the x64-windows standard triplet like here for windows:

Before https://github.com/microsoft/vcpkg/pull/26354:

    cl 
    -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD 
    -std:c++17 -utf-8 /wd4530 /wd4577 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DQT_NO_LINKED_LIST -DQT_NO_LINKED_LIST -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_USE_QSTRINGBUILDER -DNDEBUG -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG -DQT_QMLDEVTOOLS_LIB -DQT_CORE_LIB -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\tools\qmllint -I. -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include\QtQml -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include\QtQml\5.15.7 -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include\QtQml\5.15.7\QtQml -I..\..\include -I..\..\include\QtQml -I..\..\include\QtQml\5.15.7 -I..\..\include\QtQml\5.15.7\QtQml -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5\QtCore\5.15.7 -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5\QtCore\5.15.7\QtCore -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5 -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5\QtCore -I.moc\release -IC:\mixxx-vcpkg\installed\x64-windows\include -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5 -IC:\mixxx-vcpkg\installed\x64-windows\tools\qt5\mkspecs\win32-msvc -Fo.obj\release\ @C:\Users\RUNNER~1\AppData\Local\Temp\main.obj.6780.15.jom
main.cpp

After https://github.com/microsoft/vcpkg/pull/26354:

    cl.exe 
    -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD 
    -nologo -DWIN32 -D_WINDOWS -W3 -utf-8 -GR -EHsc -MP -MD -O2 -Oi -Gy -DNDEBUG -Z7 
    -nologo -DWIN32 -D_WINDOWS -W3 -utf-8 -GR -EHsc -MP -MD -O2 -Oi -Gy -DNDEBUG -Z7 
    -std:c++17 -utf-8 /wd4530 /wd4577 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DQT_NO_LINKED_LIST -DQT_NO_LINKED_LIST -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_USE_QSTRINGBUILDER -DNDEBUG -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG -DQT_QMLDEVTOOLS_LIB -DQT_CORE_LIB -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\tools\qmllint -I. -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include\QtQml -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include\QtQml\5.15.7 -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include\QtQml\5.15.7\QtQml -I..\..\include -I..\..\include\QtQml -I..\..\include\QtQml\5.15.7 -I..\..\include\QtQml\5.15.7\QtQml -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5\QtCore\5.15.7 -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5\QtCore\5.15.7\QtCore -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5 -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5\QtCore -I.moc\release -IC:\mixxx-vcpkg\installed\x64-windows\include -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5 -IC:\mixxx-vcpkg\installed\x64-windows\tools\qt5\mkspecs\win32-msvc -Fo.obj\release\ @C:\Users\RUNNER~1\AppData\Local\Temp\main.obj.2604.16.jom
main.cpp

With the proposed patch https://github.com/daschuer/vcpkg/commit/6b45c7681fec2af36669653f3474c6c31cda968f applied:

    cl.exe 
    -c -nologo -Zc:wchar_t -FS -Zc:rvalueCast -Zc:inline -Zc:strictStrings -Zc:throwingNew -Zc:referenceBinding -Zc:__cplusplus -O2 -MD 
    -nologo -DWIN32 -D_WINDOWS -W3 -utf-8 -GR -EHsc -MP -MD -O2 -Oi -Gy -DNDEBUG -Z7 
    -std:c++17 -utf-8 /wd4530 /wd4577 -W3 -w34100 -w34189 -w44996 -w44456 -w44457 -w44458 -wd4577 -wd4467 -DUNICODE -D_UNICODE -DWIN32 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -DWIN64 -DQT_NO_LINKED_LIST -DQT_NO_LINKED_LIST -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_USE_QSTRINGBUILDER -DNDEBUG -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG -DQT_QMLDEVTOOLS_LIB -DQT_CORE_LIB -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\tools\qmllint -I. -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include\QtQml -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include\QtQml\5.15.7 -IC:\mixxx-vcpkg\buildtrees\qt5-declarative\src\5.15.7-7f3698f29e.clean\include\QtQml\5.15.7\QtQml -I..\..\include -I..\..\include\QtQml -I..\..\include\QtQml\5.15.7 -I..\..\include\QtQml\5.15.7\QtQml -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5\QtCore\5.15.7 -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5\QtCore\5.15.7\QtCore -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5 -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5\QtCore -I.moc\release -IC:\mixxx-vcpkg\installed\x64-windows\include -IC:\mixxx-vcpkg\installed\x64-windows\include\qt5 -IC:\mixxx-vcpkg\installed\x64-windows\tools\qt5\mkspecs\win32-msvc -Fo.obj\release\ @C:\Users\RUNNER~1\AppData\Local\Temp\main.obj.6856.16.jom
main.cpp

[Neumann-A]

With the proposed patch https://github.com/daschuer/vcpkg/commit/6b45c7681fec2af36669653f3474c6c31cda968f applied:

these flags are coming from the toolchain set for qt5-base instead of the toolchain for the port. Also you should always use vcpkg_configure_qmake instead of supplying another function doing the same as vcpkg_configure_qmake.

I looked at how qt5-base tries to support cross builds. It is definitely not correctly designed for that. So that would require fixing first.

[Neumann-A]

seems like the flags come from qmodule.pri (<installed>\tools\qt5\mkspecs)

!host_build|!cross_compile {
    QMAKE_LIBS_PRIVATE+=$$[QT_INSTALL_LIBS]/bz2.lib
    QMAKE_LIBS_PRIVATE+=$$[QT_INSTALL_LIBS]/libpng16.lib
    QMAKE_LIBS_PRIVATE+=$$[QT_INSTALL_LIBS]/icuin.lib $$[QT_INSTALL_LIBS]/icutu.lib  $$[QT_INSTALL_LIBS]/icuuc.lib $$[QT_INSTALL_LIBS]/icuio.lib $$[QT_INSTALL_LIBS]/icudt.lib Advapi32.lib
    QMAKE_LIBS_PRIVATE+=$$[QT_INSTALL_LIBS]/zstd.lib
    QMAKE_CC=cl.exe
    QMAKE_CXX=cl.exe
    QMAKE_AR=lib.exe
    QMAKE_RANLIB=:
    QMAKE_STRIP=
    QMAKE_NM=
    QMAKE_RC=rc.exe
    QMAKE_MT=mt.exe
    QMAKE_LIB=lib.exe
    QMAKE_LINK=link.exe
    QMAKE_LIBS+=kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
    QMAKE_RC+=-c65001 -DWIN32
    QMAKE_CFLAGS_RELEASE+=-nologo -DWIN32 -D_WINDOWS -W3 -utf-8 -MP  -MD -O2 -Oi -Gy -DNDEBUG -Z7
    QMAKE_CXXFLAGS_RELEASE+=-nologo -DWIN32 -D_WINDOWS -W3 -utf-8 -GR -EHsc -MP  -MD -O2 -Oi -Gy -DNDEBUG -Z7
    QMAKE_LFLAGS+=-machine:x64 -nologo -DEBUG -INCREMENTAL:NO -OPT:REF -OPT:ICF
    QMAKE_LFLAGS_SHLIB+=-machine:x64 -nologo -DEBUG -INCREMENTAL:NO -OPT:REF -OPT:ICF
    QMAKE_LFLAGS_PLUGIN+=-machine:x64 -INCREMENTAL:NO
    QMAKE_LIBFLAGS_RELEASE+=-machine:x64 -nologo
}

[daschuer]

I looked at how qt5-base tries to support cross builds. It is definitely not correctly designed for that. So that would require fixing first.

Since that is not broken for me, I have no interest to fix it. I expect that this is a quite hard task, because it is against the original design of the Qt build system.

these flags are coming from the toolchain set for qt5-base instead of the toolchain for the port.

Yes.

Also you should always use vcpkg_configure_qmake instead of supplying another function doing the same as vcpkg_configure_qmake.

Ok, would than a solution acceptable that adds another parameter to vcpkg_configure_qmake, to disable adding the CMake flags?

[kafeg]

It started failing after https://github.com/microsoft/vcpkg/commit/d8e60ef4741584f2957788ed0786dd365c92c4d9

[dg0yt]

Qt5 in vcpkg isn't really supporting cross builds. The key problem is using host (triplet) tools with target mkspecs. It may have been somewhat hidden for osx, but it it is obvious when trying to build for mingw on linux.

[daschuer]

For me it is kind of mood to discuss whether Qt5 supports cross compiling with vcpkg, because there is clearly a demand AND it was working. From that point of view we have a regression here and you are holding back a feature that is clearly supported by the Qt authors for some principles. But anyway in case of Mixxx we have all working as an overlay: https://github.com/mixxxdj/vcpkg/tree/2.4/overlay/osx

[dg0yt]

Nice that it works for your with osx/mixxx glasses on. But this is no the kind of feedback that motivates me to move forward the WIP work which I already have.

[daschuer]

Oh sorry, I did not knew there is work in progress. Than go ahead and keep us informed. I am happy do help testing that we quickly get around the broken state.

[github-actions[bot]]

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.