Rockthesmurf
Advanced Member
Hi there,
In an attempt to compile apkenv from my Windows box, it seemed my best bet was to use the cygwin environment (along with my existing CodeSourcery tool chain, and Pandora SDK). Initially things were looking pretty good:
$ make DEBUG=1
CC apkenv.o
CC linker/dlfcn.o
CC linker/strlcpy.o
CC linker/linker.o
CC linker/linker_environ.o
CC linker/rt.o
CC compat/hooks.o
CC compat/liblog_wrappers.o
CC compat/gles_wrappers.o
compat/gles_wrappers.c: In function 'my_glGetTexStreamDeviceNameIMG':
compat/gles_wrappers.c:1548: warning: control reaches end of non-void function
compat/gles_wrappers.c: In function 'my_glUnmapBufferOES':
compat/gles_wrappers.c:1524: warning: control reaches end of non-void function
compat/gles_wrappers.c: In function 'my_glMapBufferOES':
compat/gles_wrappers.c:1518: warning: control reaches end of non-void function
compat/gles_wrappers.c: In function 'my_glQueryMatrixxOES':
compat/gles_wrappers.c:1410: warning: control reaches end of non-void function
CC compat/libc_wrappers.o
CC compat/pthread_wrappers.o
CC compat/gles2_wrappers.o
CC apklib/ioapi.o
CC apklib/ioapi_mem.o
CC apklib/unzip.o
CC apklib/apklib.o
apklib/apklib.c: In function 'apk_get_shared_libraries':
apklib/apklib.c:83: warning: implicit declaration of function 'recursive_mkdir'
CC jni/jnienv.o
CC jni/shlib.o
CC imagelib/loadpng.o
CC imagelib/loadjpeg.o
CC debug/debug.o
CC pandora/platform.o
But then it tries to link:
LINK apkenv
C:\Users\scraft\Pandora\usr\local\angstrom\arm\arm-angstrom-linux-gnueabi\usr\lib/libz.so: file not recognized: File format
not recognized
collect2: ld returned 1 exit status
makefile:90: recipe for target `apkenv' failed
make: *** [apkenv] Error 1
The problem it is having is that libz.so is a symbolic link, cygwin knows this:
$ file "C:\Users\scraft\Pandora\usr\local\angstrom\arm\arm-angstrom-linux-gnueabi\usr\lib/libz.so"
C:\Users\scraft\Pandora\usr\local\angstrom\arm\arm-angstrom-linux-gnueabi\usr\lib/libz.so: symbolic link to `libz.so.1.2.3'
But the Code Sourcery tool chain seems to struggle, a simple example:
$ arm-none-linux-gnueabi-nm.exe C:/Users/scraft/Pandora/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/libz.so
arm-none-linux-gnueabi-nm.exe: C:/Users/scraft/Pandora/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/libz.so: File format not recognized
The version I am running:
gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202)
Perhaps I should try a later version of Code Soucery (on one of my other machines I actually have a later version set up)?
For what it is worth I have tried putting CYGPATH=cygpath in my environment, but it doesn't help.
Has anyone experienced this? Feels like there must be a solution?!
In an attempt to compile apkenv from my Windows box, it seemed my best bet was to use the cygwin environment (along with my existing CodeSourcery tool chain, and Pandora SDK). Initially things were looking pretty good:
$ make DEBUG=1
CC apkenv.o
CC linker/dlfcn.o
CC linker/strlcpy.o
CC linker/linker.o
CC linker/linker_environ.o
CC linker/rt.o
CC compat/hooks.o
CC compat/liblog_wrappers.o
CC compat/gles_wrappers.o
compat/gles_wrappers.c: In function 'my_glGetTexStreamDeviceNameIMG':
compat/gles_wrappers.c:1548: warning: control reaches end of non-void function
compat/gles_wrappers.c: In function 'my_glUnmapBufferOES':
compat/gles_wrappers.c:1524: warning: control reaches end of non-void function
compat/gles_wrappers.c: In function 'my_glMapBufferOES':
compat/gles_wrappers.c:1518: warning: control reaches end of non-void function
compat/gles_wrappers.c: In function 'my_glQueryMatrixxOES':
compat/gles_wrappers.c:1410: warning: control reaches end of non-void function
CC compat/libc_wrappers.o
CC compat/pthread_wrappers.o
CC compat/gles2_wrappers.o
CC apklib/ioapi.o
CC apklib/ioapi_mem.o
CC apklib/unzip.o
CC apklib/apklib.o
apklib/apklib.c: In function 'apk_get_shared_libraries':
apklib/apklib.c:83: warning: implicit declaration of function 'recursive_mkdir'
CC jni/jnienv.o
CC jni/shlib.o
CC imagelib/loadpng.o
CC imagelib/loadjpeg.o
CC debug/debug.o
CC pandora/platform.o
But then it tries to link:
LINK apkenv
C:\Users\scraft\Pandora\usr\local\angstrom\arm\arm-angstrom-linux-gnueabi\usr\lib/libz.so: file not recognized: File format
not recognized
collect2: ld returned 1 exit status
makefile:90: recipe for target `apkenv' failed
make: *** [apkenv] Error 1
The problem it is having is that libz.so is a symbolic link, cygwin knows this:
$ file "C:\Users\scraft\Pandora\usr\local\angstrom\arm\arm-angstrom-linux-gnueabi\usr\lib/libz.so"
C:\Users\scraft\Pandora\usr\local\angstrom\arm\arm-angstrom-linux-gnueabi\usr\lib/libz.so: symbolic link to `libz.so.1.2.3'
But the Code Sourcery tool chain seems to struggle, a simple example:
$ arm-none-linux-gnueabi-nm.exe C:/Users/scraft/Pandora/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/libz.so
arm-none-linux-gnueabi-nm.exe: C:/Users/scraft/Pandora/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib/libz.so: File format not recognized
The version I am running:
gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202)
Perhaps I should try a later version of Code Soucery (on one of my other machines I actually have a later version set up)?
For what it is worth I have tried putting CYGPATH=cygpath in my environment, but it doesn't help.
Has anyone experienced this? Feels like there must be a solution?!