[Proj] Building with fresh gcc snapshot on Windows-XP fails

[Arjan van Dijk]

Hi!

After Paul Hiemstra gave me the hint to make a fresh install of MinGW,
I managed to build the Proj-4 library libproj.a on my Win-XP box.
Then I encountered problems with the gfortran version included with that 
gcc collection,
and someone pointed me at an ultimately fresh gcc snapshot, which 
can be downloaded from www.equation.com. 
My fortran performance was greatly boosted by this upgrade,
but Proj-4 now refuses to be built. Again... Of course I still have the
old library from the gcc version that I installed some days ago, but I 
don't like
having to have two gcc versions for all the different needs.

The gcc version that builds Proj-4 without problems is:

$ gcc -v 
Reading specs from c:/mingw/bin/../lib/gcc/mingw32/3.4.5/specs 
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with- 
gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw 
-- 
enable-threads --disable-nls --enable-languages=c,c+ 
+,f77,ada,objc,java --disable-win32-registry --disable-shared -- 
enable- 
sjlj-exceptions --enable-libgcj --disable-java-awt --without-x -- 
enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter -- 
enable-hash-synchronization --enable-libstdcxx-debug 
Thread model: win32 
gcc version 3.4.5 (mingw-vista special r3) 

The snapshot that has better Fortran support but that crashes building 
Proj-4 is:

$ gcc -v 
Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../gcc-4.4-20090220-mingw/configure 
--host=i386-pc-mingw32 --build=x86_64-unknown-linux-gnu 
--target=i386-pc-mingw32 
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.4-20090220 
--with-gcc --with-gnu-ld --with-gnu-as --disable-shared --disable-nls 
--disable-tls 
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp 
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr 
--enable-languages=c,fortran,c++ 
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.4-20090220 
--enable-libgomp --enable-threads=win32 --disable-win32-registry
Thread model: win32
gcc version 4.4.0 20090220 (experimental) (GCC) 


Using this gcc, ./configure ran okay, but "make" crashed: 
$ make 
Making all in src 
make[1]: Entering directory `d:/Arjan/proj/proj-4.6.1/src' 
c:/mingw/bin/make  all-am 
make[2]: Entering directory `d:/Arjan/proj/proj-4.6.1/src' 
C:/msys/1.0/bin/sh.exe ../libtool --tag=CC   --mode=compile gcc - 
DHAVE_CONFIG_H -I. -DPROJ_LIB=\"/usr/local/share/proj\"     -g -O2 -MT 
jniproj.lo -MD -MP -MF .deps/jniproj.Tpo -c -o jniproj.lo jniproj.c 
Xjniproj.Tpo -c -o jniproj.lo jniproj.lo 
libtool: compile: libobj name `jniproj.Tpo -c -o jniproj.lo 
jniproj.lo' may not contain shell special characters. 
rm: invalid option -- c 
Try `rm --help' for more information. 
 gcc -DHAVE_CONFIG_H -I. "-DPROJ_LIB=\\/usr/local/share/proj\" -g -O2 - 
MT jniproj.lo -MD -MP -MF .deps/jniproj.Tpo -c -o jniproj.lo 
jniproj.c"  -DDLL_EXPORT -DPIC -o .libs/jniproj.Tpo -c -o jniproj.lo 
jniproj.o 
gcc.exe: jniproj.o: linker input file unused because linking not done 
 gcc -DHAVE_CONFIG_H -I. "-DPROJ_LIB=\\/usr/local/share/proj\" -g -O2 - 
MT jniproj.lo -MD -MP -MF .deps/jniproj.Tpo -c -o jniproj.lo 
jniproj.c" -o jniproj.Tpo -c -o jniproj.lo jniproj.o >/dev/null 2>&1 
mv -f .deps/jniproj.Tpo .deps/jniproj.Plo 
mv: cannot stat `.deps/jniproj.Tpo': No such file or directory 
make[2]: *** [jniproj.lo] Error 1 
make[2]: Leaving directory `d:/Arjan/proj/proj-4.6.1/src' 
make[1]: *** [all] Error 2 
make[1]: Leaving directory `d:/Arjan/proj/proj-4.6.1/src' 
make: *** [all-recursive] Error 1 
Somehow the new gcc version cannot compile the same code that went 
allright with the old version, and that had led to a working C sample. 
Is the Proj-4 project "very sensitive" or "less generic"? Or is there a 
bug in the gcc snapshot? 

Arjan 




Disclaimer RIVM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20090227/e5a8f8ca/attachment.html>