[GRASS-dev] Re: [GRASS-windows] Compiling grass7 on msys/mingw?

GRASS GRASS developer
1

Colin Nielsen wrote:

> I suspect that Python wants PYTHONPATH to use Windows syntax, e.g.
> (untested):
>
> - PYTHONPATH="$(GISBASE)/etc/python:$$PYTHONPATH" \
> + PYTHONPATH="$(call mkpath,$(GISBASE)/etc/python,$$PYTHONPATH)" \
> +
> +ifneq ($(MINGW32),)
> +mkpath = $(shell g.dirseps -h $(1))\;$(2)
> +else
> +mkpath = $(1):$(2)
> +endif

I applied this to the Html.make file and tried again. I got:

[snip]

If you apply the above as-is, you will get this error. The htmldesc=
definition needs to be a contiguous block, and the ifneq...endif block
needs to follow it.

I have attached a complete, modified Html.make file to avoid
confusion. This has at least been tested on Linux.

I then checked the variable PYTHONPATH and found that my Arc
installation over-wrote the PYTHONPATH variable to its own folder. I
changed this back to /usr/local/src/grass_trunk/lib/Python and ran it
again (with the original Html.make) and got:

    os.execvp("g.parser", [name] + argv)
  File "C:\MinGW\Python\lib\os.py", line 353, in execvp
    _execvpe(file, args)
  File "C:\MinGW\Python\lib\os.py", line 389, in _execvpe
    func(fullname, *argrest)
OSError: [Errno 2] No such file or directory

Ugh. I suspect os.execvp() needs "g.parser.exe" rather than
"g.parser". On Windows, only the higher-level interfaces (e.g.
ShellExecute() or "cmd /c ...") allow the .exe (or .bat etc) extension
to be omitted.

On Windows, we might want to use subprocess.Popen(shell=True) followed
by sys.exit() instead of os.execvp().

Before I continue with this, is this some peculiarity with my
installation or a more general problem with grass7 on mingw/msys?

The latter.

7.0 is quite fluid, and it doesn't seem to be getting much testing on
Windows (6.x doesn't get much testing either, but then 6.x isn't being
substantially rewritten).

--
Glynn Clements <glynn@gclements.plus.com>

(attachments)

Html.make (1.01 KB)

2

Glynn,

I have attached a complete, modified Html.make file to avoid
confusion. This has at least been tested on Linux.

Ugh. I suspect os.execvp() needs "g.parser.exe" rather than
"g.parser". On Windows, only the higher-level interfaces (e.g.
ShellExecute() or "cmd /c ...") allow the .exe (or .bat etc) extension
to be omitted.

Thanks for the help. You were right on both counts. I added the new
Html.make and edited the grass.py line 208 to:
     os.execvp("g.parser.exe", [name] + argv)

That works too, the scripts compile perfectly now. Although I realize
that some work around will be needed to make it OS generic.

Any idea why I get the other error for r.mapcalc, r.univar,
raster3d/base and v.voronoi?

gcc -L/usr/local/src/grass_trunk/dist.i686-pc-mingw32/lib
-Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/usr/local/lib
-L/usr/local/pgsql/lib -o
/usr/local/src/grass_trunk/dist.i686-pc-mingw32/bin/r.mapcalc.exe
../../lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime
-lxdr -liberty -lws2_32 -lz -lgrass_btree -lxdr -liberty
-lws2_32 -lz
/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x104): undefined
reference to `WinMain@16'
collect2: ld returned 1 exit status
make: *** [/usr/local/src/grass_trunk/dist.i686-pc-mingw32/bin/r.mapcalc.exe]
Error 1

7.0 is quite fluid, and it doesn't seem to be getting much testing on
Windows (6.x doesn't get much testing either, but then 6.x isn't being
substantially rewritten).

I am happy to test / keep posting errors for grass70 and grass64 as I
use grass in Windows Vista regularly. Let me know if there is anything
specific I should be testing/ looking for.

-Colin

3

Colin Nielsen wrote:

Any idea why I get the other error for r.mapcalc, r.univar,
raster3d/base and v.voronoi?

Not exactly, but I'm fairly sure that it's related to the fact that
those four directories are the only ones which use Multi.make (used
when building more than one module from a single directory).

gcc -L/usr/local/src/grass_trunk/dist.i686-pc-mingw32/lib
-Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/usr/local/lib
-L/usr/local/pgsql/lib -o
/usr/local/src/grass_trunk/dist.i686-pc-mingw32/bin/r.mapcalc.exe
../../lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime
-lxdr -liberty -lws2_32 -lz -lgrass_btree -lxdr -liberty
-lws2_32 -lz
/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x104): undefined
reference to `WinMain@16'
collect2: ld returned 1 exit status
make: *** [/usr/local/src/grass_trunk/dist.i686-pc-mingw32/bin/r.mapcalc.exe]
Error 1

Well, there are no object files except for fmode.o (which is added to
all executables to cause open() to use binary mode rather than text
mode).

The linking rule for a module in Module.make is:

  $(BIN)/$(PGM)$(EXE): $(ARCH_OBJS) $(DEPENDENCIES)
    $(call linker)

Multi.make splits this into two parts:

  $(BIN)/%$(EXE): $(DEPENDENCIES)
    $(call linker)
and:
  $(BIN)/$(1)$(EXE): $$(patsubst %.o,$(OBJDIR)/%.o,$$($$(subst .,_,$(1)_OBJS)))

The first is a pattern rule, and the second is part of an $(eval ...)
template which is instantiated for each module.

The prerequisites are supposed to be merged, but either this isn't
happening, or something is causing the template to come up empty.

I'm not sure if it's a flaw in the MSys version of make, or there's a
flaw in the rule related to $(EXE) (which will be empty on platforms
other than Windows).

Can you try the following:

  make -d -p -C raster/r.mapcalc &> out.log
  gzip out.log

and send me the resulting out.log.gz file?

--
Glynn Clements <glynn@gclements.plus.com>