Failed build with MXE cross compiler (Mingw)

[joede]

I've tried to build the library and the examples with the MXE cross compiler on Debian 8. While the library is build without problems, the examples and the test application can't be built. The linking process aborts with unresolved externals. I've put the (stripped down) output of the build into a gist.

https://gist.github.com/joede/279e36de061c422b5dcf097e307d2581

There is a bug in log4qt.pro. The inclusion of g++.pri uses the wrong path. It should be ../../g++.pri. Fixing the path leads to the same linking errors.

MXE uses g++ 4.9.3 and Qt 5.5.1!

Building log4qt on Debian 8 itself works very well and the test application finish without any failures. Debian 8 comes with g++ 4.9.2 and Qt 5.3!

[andibacher]

Hallo,

Thank you for your feedback. What is the MXE cross compiler exactly. Which plattform ist your build targeting.

From the outpout you provided I would guess it is a problem with the dll export. The log4t library uses the Qt Macro Q_DECL_EXPORT/Q_DECL_IMPORT. So if the plattform is dedected correct this should work on any platform. May be the MXE toolchain cases a wrong detection of the target platform?

We do continous integration on Linux (ubuntu, opensuse), Windows and Mac and everthing works in these builds so I don't think it is a problem with the log4qt library itself.

What you can try is the remove the hide_symbols from CONFIG in the log4qt.pro file: CONFIG += c++11 \ hide_symbols

If my suspicion is right and it has todo with the dll export this should fix your problem. Give me feedback if this works. Regards, Andreas

[joede]

Sorry for the delay. MXE is a really great collection of script and patches to build the mingw gcc toolchain for crosscompiling Windows binaries. Unlike the Debian package of mingw, this installations builds most of the common libraries too! The source of these libraries is fetched and than patched to allow crosscompilation. The included autotools and pkgconf are aware of this cross-platform-installation and work flawless. I use MXE to cross-build all of my Windows applications. Since my last project, I use Qt too.

Back to the problem... Your tipp doesn't help. I've removed hide_symbols and fixed the include path of g++.pri. The problem is still there, with and without the fix. The following Gist includes the full log of the build.

https://gist.github.com/joede/97f1b3a504b67cb7fb716e4c070c37a1

[andibacher]

I did setup MXE under ubuntu and I can confirm that I have the same problem. What I did not know so far was that MXE is doing a static linking to the Qt Library. Currently the Log4Qt project does not support static linking with Qt. It has never been testet in this usage. So far we only used it as shared library linked against the shared library of Qt.

[andibacher]

If I try to do a static build of the log4Qt library, tests and examples with mingw under windows I get the same errors as with MXE cross-build. As I mentioned before Log4Qt project does not seem to support static linkage with qmake. I will close the issue for now.

[joede]

MXE allows dynamic linking! If I find the time, I'll try to test this this week. The toolchain is named i686-w64-mingw32.shared-* or x86_64-w64-mingw32.shared-*!

[joede]

FYI: the MXE build works fine as soon as I use the shared library option.

x86_64-w64-mingw32.shared-qmake-qt5 log4qt.pro && make

[andibacher]

Thanks for the feedback, so it seems to be a general problem with static builds. Are static buidls somethings that is from interrest, then i will look into that when i find some time.

[joede]

IMO it would be nice to have static builds too. In my case, I use shared builds if I use an installer. In some situations I need "portable apps" which are static builds of a simple EXE file.