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
Original issue reported on code.google.com by
epienbr...@gmail.com
on 16 Dec 2012 at 6:38Attachments: