Configure "-Prefix" Option for Cross Compiling

configure --prefix option for cross compiling

Yes you are right, --prefix is the path for working environment. Just use --prefix=/usr. You can check in which folder path make install command will install your binary by installing in DESTDIR. For example if you use --prefix=/usr and make install DESTDIR=/home/me/arm/build/target_fs, then the binaries will be installed in the folder /home/me/arm/build/target_fs/usr. And If you just run make install, then the binary will be installed in your prefix i.e. in "/usr".

As you are cross-compiling, I think it doesn't matter which prefix you use, because anyways you will be installing in DESTDIR and then copying the binary files manually to your target.

Cross-compile: How to install with one prefix, and deploy with a different prefix?

If I understand correctly, /var/install on your x86 system will be / on your alternative architecture.
To solve your issue, you need to modify the following step:

• configure will certainly do some sed in file, so you need to specify the final place

  ./configure --prefix=/ CC=[my-cross-compiler-gcc]

• makefile generated by automake have support of variable DESTDIR which is prepended to the installation path:

  make DESTDIR=/var/install install

Cross-compiling SystemC libraries and linking to them

In the last couple of days I've learnt a lot about libtool and how DLLEXPORT is meant to be used in a consistent manner.

It has made me realize that the root cause of the problem is the end-user (myself), as always...

To be fair, there is something inconsistent in the configure script that ships with SystemC. The below:

./configure --host=x86_64-w64-mingw32.static

• will build a static library (libsystemc.a) as expected
• but it will happily do so using settings for shared libraries by default (assuming --enable-shared)

It makes the end-user believe that everything is fine... when it isn't.

Once you understand that and you explicitly specify settings that are consistent with building a static library:

./configure --host=x86_64-w64-mingw32.static --disable-shared

then everything works just fine.

The SystemC cmake flow is more robust. It throws an error if you try to target Windows using the default settings, which leaves you no choice but to specify -DBUILD_SHARED_LIBS=OFF on the command line.

How to cross-compile Qt6 on Linux for Windows?

For those coming here from google with same problem.

In Qt6 you need to specify Cmake toolchain for cross-compilation (I get something similar to toolchain shared here), as 'alone' device-option CROSS_COMPILE (as in cmd from my question) is depreciated/outdated (or smth like that).

In my case I needed to use CMake toolchain and device-option CROSS-COMPILE as well, because in other way qmake was not able to find proper cross-platform compiler (in my case x86_64-w64-mingw32-g++-posix). To use compiler with "posix" at the end I needed to modify qtbase/mkspecs/win32-g++/qmake.conf. This is how it looks like after changes:

#
# qmake configuration for win32-g++
#
# Written for MinGW-w64 / gcc 5.3 or higher
#
# Cross compile example for i686-w64-mingw32-g++:
#   configure -xplatform win32-g++ -device-option CROSS_COMPILE=i686-w64-mingw32-
#

include(../common/g++-win32.conf)
include(../common/windows-desktop.conf)

# modifications to g++-win32.conf

QMAKE_CC                = $${CROSS_COMPILE}gcc-posix
QMAKE_CFLAGS           += -fno-keep-inline-dllexport
QMAKE_CFLAGS_WARN_ON   += -Wextra

QMAKE_CXX               = $${CROSS_COMPILE}g++-posix
QMAKE_CXXFLAGS         += -fno-keep-inline-dllexport
QMAKE_CXXFLAGS_WARN_ON  = $$QMAKE_CFLAGS_WARN_ON
QMAKE_CXXFLAGS_EXCEPTIONS_ON += -mthreads

QMAKE_LINK              = $${CROSS_COMPILE}g++-posix
QMAKE_LINK_C            = $${CROSS_COMPILE}gcc-posix

QMAKE_CFLAGS_LTCG       = -flto
QMAKE_CXXFLAGS_LTCG     = $$QMAKE_CFLAGS_LTCG
QMAKE_LFLAGS_LTCG       = $$QMAKE_CFLAGS_LTCG
QMAKE_LFLAGS_EXCEPTIONS_ON += -mthreads

load(qt_config)

Final ./configure cmd:

./../qt-everywhere-src-6.2.1/configure -prefix $HOME/Projects/testing_qt_builds/qtbuild_with_old_params -platform linux-g++ -xplatform win32-g++ -device-option CROSS_COMPILE=/usr/bin/x86_64-w64-mingw32- -opensource -opengl desktop -qt-host-path $HOME/Qt/6.2.1/gcc_64 -nomake tests -nomake examples -skip qtwebengine -- -DQT_BUILD_TOOLS_WHEN_CROSSCOMPILING=ON -DCMAKE_TOOLCHAIN_FILE=$HOME/Projects/toolchain.cmake

After cmake --build and cmake --install I got host-qmake script in my build path

$HOME/Projects/testing_qt_builds/qtbuild_with_old_params/bin/

Which I had to use to build my Qt project by passing .pro file to it. And then I just copied .exe file to Windows, provided all needed dlls and POOF, app works. :D

My thread on qt forum with same problem where one of moderators helped me a lot to get final solution.

---

Related Topics