IT박스

Linux에서 Windows 대상으로의 교차 컴파일을 위해 Qt를 구성하려면 어떻게해야합니까?

itboxs 2020. 10. 15. 07:37
반응형

Linux에서 Windows 대상으로의 교차 컴파일을 위해 Qt를 구성하려면 어떻게해야합니까?


Linux x86_64 호스트 머신을 사용하여 Windows x86_64 대상에 대한 Qt 라이브러리 (그리고 결국 내 애플리케이션)를 교차 컴파일하고 싶습니다. 친한 것 같지만이 과정의 일부에 대해 근본적인 오해가있을 수 있습니다.

내 Fedora 컴퓨터에 모든 mingw 패키지를 설치 한 다음 win32-g++내 환경에 맞게 qmake.conf 파일을 수정하여 시작했습니다. 그러나, 나는 Qt를위한 몇 가지 겉으로는 명백한 구성 옵션으로 붙어 받고있는 것으로 보인다 : -platform-xplatform. Qt 문서에 따르면 이것이 -platform호스트 머신 아키텍처 (컴파일하는 곳) -xplatform여야하며 배포하려는 대상 플랫폼이어야합니다. 제 경우에는 설정 -platform linux-g++-64하고 -xplatform linux-win32-g++linux-win32-g ++는 수정 된 win32-g ++ 구성입니다.

내 문제는 이러한 옵션으로 configure를 실행 한 후 크로스 컴파일러 (x86_64-w64-mingw32-gcc) 대신 내 시스템의 컴파일러를 호출한다는 것입니다. -xplatform옵션을 생략하고 -platform대상 사양 (linux-win32-g ++)으로 설정하면 크로스 컴파일러를 호출하지만 일부 유닉스 관련 함수가 정의되지 않은 경우 오류가 발생합니다.

다음은 최근 시도의 결과입니다. http://pastebin.com/QCpKSNev .

질문 :

  1. 리눅스 호스트에서 Windows 용 Qt는 뭔가를 크로스 컴파일 할 때, 네이티브 컴파일러한다 이제까지 호출? 즉, 크로스 컴파일 과정 에서 크로스 컴파일러 사용해야하지 않습니까? -xplatform옵션을 지정할 때 Qt의 구성 스크립트가 시스템의 네이티브 컴파일러를 호출하는 이유를 알 수 없습니다 .

  2. mingw 크로스 컴파일러를 사용하는 경우 언제 사양 파일을 처리해야합니까? GCC에 대한 사양 파일은 여전히 ​​나에게 일종의 미스터리이므로 여기에 배경이 도움이 될지 궁금합니다.

  3. 일반적으로 내 qmake.conf에서 크로스 컴파일러를 지정하는 것 외에 고려해야 할 사항은 무엇입니까?


그냥 사용 M 교차 환경 (MXE을) . 전체 프로세스에서 고통을 덜어줍니다.

  • 그것을 얻으십시오 :

    $ git clone https://github.com/mxe/mxe.git
    
  • 빌드 종속성 설치

  • Windows 용 Qt, 종속성 및 교차 빌드 도구를 빌드합니다. 이것은 괜찮은 인터넷 접속이 가능한 빠른 기계에서 약 1 시간이 걸릴 것입니다; 다운로드 용량은 약 500MB입니다.

    $ cd mxe && make qt
    
  • 앱의 디렉터리로 이동하여 교차 빌드 도구를 PATH 환경 변수에 추가합니다.

    $ export PATH=<mxe root>/usr/bin:$PATH
    
  • Qt Makefile 생성기 도구를 실행 한 다음 빌드합니다.

    $ <mxe root>/usr/i686-pc-mingw32/qt/bin/qmake && make
    
  • ./release 디렉토리에서 바이너리를 찾아야합니다.

    $ wine release/foo.exe
    

몇 가지 참고 사항 :

  • MXE 저장소의 마스터 브랜치를 사용하십시오. 개발팀으로부터 더 많은 사랑을받는 것 같습니다.

  • 출력은 64 비트 Windows에서 잘 작동하는 32 비트 정적 바이너리입니다.


(이것은 MXE가 답변 이후 진화 했으므로 @Tshepang의 답변 업데이트입니다)

Qt 구축

make qtQt를 빌드하는 데 사용 하는 대신을 사용 MXE_TARGETS하여 대상 머신 및 도구 체인 (32 비트 또는 64 비트)을 제어 할 수 있습니다 . MXE는 빌드하려는 lib 유형을 표시하기 위해 .static.shared대상 이름의 일부로 사용하기 시작했습니다 .

# The following is the same as `make qt`, see explanation on default settings after the code block.
make qt MXE_TARGETS=i686-w64-mingw32.static   # MinGW-w64, 32-bit, static libs

# Other targets you can use:
make qt MXE_TARGETS=x86_64-w64-mingw32.static # MinGW-w64, 64-bit, static libs
make qt MXE_TARGETS=i686-w64-mingw32.shared   # MinGW-w64, 32-bit, shared libs

# You can even specify two targets, and they are built in one run:
# (And that's why it is MXE_TARGET**S**, not MXE_TARGET ;)
# MinGW-w64, both 32- and 64-bit, static libs
make qt MXE_TARGETS='i686-w64-mingw32.static x86_64-w64-mingw32.static'

@Tshepang의 원래 답변에서 그는를 지정하지 않았 MXE_TARGETS으며 기본값이 사용됩니다. 그가 대답을 썼을 때 기본값은 였지만 i686-pc-mingw32이제는 i686-w64-mingw32.static. 명시 적 MXE_TARGETS으로 i686-w64-mingw32, 생략 으로 설정 하면 .static이 구문은 이제 더 이상 사용되지 않으므로 경고가 인쇄됩니다. 대상을로 설정하려고하면 i686-pc-mingw32MXE가 MinGW.org (예 : i686-pc-mingw32)에 대한 지원을 제거했기 때문에 오류가 표시됩니다.

달리는 qmake

우리는 변화로 MXE_TARGETS<mxe root>/usr/i686-pc-mingw32/qt/bin/qmake명령이 더 이상 작동 전혀 없이도 것입니다. 이제해야 할 일은 다음과 같습니다.

<mxe root>/usr/<TARGET>/qt/bin/qmake

지정하지 않은 경우 다음을 MXE_TARGETS수행하십시오.

<mxe root>/usr/i686-w64-mingw32.static/qt/bin/qmake

업데이트 : 새 기본값은 이제i686-w64-mingw32.static


좋아 내가 알아 낸 것 같아.

부분적으로 https://github.com/mxe/mxe/blob/master/src/qt.mkhttps://www.videolan.org/developers/vlc/contrib/src/qt4/rules.mak 기반

configure (-xtarget 등)를 실행할 때 "처음에"나타나는 것으로 보이며, 구성한 다음 "hosts"gcc를 실행하여 로컬 바이너리 파일 ./bin/qmake를 빌드합니다.

 ./configure -xplatform win32-g++ -device-option CROSS_COMPILE=$cross_prefix_here -nomake examples ...

그런 다음 정상적인 "make"를 실행하고 mingw를 위해 빌드합니다.

  make
  make install

그래서

  1. msvcrt.dll (기본값)이 아닌 다른 것을 사용해야하는 경우에만. 다른 것을 사용한 적이 없어서 확실하지 않습니다.

  2. https://stackoverflow.com/a/18792925/32453 은 일부 구성 매개 변수를 나열합니다.


In order to compile Qt, one must run it's configure script, specifying the host platform with -platform (e.g. -platform linux-g++-64 if you're building on a 64-bit linux with the g++ compiler) and the target platform with -xplatform (e.g. -xplatform win32-g++ if you're cross compiling to windows).

I've also added this flag: -device-option CROSS_COMPILE=/usr/bin/x86_64-w64-mingw32- which specifies the prefix of the toolchain I'm using, which will get prepended to 'gcc' or 'g++' in all the makefiles that are building binaries for windows.

Finally, you might get problems while building icd, which apparently is something that is used to add ActiveX support to Qt. You can avoid that by passing the flag -skip qtactiveqt to the configure script. I've got this one out of this bug report: https://bugreports.qt.io/browse/QTBUG-38223

Here's the whole configure command I've used:

    cd qt_source_directory
    mkdir my_build
    cd my_build
    ../configure \
      -release \
      -opensource \
      -no-compile-examples \
      -platform linux-g++-64 \
      -xplatform win32-g++ \
      -device-option CROSS_COMPILE=/usr/bin/x86_64-w64-mingw32- \
      -skip qtactiveqt \
      -v

As for yout questions:

1 - Yes. The native compiler will be called in order to build some tools that are needed in the build process. Maybe things like qconfig or qmake, but I'm not entirely sure which tools, exactly.

2 - Sorry. I have no idea what specs files are in the context of compilers =/ . But as far as I know, you wouldn't have to deal with that.

3 - You can specify the cross compiler prefix in the configure command line instead of doing it in the qmake.conf file, as mentioned above. And there's also that problem with idc, whose workaround I've mentioned as well.


Another way to cross-compile software for Windows on Linux is the mingw-w64 toolchain on Archlinux. It is easy to use and maintain, and it provides recent versions of the compiler and many libraries. I personally find it easier than MXE and it seems to adopt newer versions of libraries faster.

First you will need an arch-based machine (virtual machine or docker container will suffice). It does not have to be Arch Linux, derivatives will do as well. I used Manjaro Linux. Most of the mingw-w64 packages are not available at the official Arch repositories, but there is plenty in AUR. Default package manager for Arch (pacman) does not support installation directly from AUR, so you will need to install and use an AUR wrapper like pacaur or yaourt. Then installing mingw-w64 version of Qt5 and Boost libraries is as easy as:

pacaur -Sy mingw-w64-qt5-base mingw-w64-boost
#yaourt -Sy mingw-w64-qt5-base mingw-w64-qt5-boost #if you use yaourt

This will also install the mingw-w64 toolchain (mingw-w64-gcc) and other dependencies. Cross-compiling a Qt project for windows (x64) is then as simple as:

x86_64-w64-mingw32-qmake-qt5
make

To deploy you program you will need to copy corresponding dlls from /usr/x86_64-w64-mingw32/bin/.

To get a 32bit version you simply need to use i686-w64-mingw32-qmake-qt5 instead. Cmake-based projects work just as easy with x86_64-w64-mingw32-cmake. This approach worked extremely well for me, was the easiest to set-up, maintain and extend. It also goes well with continuous integration services. There are docker images available too.

For example, let's say I want to build QNapi subtitle downloader GUI. I could do it in two steps:

1) Start the docker container:

sudo docker run -it burningdaylight/docker-mingw-qt5 /bin/bash

2) Clone and compile QNapi

git clone --recursive 'https://github.com/QNapi/qnapi.git'
cd qnapi/
x86_64-w64-mingw32-qmake-qt5
make

That's it! In many cases it will be that easy. Adding your own libraries to package repository (AUR) is also straightforward. You would need to write a PKBUILD file, which is as intuitive as it can get, see mingw-w64-rapidjson, for example.

참고URL : https://stackoverflow.com/questions/10934683/how-do-i-configure-qt-for-cross-compilation-from-linux-to-windows-target

반응형