[PARTIALLY SOLVED] Link errors when compiling via mingw

[GauVeldt]

I attempted a sourceball mingw build of minetest (and dependencies since irrlicht and vorbisfile/vorbis/ogg didn't have mingw lib binaries)

NOTE: I got the link errors resolved by forcing minetest to a 32-bit build so I guess it was the 32-bit irrlicht DLL causing the issue (it refuses to compile 64-bit in mingw due to the AES code complaining '64-bit not supported'). Forcing it 32-bit wasn't as trivial since I had to track down the holdout resource file making a 64-bit resource even after adding -m32 to CFLAGS and CXXFLAGS (had to hack hardcoded command options to windres in CMakeLists.txt since it has no support for RCFLAGS in the configuration and I do not know the syntax in cmake for adding a new configuration setting. The option needed is to be able to set
RCFLAGS=-O coff -F pe-i386
in cmake when desired a 32-bit build of minetest (and line 418 must be adjusted in CMakeLists.txt to include the configuration's value in the windres command line, using blank string for 64-bit or as above for 32-bit).

The hardcoded hack is in line 418 of minetest/src/CMakeLists.txt:
\t\t\tCOMMAND ${CMAKE_RC_COMPILER} -O coff -F pe-i386 -I{CMAKE_CURRENT_SOURCE_DIR} -I${CMAKE_CURRENT_BINARY_DIR}

The dependencies successfully build into their .dll, .a and .def files

then I go to minetest and pass those file to the cmake configuration
All goes well in the build to the end which yields 4 link errors (climbs to 5 if I enable gettext which has its include and lib dirs copied over):

build done via mingw/code::blocks (with cmake's Makefile set as custom makefile for the project)

Sourceballs used:
gettext
irrlicht-1.7.3
libogg-1.3.2
libvorbis-1.3.4
minetest # zip download from github 2014.09.25
OpenAL #1.1
zlib-1.2.5
zlib125dll

Errors:
CMakeFiles\minetest.dir\objects.a(clientmap.cpp.obj)clientmap.cpp:(.text$_ZN3irr5scene10ISceneNode11getMaterialEj[_ZN3irr5scene10ISceneNode11getMaterialEj]+0x3)||undefined reference to `__imp__ZN3irr5video16IdentityMaterialE'|
CMakeFiles\minetest.dir\objects.a(content_cao.cpp.obj)content_cao.cpp|| undefined reference to `__imp__ZN3irr4core14IdentityMatrixE'|
CMakeFiles\minetest.dir\objects.a(content_cao.cpp.obj)content_cao.cpp|| undefined reference to `__imp__ZN3irr4core14IdentityMatrixE'|
CMakeFiles\minetest.dir\objects.a(content_cao.cpp.obj)content_cao.cpp|| undefined reference to `__imp__ZN3irr4core14IdentityMatrixE'|
||=== Build failed: 4 error(s), 0 warning(s) (0 minute(s), 17 second(s)) ===|

!!! PARTIALLY RESOLVED (but only 32-bit only) !!!
Forcing everything to 32-bit (-m32 but see below hack to force the resource file to 32-bit also) made it build correctly in mingw

I had to hack in -O coff and -F pe-i386 into minetest/src/CMakeLists.txt for the winresource.o file to allow minetest to do a 32-bit compile in mingw then it was able to link successfully to irrlicht (which will NOT compile -m64 via mingw)coff

I think the CMake should include the RCFLAGS variable for configuring 64-bit versus 32-bit builds!
RCFLAGS=-O coff -F pe-i386

[Krock]

Please use Irrlicht 1.8.1 and try again

[GauVeldt]

Please use Irrlicht 1.8.1 and try again

Will do.

If the irrlicht 1.7 branch no longer builds the current source the build instructions readme should probably be updated to reflect such in the dependencies section (it says to use Irrlicht 1.7.x).

On another note has it been considered to move away from OpenAL now that creative has done a microsoftesque triple-E on it?

[GauVeldt]

Isn't this error usually caused when a library headerfile contains a signature not defined (EDIT: or defined but inadvertently mismatched) by a respective implementation in the library's corresponding sourcefile (thus does not appear in the DLL), and then this signature is accessed by a user of the library?

If so it's in the header so it gets by the compiler but fails at the linker just like what is happening here.

[GauVeldt]

And after all that and building a 1.8.1 build of irrlicht and changing cmake settings to use it I still get the four linker errors in OP (yes I cleaned the minetest build first).

[Krock]

I got linking errors, too. Please try this OpenAL version: http://sfan5.pf-control.de/openal_stripped.zip
Maybe you'll have to edit the builtin Lua compiling file.. only know it from MSBuild.

[GauVeldt]

I got linking errors, too. Please try this OpenAL version: http://sfan5.pf-control.de/openal_stripped.zip
Maybe you'll have to edit the builtin Lua compiling file.. only know it from MSBuild.

At this point my link errors are as follows:
clientmap.cpp(clientmap.cpp.obj)
1x ...undefined reference to `__imp__ZN3irr5video16IdentityMaterialE'
content_cao.cpp(content_cao.cpp.obj)
3x ...undefined reference to `__imp__ZN3irr4core14IdentityMatrixE'

These very much look like irrlicht library references, not OpenAL or Lua references. Note the irr in the mangled name decorations.

[GauVeldt]

At this point I'm going to try forcing the entire build to 32-bit since that was the default in the irrlicht, vorbis, ogg et al builds. Due to the absence of a free 64-bit fortran in windows the GNU stuff is still broken since you can't bootstrap a cross compiled 64-bit native mingw and libraries. I don't have the ability to use GPU accelerated numpy in Python as a result (on a 64-bit system to use GPU accelerated numpy requires everything used in its building to be 64-bit native and it won't accept a cross compile).

I've had the architecture cause link issues in mingw before.

EDIT: nope no-go on that. looks like the bundled lua has only a 64-bit library

[GauVeldt]

...okay that's strange...

irrlicht won't compile -m64 (complains in the aes stuff)...
and minetest won't compile -m32 (complains in the lua stuff)

I see a rock and hard place here

EDIT: somehow it works if not explicitly specified up to those four link errors. I distrust stuff when settings work magically on defaults and fail when explicitly configured for what the default was choosing...

EDIT2: I lean more towards the explicit is better than implicit camp...

EDIT3: Okay uncovered what was going on with lua... seems I missed one of CFLAGS/CXXFLAGS in cmake when I was setting -m32

[GauVeldt]

Forcing everything to 32-bit (-m32 but see below hack to force the resource file to 32-bit also) made it build correctly in mingw

I had to hack in -O coff and -F pe-i386 into minetest/src/CMakeLists.txt for the winresource.o file to allow minetest to do a 32-bit compile in mingw then it was able to link successfully to irrlicht (which will NOT compile -m64 via mingw)coff

I think the CMake should include the RCFLAGS variable for configuring 64-bit versus 32-bit builds!
RCFLAGS=-O coff -F pe-i386