Cross-compilation issues when using MinGW

Hi,

At the moment I'm trying to get ANGLE packaged using the Fedora MinGW 
cross-compiler and I'm stumbling across some issues. The gyp build system 
(which ANGLE uses) doesn't seem to support cross-compiling well, so perhaps I'm 
doing something wrong but here's what I did so far to get ANGLE built:

svn checkout http://angleproject.googlecode.com/svn/trunk/ angleproject
cd angleproject
mkdir build_win32
cd build_win32
gyp -D OS=win --depth . -I ../build/common.gypi ../src/build_angle.gyp
make V=1 CXX=i686-w64-mingw32-g++ LIBS="-ld3d9 -ldxguid -ldwmapi" 
CXXFLAGS="-std=c++11 -msse2 -DUNICODE -D_UNICODE"

Initially the build fails because src/libEGL/Display.h tries to #include 
<D3Dcompiler.h> while the mingw-w64 toolchain only provides d3dcompiler.h (the 
Linux file system is case-sensitive). Attached patch fixes this

When the build completes, the following files are created in the folder 
'out/Debug/src':
libEGL.so  libGLESv2.so  libpreprocessor.a  libtranslator_common.a  
libtranslator_glsl.a  libtranslator_hlsl.a
The .so files which are in this folder are misnamed and are actually .dll files 
(my guess is that this is a gyp limitation).

Now I tried to open these .so files in Dependency Walker to find out what 
symbols are exported from it.
When opening libEGL.so the number of exported symbols are 1485 in total which 
looks a bit too much to me.
This list of exported symbols also contains various Direct3D symbols like 
CLSID_CDirect3DRM and GUID_D3DCallbacks2
(which are probably coming from the dxguid static library which is provided by 
the mingw-w64 toolchain).
The libGLESv2.so file contains an even larger amount of exported symbols, 6856 
to be exact.

I noticed that the ANGLE code also contains some .def files which contains a 
list of symbols which should be exported in the dll's.
For some reason (probably another gyp limitation) this .def file isn't used 
while building the library.

Another issue I noticed is that no import libraries are created. Normally each 
built library should also have a
corresponding .a (or .dll.a) file (.lib when using MSVC) so that other binaries 
can be linked against the library in question.

For both these issues I tried to workaround them by injecting custom LDFLAGS 
which are used to build the libraries.
For libGLESv2: -Wl,--out-implib,libGLESv2.dll.a ../src/libGLESv2/libGLESv2.def
For libEGL: -Wl,--out-implib,libEGL.dll.a -L. -lGLESv2 ../src/libEGL/libEGL.def

Unfortunately this results in a build failure.
When building the libGLESv2 library the following warnings are shown:

  flock out/Debug/linker.lock i686-w64-mingw32-g++ -shared -Wl,--out-implib,libGLESv2.dll.a ../src/libGLESv2/libGLESv2.def   -Wl,-soname=libGLESv2.so -o out/Debug/obj.target/../src/libGLESv2.so -Wl,--whole-archive out/Debug/obj.target/libGLESv2/../src/common/debug.o out/Debug/obj.target/libGLESv2/../src/common/RefCountObject.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/IndexDataManager.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/VertexDataManager.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Blit.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Buffer.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Context.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/D3DConstantTable.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Fence.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Float16ToFloat32.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Framebuffer.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/HandleAllocator.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/libGLESv2.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/main.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Program.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/ProgramBinary.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Query.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Renderbuffer.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/ResourceManager.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Shader.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/Texture.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/TextureSSE2.o out/Debug/obj.target/libGLESv2/../src/libGLESv2/utilities.o out/Debug/obj.target/../src/libtranslator_hlsl.a out/Debug/obj.target/../src/libtranslator_common.a out/Debug/obj.target/../src/libpreprocessor.a -Wl,--no-whole-archive -ld3d9 -ldxguid -ldwmapi
Warning: resolving _glActiveTexture by linking to _glActiveTexture@4
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving _glAttachShader by linking to _glAttachShader@8
Warning: resolving _glBeginQueryEXT by linking to _glBeginQueryEXT@8
<snip>
Warning: resolving _glVertexAttribPointer by linking to 
_glVertexAttribPointer@24
Warning: resolving _glViewport by linking to _glViewport@16
  SOLINK(target) out/Debug/obj.target/../src/libGLESv2.so: Finished

When building the libEGL library (which depends on some internal NONAME symbols 
in libGLESv2) the following error occurs:

flock out/Debug/linker.lock i686-w64-mingw32-g++ -shared 
-Wl,--out-implib,libEGL.dll.a -L. -lGLESv2 ../src/libEGL/libEGL.def 
-Wl,-rpath=\$ORIGIN/lib.target/   -Wl,-soname=libEGL.so -o 
out/Debug/obj.target/../src/libEGL.so -Wl,--whole-archive 
out/Debug/obj.target/libEGL/../src/common/debug.o 
out/Debug/obj.target/libEGL/../src/common/RefCountObject.o 
out/Debug/obj.target/libEGL/../src/libEGL/Config.o 
out/Debug/obj.target/libEGL/../src/libEGL/Display.o 
out/Debug/obj.target/libEGL/../src/libEGL/libEGL.o 
out/Debug/obj.target/libEGL/../src/libEGL/main.o 
out/Debug/obj.target/libEGL/../src/libEGL/Surface.o 
out/Debug/obj.target/../src/libGLESv2.so -Wl,--no-whole-archive -ld3d9 -ldxguid 
-ldwmapi
Warning: resolving _eglBindAPI by linking to _eglBindAPI@4
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving _eglBindTexImage by linking to _eglBindTexImage@12
Warning: resolving _eglChooseConfig by linking to _eglChooseConfig@20
<snip>
Warning: resolving _eglWaitGL by linking to _eglWaitGL@0
Warning: resolving _eglWaitNative by linking to _eglWaitNative@4
out/Debug/obj.target/libEGL/../src/libEGL/Display.o:Display.cpp:(.text+0x2d15): 
undefined reference to `glCreateContext'
out/Debug/obj.target/libEGL/../src/libEGL/Display.o:Display.cpp:(.text+0x303e): 
undefined reference to `glDestroyContext'
/usr/lib64/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld: 
out/Debug/obj.target/libEGL/../src/libEGL/Display.o: bad reloc address 0x0 in 
section `.data'
collect2: error: ld returned 1 exit status

My questions:
- Am I doing something wrong or are the discovered build issues limitations of 
the gyp build system?
- Should the generated .dll files only contain the symbols which are mentioned 
in the .def files?
- What can be done to prevent the undefined reference failure when building the 
libEGL library?
Original issue reported on code.google.com by epienbr...@gmail.com on 16 Dec 2012 at 6:38
Attachments:
angleproject-fix-case-sensitive-include.patch
lion0406 / angleproject

Cross-compilation issues when using MinGW #390
