[GRASS-dev] GRASS-6.3.0RC4 Windows Native Binary (MSYS) Build Errors

Marco_Pasetti · January 24, 2008, 11:22am

Hi List,

I’m new here. I started last week to face the “Build GRASS on Windows” problems. I never used MinGW & MSYS Enviroment, while I experienced ANSI C programming about 12 years ago (my first @ engineer university!) then never used anymore. Now I’m trying to resume some knowledges…

I built grass-6.3.0RC4 in MinGW and MSYS Enviroment using source code from http://download.osgeo.org/grass/grass63/source/grass-6.3.0RC4.tar.gz

Reading the error log I tried to look for the reasons of that errors.

First I checked out /imagery/i.class build errors. It seems to be generated by lack in MinGW of SIGSTP and SIGALRM signal definitions in mingw/include/signal.h
I added those signals to signal.h as follows:

#define SIGTSTP 18 /* Stop Request by Terminal /
#define SIGALRM 13 / Alarm Signal */

But recompiling it gives an error because of the lack of alarm() function in MinGW.

Similar errors come out from building other modules. The problem is due to the lack in MinGW of some Standard POSIX system calls to active processes; functions like alarm(), fork(), wait() and other of the same “group” are not supported in MinGW.
I think that a way to solve the problem could be to include MinGW windows API libraries and use, instead of alarm()…, equivalent functions supported by win API.

What do you think about?

Thanks,

Marco

mlennert · January 24, 2008, 11:39am

Hi Marco,

On 24/01/08 12:22, marco.pasetti@alice.it wrote:

I built grass-6.3.0RC4 in MinGW and MSYS Enviroment using source code from http://download.osgeo.org/grass/grass63/source/grass-6.3.0RC4.tar.gz <http://mailstore.rossoalice.alice.it/exchweb/bin/redir.asp?URL=http://download.osgeo.org/grass/grass63/source/grass-6.3.0RC4.tar.gz>
Reading the error log I tried to look for the reasons of that errors.
First I checked out /imagery/i.class build errors. It seems to be

Please look at (and amend) http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

Currently, the following i.* modules do not compile (also the info at http://geog-pc40.ulb.ac.be/grass/wingrass/, notably winmakeerror.log):

/c/grasssrc/grass6/imagery/i.class
/c/grasssrc/grass6/imagery/i.ortho.photo/photo.2image
/c/grasssrc/grass6/imagery/i.ortho.photo/photo.2target
/c/grasssrc/grass6/imagery/i.points
/c/grasssrc/grass6/imagery/i.vpoints

All of these won't work because they interactively use x-monitors which do not work on Windows (see last night's post by Glynn on that question: http://lists.osgeo.org/pipermail/grass-dev/2008-January/034965.html). So, I'm not sure that it is really worth spending any time on trying to solve compilation problems on them. They should be (and partly are - i.e. i.points/i.vpoints are replaced by the georectifier in gis.m) replaced by a combination of non-interactive modules and a gui layer.

However, what would be good to study and solve are the compilation errors for r.terraflow and r.li*...

Moritz

Marco_Pasetti · January 24, 2008, 1:32pm

Hi Moritz,

Thanks for your reply.

Please look at (and amend)
http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

About this document I’ve got some questions:

[…] The port is of the current cvs branch GRASS 6.3. There are no ports of earlier versions […]

I used 6.3.0RC4 source code (as I told you)… should I use a snapshot instead? (i.e. http://download.osgeo.org/grass/grass63/source/snapshot/grass-6.3.svn_src_snapshot_2008_01_19.tar.gz)
Actually I never used CVS, and in windows (using MSYS) I don’t know if it works (and how does it works!)
Some suggestions?

[…] You also have to erase $(MANDIR) $(MANPAGES) from line 13 of man/Makefile, i.e. ‘default: $(MANDIR) $(MANPAGES)’ → ‘default:’. […]

I’m reffering mainly to this wiki http://wiki.qgis.org/qgiswiki/BuildingFromSource#head-780e111c05f2c81b08bb55f1c8ad322cd6351fc1
This is a wiki on woh to build qgis, and contains all instructions on how to build grass Windows Native Binary to be included in qgis (so without GUI).
The previous instruction is not included, but building works though.

[…] After compiling you should copy libxdr.dll, libproj.dll, libpng.dll, libgdal-1.dll and libz.dll.1.2.3 into the GRASS lib directory and all the GDAL and PROJ .exe files in the bin directory into the GRASS bin directory […]

Is this necessary even if I want to run grass only i qgis?

However, what would be good to study and solve are the compilation
errors for r.terraflow and r.li*…

OK. I’ll work on that…

Thanks,

Marco

Da: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Inviato: gio 24/01/2008 12.39
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: [GRASS-dev] GRASS-6.3.0RC4 Windows Native Binary (MSYS) Build Errors

Hi Marco,

On 24/01/08 12:22, marco.pasetti@alice.it wrote:

I built grass-6.3.0RC4 in MinGW and MSYS Enviroment using source code
from
http://download.osgeo.org/grass/grass63/source/grass-6.3.0RC4.tar.gz
<http://mailstore.rossoalice.alice.it/exchweb/bin/redir.asp?URL=http://download.osgeo.org/grass/grass63/source/grass-6.3.0RC4.tar.gz>

Reading the error log I tried to look for the reasons of that errors.
First I checked out /imagery/i.class build errors. It seems to be

Please look at (and amend)
http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

Currently, the following i.* modules do not compile (also the info at
http://geog-pc40.ulb.ac.be/grass/wingrass/, notably winmakeerror.log):

/c/grasssrc/grass6/imagery/i.class
/c/grasssrc/grass6/imagery/i.ortho.photo/photo.2image
/c/grasssrc/grass6/imagery/i.ortho.photo/photo.2target
/c/grasssrc/grass6/imagery/i.points
/c/grasssrc/grass6/imagery/i.vpoints

All of these won’t work because they interactively use x-monitors which
do not work on Windows (see last night’s post by Glynn on that question:
http://lists.osgeo.org/pipermail/grass-dev/2008-January/034965.html).
So, I’m not sure that it is really worth spending any time on trying to
solve compilation problems on them. They should be (and partly are -
i.e. i.points/i.vpoints are replaced by the georectifier in gis.m)
replaced by a combination of non-interactive modules and a gui layer.

However, what would be good to study and solve are the compilation
errors for r.terraflow and r.li*…

Moritz

mlennert · January 24, 2008, 1:54pm

Hi Marco,

On 24/01/08 14:32, marco.pasetti@alice.it wrote:

Please look at (and amend)

http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

About this document I've got some questions:

1) [...] The port is of the current cvs branch GRASS 6.3. There are
no ports of earlier versions [...]

I used 6.3.0RC4 source code (as I told you)... should I use a
snapshot instead? (i.e. http://download.osgeo.org/grass/grass63/source/snapshot/grass-6.3.svn_src_snapshot_2008_01_19.tar.gz)
Actually I never used CVS, and in windows (using MSYS) I don't know
if it works (and how does it works!) Some suggestions?

No, the sentence should be reformulated to "The port is of the current GRASS version 6.3. There are no ports of earlier versions of GRASS."

2) [...] You also have to erase $(MANDIR) $(MANPAGES) from line 13 of
man/Makefile, i.e. 'default: $(MANDIR) $(MANPAGES)' -> 'default:'.
[...]

I'm reffering mainly to this wiki http://wiki.qgis.org/qgiswiki/BuildingFromSource#head-780e111c05f2c81b08bb55f1c8ad322cd6351fc1
This is a wiki on woh to build qgis, and contains all instructions
on how to build grass Windows Native Binary to be included in qgis
(so without GUI). The previous instruction is not included, but
building works though.

I'll have to test this again, but I think you are right. This used to cause problems, but doesn't anymore. Not sure why.

3) [...] After compiling you should copy libxdr.dll, libproj.dll, libpng.dll, libgdal-1.dll and libz.dll.1.2.3 into the GRASS lib directory and all the GDAL and PROJ .exe files in the bin directory
into the GRASS bin directory [...]

Is this necessary even if I want to run grass only i qgis?

I have no idea about how QGIS handles these dependencies. This you should better ask on the QGIS list. The instructions are about how to compile a native windows port of GRASS on its own.

However, what would be good to study and solve are the compilation errors for r.terraflow and r.li*...

OK. I'll work on that...

Great !

Moritz

Marco_Pasetti · January 24, 2008, 2:42pm

Hi Moritz,

No, the sentence should be reformulated to “The port is of the current
GRASS version 6.3. There are no ports of earlier versions of GRASS.”

Perfect! Now I know that building from RC4 source code is good, without referring to some cvs else.
Now the first step is done and I’m sure I worked on the right way (it just finished to re-compile RC4… it takes about two hours!! why so long???)

I’ll have to test this again, but I think you are right. This used to
cause problems, but doesn’t anymore. Not sure why.

good

I have no idea about how QGIS handles these dependencies. This you should better ask on the QGIS list.

Ok. I’ll ask to ggis-developer.

The instructions are about how to compile a native windows port of GRASS on its own

Is it a problem if I check out only the building, without testing grass as “standalone” complete windows version?
To do this I should install some other stuffs, and it seems I already overtook my target…
I’m going to explain…

I’m an engineering student and I’m making an experimental thesis on solar radiation and mathematic models simulating transitory functioning of solar cells (photovoltaic); I approached GIS few weeks ago only to know how to determinate horizon lines starting from elevation data and a given GPS point (I need that to carefully compare my model results with real measured data); so, I discovered a big and deep world (have you ever heard to pandora’s box myth?)… I also discovered that JRC developed a GRASS module called r.horizon that it’s perfect for my purpose… even if it’s not included in current grass distribution. I looked for sources and informations on how to build executables for windows; I even installed linux (ubuntu 7.10, dual boot with xp pro) on my machine, to let it work easily… but, for many reasons, I need it on windows… so… here I am! at this stage I already built r.horizon (and r.sun2 module, also from JRC) without errors… but I want to continue because I think that, if you (developer community) have been so kind in writing wikies and replay to mails, I must replay with tryng to do my job too…

Sorry for the OT. But I think it was necessary

Thanks,

Marco

Da: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Inviato: gio 24/01/2008 14.54
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: R: [GRASS-dev] GRASS-6.3.0RC4 Windows Native Binary (MSYS) Build Errors

Hi Marco,

On 24/01/08 14:32, marco.pasetti@alice.it wrote:

Please look at (and amend)
http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

About this document I’ve got some questions:

[…] The port is of the current cvs branch GRASS 6.3. There are
no ports of earlier versions […]

I used 6.3.0RC4 source code (as I told you)… should I use a
snapshot instead? (i.e.
http://download.osgeo.org/grass/grass63/source/snapshot/grass-6.3.svn_src_snapshot_2008_01_19.tar.gz)
Actually I never used CVS, and in windows (using MSYS) I don’t know
if it works (and how does it works!) Some suggestions?

No, the sentence should be reformulated to “The port is of the current
GRASS version 6.3. There are no ports of earlier versions of GRASS.”

[…] You also have to erase $(MANDIR) $(MANPAGES) from line 13 of
man/Makefile, i.e. ‘default: $(MANDIR) $(MANPAGES)’ → ‘default:’.
[…]

I’m reffering mainly to this wiki
http://wiki.qgis.org/qgiswiki/BuildingFromSource#head-780e111c05f2c81b08bb55f1c8ad322cd6351fc1
This is a wiki on woh to build qgis, and contains all instructions
on how to build grass Windows Native Binary to be included in qgis
(so without GUI). The previous instruction is not included, but
building works though.

I’ll have to test this again, but I think you are right. This used to
cause problems, but doesn’t anymore. Not sure why.

[…] After compiling you should copy libxdr.dll, libproj.dll,
libpng.dll, libgdal-1.dll and libz.dll.1.2.3 into the GRASS lib
directory and all the GDAL and PROJ .exe files in the bin directory
into the GRASS bin directory […]

Is this necessary even if I want to run grass only i qgis?

I have no idea about how QGIS handles these dependencies. This you
should better ask on the QGIS list. The instructions are about how to
compile a native windows port of GRASS on its own.

However, what would be good to study and solve are the compilation
errors for r.terraflow and r.li*…

OK. I’ll work on that…

Great !

Moritz

Hamish · January 25, 2008, 1:52am

marco.pasetti wrote:

I'm an engineering student and I'm making an experimental thesis on
solar radiation and mathematic models simulating transitory
functioning of solar cells (photovoltaic); I approached GIS few weeks
ago only to know how to determinate horizon lines starting from
elevation data and a given GPS point (I need that to carefully
compare my model results with real measured data); so, I discovered a
big and deep world (have you ever heard to pandora's box myth?)... I
also discovered that JRC developed a GRASS module called r.horizon
that it's perfect for my purpose... even if it's not included in
current grass distribution. I looked for sources and informations on
how to build executables for windows; I even installed linux (ubuntu
7.10, dual boot with xp pro) on my machine, to let it work easily....
but, for many reasons, I need it on windows... so.. here I am! at
this stage I already built r.horizon (and r.sun2 module, also from
JRC) without errors... but I want to continue because I think that,
if you (developer community) have been so kind in writing wikies and
replay to mails, I must replay with tryng to do my job too...

Note Cygwin+GRASS works well if you need to run on Windows in a stable
way. Of course helping to test the experimental native build is most
welcome too.

Hamish

____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Marco_Pasetti · January 25, 2008, 10:32am

Hi Hamish,

Note Cygwin+GRASS works well if you need to run on Windows in a stable
way. Of course helping to test the experimental native build is most
welcome too.

Yes, I read about it, but I agree that Windows Native Binary compiled using MinGW32 should be the right way.
Now I need to let things (I need) work in grass, intented as plugin in qgis.
I’m completing qgis building; later I will approach grass building as “standalone” application (so with TclTk and other stuffs not needed for grass-in-qgis use only);
I hope to give help in building and source code bug fixing… but I cannot be helpful in application testings, because, actually, I’m not a “full” grass user

Regards,

Marco

PS: I think that including Windows API lots of problems could be fixed, changing functions like alarm(), fork(), wait()… in the source code, with their equivalents avaible in Windows API. Is there possible to make a conditional structure in order to determinate which build platform is in use? in the way to let gcc determinate which header/function it should include/compile?

Da: Hamish [mailto:hamish_b@yahoo.com]
Inviato: ven 25/01/2008 2.52
A: marco.pasetti@alice.it; Moritz Lennert; grass-dev@lists.osgeo.org
Oggetto: Re: R: R: [GRASS-dev] GRASS-6.3.0RC4 Windows Native Binary (MSYS) Build Errors

marco.pasetti wrote:

I’m an engineering student and I’m making an experimental thesis on
solar radiation and mathematic models simulating transitory
functioning of solar cells (photovoltaic); I approached GIS few weeks
ago only to know how to determinate horizon lines starting from
elevation data and a given GPS point (I need that to carefully
compare my model results with real measured data); so, I discovered a
big and deep world (have you ever heard to pandora’s box myth?)… I
also discovered that JRC developed a GRASS module called r.horizon
that it’s perfect for my purpose… even if it’s not included in
current grass distribution. I looked for sources and informations on
how to build executables for windows; I even installed linux (ubuntu
7.10, dual boot with xp pro) on my machine, to let it work easily…
but, for many reasons, I need it on windows… so… here I am! at
this stage I already built r.horizon (and r.sun2 module, also from
JRC) without errors… but I want to continue because I think that,
if you (developer community) have been so kind in writing wikies and
replay to mails, I must replay with tryng to do my job too…

Note Cygwin+GRASS works well if you need to run on Windows in a stable
way. Of course helping to test the experimental native build is most
welcome too.

Hamish

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

mlennert · January 25, 2008, 11:18am

On 25/01/08 11:32, marco.pasetti@alice.it wrote:

PS: I think that including Windows API lots of problems could be fixed, changing functions like alarm(), fork(), wait()... in the source code, with their equivalents avaible in Windows API.

This is what Glynn suggests here: http://lists.osgeo.org/pipermail/grass-dev/2008-January/034999.html

Is there possible to make a conditional structure in order to determinate which build platform is in use? in the way to let gcc determinate which header/function it should include/compile?

Yes, just grep for "MINGW32" in lib/gis/ to see a whole series of examples, such as rename.c, sleep.c, etc.

Moritz

Marco_Pasetti · January 25, 2008, 12:34pm

Hi Moritz,

Yes. I read the mail. Let me finish to build latest qgis stable releas with RC4 built-in, then I will start to work on WinGrass standalone.
Probably I will need support about unix functions, in order to exactly know what do they do.

Regards,

Marco

Da: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Inviato: ven 25/01/2008 12.18
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: R: R: R: [GRASS-dev] GRASS-6.3.0RC4 Windows Native Binary (MSYS) Build Errors

On 25/01/08 11:32, marco.pasetti@alice.it wrote:

PS: I think that including Windows API lots of problems could be fixed,
changing functions like alarm(), fork(), wait()… in the source code,
with their equivalents avaible in Windows API.

This is what Glynn suggests here:
http://lists.osgeo.org/pipermail/grass-dev/2008-January/034999.html

Is there possible to make
a conditional structure in order to determinate which build platform is
in use? in the way to let gcc determinate which header/function it
should include/compile?

Yes, just grep for “MINGW32” in lib/gis/ to see a whole series of
examples, such as rename.c, sleep.c, etc.

Moritz