Help with cross compile

[efaj]

I've been trying to cross compile with no success, it's just not like normal linux things where everything just works... here, everything just NOT works... so, I was hoping if someone could tell me how they do their cross compilation, and how they set up their toolchain.

In general, my issue is not with CEGUI itself, since the errors are about missing freetype2 (ft2xxx.h - pardon my bad memory), but in general, my troubles are with setting up a toolchain or directory with all the dependencies so I can then reach all the way to cross compiling Ogre and my application. (and I know freetype is just the tip of the iceberg, and I'm even having problems with boost)

How do you organize your cross compilation?

[Kulik]

Hi, I have sort of given up on this dream and fire up a Windows 7 VM in virt-manager that does the compile instead. For years I wanted to automate this with scripts that would auto build things but haven't had time so far.

My experiences with cross compilation were similar to yours, I got some stuff to work but it was a lot of pain when dealing with complex dependencies.

Sorry for not being of more help.

PS: Woot, 1000th post! Do I get a cake?

[efaj]

Hi, I have sort of given up on this dream and fire up a Windows 7 VM in virt-manager that does the compile instead. For years I wanted to automate this with scripts that would auto build things but haven't had time so far.

My experiences with cross compilation were similar to yours, I got some stuff to work but it was a lot of pain when dealing with complex dependencies.

Sorry for not being of more help.

PS: Woot, 1000th post! Do I get a cake?

Empathy is as good.... at least i know it's not something personal the crosscompiler has against me....
It seems I can't compile from my Windows 7 (home edition) if I'm hoping to profit from the app, as it's not allowed by the eula. And even if it were, I was told by my local Intellectual Property office that the "sticker" in the comp doesn't count as a valid license (which would mean I don't own a windows version).

I'll be sure to share the info if I'm successful as present!

[efaj]

Pardon the double post, but after giving up on both this and my own OS, I decided to just "splat" everything at the side of mingw-bin (in "/usr/i586-mingw32msvc" for Ubuntu 12.04).... screw order: And I've made more advances (I think... at least the error is another)

Now my issue is that no matter what, "make" just goes to the default OGRE folder, which is not the one it should be using, but the precompiled one... but I've found no way to tell it to check in the default dir of mingw ("/usr/i586-mingw32msvc/include" and "/usr/i586-mingw32msvc/bin"). I found there are arguments for ./configure to tell such info for some libs, Irrlicht included, but not OGRE...

How can I do that for Ogre?

EDIT: This are some of the last lines of output:

Code: Select all

Making install in Ogre
make[4]: Entering directory `/media/datos/Dev/CEGUI-0.7.7/cegui/src/RendererModules/Ogre'
/bin/bash ../../../../libtool  --tag=CXX   --mode=compile i586-mingw32msvc-g++ -DHAVE_CONFIG_H -I. -I../../../../cegui/include -I../../../../cegui/include -I../../../../cegui/include/RendererModules/Ogre -pthread -I/usr/local/include -I/usr/local/include/OGRE   -DCEGUI_STATIC   -g -O2 -MT libCEGUIOgreRenderer_la-CEGUIOgreGeometryBuffer.lo -MD -MP -MF .deps/libCEGUIOgreRenderer_la-CEGUIOgreGeometryBuffer.Tpo -c -o libCEGUIOgreRenderer_la-CEGUIOgreGeometryBuffer.lo `test -f 'CEGUIOgreGeometryBuffer.cpp' || echo './'`CEGUIOgreGeometryBuffer.cpp
libtool: compile:  i586-mingw32msvc-g++ -DHAVE_CONFIG_H -I. -I../../../../cegui/include -I../../../../cegui/include -I../../../../cegui/include/RendererModules/Ogre -pthread -I/usr/local/include -I/usr/local/include/OGRE -DCEGUI_STATIC -g -O2 -MT libCEGUIOgreRenderer_la-CEGUIOgreGeometryBuffer.lo -MD -MP -MF .deps/libCEGUIOgreRenderer_la-CEGUIOgreGeometryBuffer.Tpo -c CEGUIOgreGeometryBuffer.cpp -o libCEGUIOgreRenderer_la-CEGUIOgreGeometryBuffer.o
i586-mingw32msvc-g++: unrecognized option '-pthread'
In file included from /usr/local/include/OGRE/OgreRenderTarget.h:36,
                 from /usr/local/include/OGRE/OgreRenderSystem.h:42,
                 from CEGUIOgreGeometryBuffer.cpp:33:
/usr/local/include/OGRE/OgreTimer.h:36:33: error: WIN32/OgreTimerImp.h: No such file or directory
make[4]: *** [libCEGUIOgreRenderer_la-CEGUIOgreGeometryBuffer.lo] Error 1
make[4]: Leaving directory `/media/datos/Dev/CEGUI-0.7.7/cegui/src/RendererModules/Ogre'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory `/media/datos/Dev/CEGUI-0.7.7/cegui/src/RendererModules'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/media/datos/Dev/CEGUI-0.7.7/cegui/src'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/media/datos/Dev/CEGUI-0.7.7/cegui'
make: *** [install-recursive] Error 1


After the edit, I used Ogre_CFLAGS and LIBS in the ./configure and ran... the makefile wasn't changed, so I manually changed it and ran make install. This lines are from that last run.

EDIT:
I just dropped the WIN32 file from OGRE_MINGW to the /usr/local one, and.... it compiled. Only the samples fail to compile due to -pthread and my own code due to mingw dieing saying it has a bug...
So... the formula for cross compiling seems to be:
Drop everything in the cross compiler toolchain's folder "/usr/i586-mingw32msvc/" at the moment in Ubuntu. Disable shared libraries (had to do so with CEGUI).
EDIT EDIT: Nevermind... it seems I was just able to build shared.

EDIT EDIT EDIT: All of CEGUI's output files are .a or .la while the others are .dll.a or something with .dll .... Shouldn't they have that .dll? and no .la as that's Linux's?

Aug/30 EDITx4: Ok, I've come a long way.... Ubuntu's MinGW was buggy and not supported by mingw.org themselves, so I went on with MXE... where everything is marvelous so far......
Now I was able to reach the point of compiling my project, but on linking there were 138 errors about undefined references to _imp___ZN5CEGUI7XXXXX where X is the name of a class followed by some variable or function not sure... added to the fact that the names don't coincide with how the rest of the libs are built, I have to ask:
Is the ./configure script done to correctly cross compile? I use a modified "./configure --host=i686-pc-mingw32" like instructed everywhere and still apparently only linux libs come out

[efaj]

Bump

I read that CE uses (or used) to cross compile CEGUI (at least back in 2008)... does he still? If possible, can I know how?

[dermont]

EDIT EDIT EDIT: All of CEGUI's output files are .a or .la while the others are .dll.a or something with .dll .... Shouldn't they have that .dll? and no .la as that's Linux's?

I'm not sure what version of MXE uses but with i686-w64-mingw32 on Ubuntu here it appears that when it attempts to link against a static lib (.a) it "fails" and subsequently creates a *CEGUI*.a lib.

Look for the messages during make and in particular "-no-undefined" in acinclude.m4. AFAIK that is required to ensure that shared libs are created so I don't know if removing/replacing it would do any good.

If you build purely against shared libs (i.e. convience libs *.dll.a) then the CEGUI .dll.a / dlls are created.

Also it wouldn't hurt explicitely stting the build to shared (even though shared is the default).
./configure ... --enable-shared=yes --enable-static=no

Now I was able to reach the point of compiling my project, but on linking there were 138 errors about undefined references to _imp___ZN5CEGUI7XXXXX where X is the name of a class followed by some variable or function not sure... added to the fact that the names don't coincide with how the rest of the libs are built, I have to ask:
Is the ./configure script done to correctly cross compile? I use a modified "./configure --host=i686-pc-mingw32" like instructed everywhere and still apparently only linux libs come out

I don't know what your build command looks like but at guess it could be that your build produced static CEGUI libs and the link order is not correct.

[efaj]

I'm not sure what version of MXE uses but with i686-w64-mingw32 on Ubuntu here it appears that when it attempts to link against a static lib (.a) it "fails" and subsequently creates a *CEGUI*.a lib.

Look for the messages during make and in particular "-no-undefined" in acinclude.m4. AFAIK that is required to ensure that shared libs are created so I don't know if removing/replacing it would do any good.

If you build purely against shared libs (i.e. convience libs *.dll.a) then the CEGUI .dll.a / dlls are created.

Also it wouldn't hurt explicitely stting the build to shared (even though shared is the default).
./configure ... --enable-shared=yes --enable-static=no

I had already explicitely stated it... seems that the real problem is precisely that MXE is made up of ONLY static libs, so as you said, the .dlls aren't created. The acinclude.m4 did have that flag, so now at least I'm assured that the issue was the compiler and not CEGUI.

I don't know what your build command looks like but at guess it could be that your build produced static CEGUI libs and the link order is not correct.

Yes it did produce static libs... seems that what I called "linux libs" were the .la that libtool uses, and .a that represent static in both platforms. And when I tried linking statically, it would fail since Ogre has dynamic libs.

I see you use mingw-w64 then... I had been trying to get a mingw that used dw2 like the Windows one to just use Ogre's premade bins. But seeing how SJLJ seems to be more native friendly, you use it (and you've been able to go through the whole process), and getting a dw2 is so hard.
Thanks a lot for your help expanding even across the realm of a single forum... once I really get something working, I'll expand on both Ogre's and CEGUI's wikis if possible with a more thorough and updated guide on cross compiling.

[dermont]

Yes it did produce static libs... seems that what I called "linux libs" were the .la that libtool uses, and .a that represent static in both platforms. And when I tried linking statically, it would fail since Ogre has dynamic libs.

I see you use mingw-w64 then... I had been trying to get a mingw that used dw2 like the Windows one to just use Ogre's premade bins. But seeing how SJLJ seems to be more native friendly, you use it (and you've been able to go through the whole process), and getting a dw2 is so hard.
Thanks a lot for your help expanding even across the realm of a single forum... once I really get something working, I'll expand on both Ogre's and CEGUI's wikis if possible with a more thorough and updated guide on cross compiling.

Yes I'm using mingw-w64 but haven't been through the whole process as you say. Since updating to mingw-w64 I've only cross-compiled the ogre dependencies and built Ogre static libs (enabling the OGRE_STATIC CMake option).

These are the relevant extracts from my CEGUI build (removing -no-undefined makes no difference, static libs are still created). I think I must be missing something obvious.

Your best bet would be to wait on one of the developers to comment.

Code: Select all

i686-w64-mingw32-g++ -DHAVE_CONFIG_H -I. -I../../cegui/include -I../../cegui/include -I/home/dermont/Libraries/CEGUI/dependencies/include/freetype2 -I/home/dermont/Libraries/CEGUI/dependencies/include -DCEGUIBASE_EXPORTS -g -O2 -MT libCEGUIBase_la-CEGUIFreeTypeFont.lo -MD -MP -MF .deps/libCEGUIBase_la-CEGUIFreeTypeFont.Tpo -c CEGUIFreeTypeFont.cpp  -DDLL_EXPORT -DPIC -o .libs/libCEGUIBase_la-CEGUIFreeTypeFont.o


*** Warning: linker path does not have real file for library -lfreetype.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libfreetype and none of the candidates passed a file format test
*** using a file magic. Last file checked: /home/dermont/Libraries/CEGUI/dependencies/lib/dynamic/libfreetype.a

*** Warning: linker path does not have real file for library -lpcre.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libpcre and none of the candidates passed a file format test
*** using a file magic. Last file checked: /home/dermont/Libraries/CEGUI/dependencies/lib/dynamic/libpcre.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
libtool: link: i686-w64-mingw32-ar cru .libs/libCEGUIBase.a .libs/libCEGUIBase_la-CEGUIAffector.o


Anyway even if the dependencies are built as shared libraries but named *.a instead of *.dll.a I don't understand how this is an issue.

As for testing CEGUI built against shared lib dependencies (the .dll.a issue) I only built a subset (namely TinyXML parser/TGAImageCodec).

Since you probably want to build against the same dependencies Ogre (static libs) I don't know how to resolve this other than build everything static. I haven't been able to cross-compile FreeImage as a shared lib and even if I did it would probably mean having to update the Ogre CMake files.

On Windows I use minGW gcc 4.7 which is not (binary)compatible with previous versions of gcc and therefore cannot use Ogre's premade sdk.