Bad news:
it seems impossible to cross-compile the current GRASS 6.3.cvs version.
Bsically, every module I try to compile for Win32 on my Linux box fails
with sth. like this:
*** No rule to make target
`/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/lib/libgrass_vect.so',
needed by
`/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/bin/v.in.db.exe
Obviously, it should not be looking for libgrass_vect.so but for
libgrass_vect.dll !
I am still able to compile the same modules, using the same tools, in a
GRASS 6.1.CVS tree!
Maybe some change to the configure script or one of the GRASS makefiles
broke something?
Benjamin
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Benjamin Ducke wrote:
Bad news:
it seems impossible to cross-compile the current GRASS 6.3.cvs version.
Bsically, every module I try to compile for Win32 on my Linux box fails
with sth. like this:
*** No rule to make target
`/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/lib/libgrass_vect.so',
needed by
`/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/bin/v.in.db.exe
Obviously, it should not be looking for libgrass_vect.so but for
libgrass_vect.dll !
I am still able to compile the same modules, using the same tools, in a
GRASS 6.1.CVS tree!
Maybe some change to the configure script or one of the GRASS makefiles
broke something?
Odd.
AFAICT, cross-compiling shared libraries should never have worked.
SC_CONFIG_CFLAGS uses "uname" to determine the platform, which returns
the build platform, not the host platform.
It should be using either $host or the components $host_cpu,
$host_vendor, and $host_os.
--
Glynn Clements <glynn@gclements.plus.com>
Hmmmm, but I just tried a 6.2.0 source tree and used these instructions:
http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux
... and it worked OK, too!
And all the GRASS libs it made are definitely shared DLLs.
(although I did not get GDAL support working, but that's not important
for me at this point)
Glynn Clements wrote:
Benjamin Ducke wrote:
Bad news:
it seems impossible to cross-compile the current GRASS 6.3.cvs version.
Bsically, every module I try to compile for Win32 on my Linux box fails
with sth. like this:
*** No rule to make target
`/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/lib/libgrass_vect.so',
needed by
`/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/bin/v.in.db.exe
Obviously, it should not be looking for libgrass_vect.so but for
libgrass_vect.dll !
I am still able to compile the same modules, using the same tools, in a
GRASS 6.1.CVS tree!
Maybe some change to the configure script or one of the GRASS makefiles
broke something?
Odd.
AFAICT, cross-compiling shared libraries should never have worked.
SC_CONFIG_CFLAGS uses "uname" to determine the platform, which returns
the build platform, not the host platform.
It should be using either $host or the components $host_cpu,
$host_vendor, and $host_os.
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Benjamin Ducke wrote:
Hmmmm, but I just tried a 6.2.0 source tree and used these instructions:
http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux
... and it worked OK, too!
And all the GRASS libs it made are definitely shared DLLs.
Those instructions don't appear to use the GRASS configure script, but
a "winconfigure" script which is presumably supplied with QGIS.
--
Glynn Clements <glynn@gclements.plus.com>
Of course, that's the difference!
I am using that script myself ... my fault.
Are there any plans to modify the GRASS configure script to
allow for MINGW cross compilation?
Glynn Clements wrote:
Benjamin Ducke wrote:
Hmmmm, but I just tried a 6.2.0 source tree and used these instructions:
http://wiki.qgis.org/qgiswiki/BuildingWindowsBinaryOnLinux
... and it worked OK, too!
And all the GRASS libs it made are definitely shared DLLs.
Those instructions don't appear to use the GRASS configure script, but
a "winconfigure" script which is presumably supplied with QGIS.
--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany
Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg
Benjamin Ducke wrote:
Are there any plans to modify the GRASS configure script to
allow for MINGW cross compilation?
SC_CONFIG_FLAGS would need to be changed to use $host etc rather than
the output from "uname". The main problem is that the two approaches
use entirely different platform identifiers. E.g on my system:
# this is what SC_CONFIG_FLAGS uses
$ echo `uname -s`-`uname -r`
Linux-2.6.15.1
# this is what autoconf says
$ ./configure ...
...
GRASS is now configured for: i686-pc-linux-gnu
...
IOW, someone would need to change all of the "case" patterns to use
autoconf names instead, which means figuring out the mapping between
the two.
The only viable solution I can see is to essentially scrap the bulk of
the existing SC_CONFIG_FLAGS macro, and replace it with:
case $host in
i?86-pc-linux-*)
SHLIB_CFLAGS="-fPIC"
SHLIB_SUFFIX=".so"
CFLAGS_OPTIMIZE=-O2
SHLIB_LD="${CC} -shared"
LDFLAGS="-Wl,--export-dynamic"
LD_SEARCH_FLAGS='-Wl,-rpath-link,${LIB_RUNTIME_DIR}'
;;
*)
AC_MSG_ERROR([*** Unsupported platform: $host; please update SC_CONFIG_FLAGS in aclocal.m4])
;;
esac
Then, we wait for people to contribute the information which we need
to support the other platforms. The downside is that the other
platforms won't be supported until that happens.
--
Glynn Clements <glynn@gclements.plus.com>
Hello Benjamin and Glynn,
On Sat, 2 Dec 2006, Glynn Clements wrote:
Benjamin Ducke wrote:
Bad news:
it seems impossible to cross-compile the current GRASS 6.3.cvs version.
Bsically, every module I try to compile for Win32 on my Linux box fails
with sth. like this:
*** No rule to make target
`/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/lib/libgrass_vect.so',
needed by
`/home/benni/wingrass/source/grass6/dist.i586-pc-mingw32msvc/bin/v.in.db.exe
Obviously, it should not be looking for libgrass_vect.so but for
libgrass_vect.dll !
I am still able to compile the same modules, using the same tools, in a
GRASS 6.1.CVS tree!
Maybe some change to the configure script or one of the GRASS makefiles
broke something?
Odd.
AFAICT, cross-compiling shared libraries should never have worked.
Actually, I broke that recently. It did seem to support it in a kind of hacky way but the problem was it assumed if you were compiling for MINGW that you were cross-compiling, which broke native compiling on Windows in a few places. So I changed SC_CONFIG_CFLAGS to include a MINGW section and removed most of the MINGW conditional bits from configure.in.
SC_CONFIG_CFLAGS uses "uname" to determine the platform, which returns
the build platform, not the host platform.
It should be using either $host or the components $host_cpu,
$host_vendor, and $host_os.
Will investigate using $host_os if I get a chance. There should be some documentation on the internet I would hope? Quite a few people have contributed sets of compiler flags for their platform (and I've added a good few myself too) since we took that SC_CONFIG* stuff out of Tcl, and I wouldn't want to scrap all the useful information in there.
Paul
Paul Kelly wrote:
> SC_CONFIG_CFLAGS uses "uname" to determine the platform, which returns
> the build platform, not the host platform.
>
> It should be using either $host or the components $host_cpu,
> $host_vendor, and $host_os.
Will investigate using $host_os if I get a chance. There should be some
documentation on the internet I would hope? Quite a few people have
contributed sets of compiler flags for their platform (and I've added a
good few myself too) since we took that SC_CONFIG* stuff out of Tcl, and I
wouldn't want to scrap all the useful information in there.
We can keep the variable settings, if we can match up the platform
names between autoconf and uname. You can get some information by
analysing config.guess, but I doubt that there will be a 1:1
correspondence.
--
Glynn Clements <glynn@gclements.plus.com>