Opened 13 years ago
Closed 13 years ago
#1785 closed defect (fixed)
Can't compile under mingw 64-bit anymore
Reported by: | robe | Owned by: | strk |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 2.0.1 |
Component: | build | Version: | master |
Keywords: | Cc: |
Description
I'm going to try recompiling 2.0.0 to make sure its not something that has changed in my environment, but 2.0.1 doesn't compile -- gives this error:
---- Making all in libpgcommon make[1]: Entering directory `/c/ming64/projects/postgis/postgis-2.0.1SVN/libpgcommon' x86_64-w64-mingw32-gcc -g -O2 -I../liblwgeom -Ic:/ming64/projects/pgx64/pg91/include/POSTGR~1/server -Ic:/ming64/projects/pgx64/pg91/include/POSTGR~1/server/port/win32 -I/c/ming64/projects/proj/rel-4.8.0w64/include -DDLL_EXPORT -DPIC -Wal l -Wmissing-prototypes -c -o gserialized_gist.o gserialized_gist.c x86_64-w64-mingw32-gcc -g -O2 -I../liblwgeom -Ic:/ming64/projects/pgx64/pg91/include/POSTGR~1/server -Ic:/ming64/projects/pgx64/pg91/include/POSTGR~1/server/port/win32 -I/c/ming64/projects/proj/rel-4.8.0w64/include -DDLL_EXPORT -DPIC -Wall -Wmissing-prototypes -c -o lwgeom_transform.o lwgeom_transform.c x86_64-w64-mingw32-gcc -g -O2 -I../liblwgeom -Ic:/ming64/projects/pgx64/pg91/inc lude/POSTGR~1/server -Ic:/ming64/projects/pgx64/pg91/includ/POSTGR~1/server/port/win32 -I/c/ming64/projects/proj/rel-4.8.0w64/include -DDLL_EXPORT -DPIC -Wall -Wmissing-prototypes -c -o lwgeom_pg.o lwgeom_pg.c ar rs libpgcommon.a gserialized_gist.o lwgeom_transform.o lwgeom_pg.o c:\ming64\mingw64\bin\ar.exe: creating libpgcommon.a make[1]: Leaving directory `/c/ming64/projects/postgis/postgis-2.0.1SVN/libpgcom mon' ---- Making all in postgis make[1]: Entering directory `/c/ming64/projects/postgis/postgis-2.0.1SVN/postgis ' I../libpgcommon postgis.sql.in.c | grep -v '^#' > postgis.sql.in /bin/sh: I../libpgcommon: No such file or directory
My mingw 3.4.5 32-bit still compiles okay
Change History (5)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
I've confirmed. The postgis 2.0.0 tagged compiles fine for me but 2.0.1 does not.
comment:3 by , 13 years ago
Okay I isolated the issue to our use of SQLPP.
On my mingw 32-bit
postgis/makefile SQLPP = /mingw/bin/cpp -traditional-cpp -P
but my mingw 64-bit SQLPP =
So I guess it doesn't know how to properly handle the:
$(SQL_OBJS): %.in: %.in.c $(SQLPP) -I../libpgcommon $< | grep -v '^#' > $@
in http://trac.osgeo.org/postgis/browser/trunk/postgis/Makefile.in#L135
comment:4 by , 13 years ago
Right so the culprit must be this commit: http://trac.osgeo.org/postgis/changeset/9639/.
What does typing just "cpp" at the MingW terminal give you on both 32-bit and 64-bit? I'm guessing that perhaps it doesn't exist on 64-bit.
comment:5 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Mark,
I figured out how to fix so I'm going to close this out. I suspect it is only an issue with cross-compilers. I'm not sure how to make it pick it up right, I think it does for other executables.
The issue is that in my c:\ming64\mingw64\bin the file is called:
x86_64-w64-mingw32-cpp.exe
If I copy this striping off the version so I have just a cpp.exe
It picks it up fine and compiles fine. Still doing my make check.
I suspect I may just have to note this in the wiki on compiling under mingw64, because some mingw64 have the executables already stripped and some do not so might work for one person out of the box and not another. I've had to do this with one other exe. Can't remember which one off hand.
forgot to mention this is using r9653 and I did do an sh autogen.sh and a make clean