WinGrass7 - disable LFS

[hellik]

from the dev-ml: Sun Mar 14 03:10:19 EDT 2010

> >Has disabling LFS to be set explicitly for configure in the windows-world?
>   
> I've tried --disable-largefile, 
> 
> but again there is
> 
> [...] 
> checking if system supports Large Files at all... yes
> [...]
> Large File support (LFS):   yes
> [...]
> 
> in the build-log.
> 
> what have to be done to disable LFS for building WinGrass7?

configure.in is broken; it sets USE_LARGEFILES according to whether
LFS is detected, regardless of whether it is enabled. MinGW has LFS,
but it's not in a form which currently works with GRASS.

what are the differences to 6.4/6.5? both are compiling on WinVista?32.

Helmut

[glynn]

Replying to hellik:

what are the differences to 6.4/6.5? both are compiling on WinVista?32.

There are no differences in the configure checks. There may be differences is how the results of the checks are used.

[hellik]

Replying to glynn:

Replying to hellik:

what are the differences to 6.4/6.5? both are compiling on WinVista?32.

There are no differences in the configure checks. There may be differences is how the results of the checks are used.

so Grass7-compiling on Win-OS 32-bit and testing won't be possible (at the moment)?

Helmut

[glynn]

Replying to hellik:

so Grass7-compiling on Win-OS 32-bit and testing won't be possible (at the moment)?

Remind me again: what is being broken by the LFS mis-detection?

I occasionally compile and test 7.0 on Win32 (Windows XP), and haven't noticed any problems, but I haven't tested it thoroughly.

The one thing which I remember is that "make test" in lib/vector/diglib fails (it compares the output against test64.ok and fails because of the 32-bit off_t).

You could just modify Platform.make by hand after running configure.

[hellik]

Replying to glynn:

Replying to hellik:

so Grass7-compiling on Win-OS 32-bit and testing won't be possible (at the moment)?

Remind me again: what is being broken by the LFS mis-detection?

see  https://trac.osgeo.org/grass/ticket/930

i get errors in /vector/diglib, /raster/r.li/r.li.patchdensity, r.li.patchnum, /raster/r.patch, /gem.

and I don't get any usable Grass7 (following the instructions in  http://trac.osgeo.org/grass/wiki/CompileOnWindows#Grass-7.0.svntrunk), that means nothing is installed in C:\OSGeo4W\apps\grass.

Helmut

[hellik]

Replying to glynn:

Replying to hellik:

so Grass7-compiling on Win-OS 32-bit and testing won't be possible (at the moment)?

Remind me again: what is being broken by the LFS mis-detection? I occasionally compile and test 7.0 on Win32 (Windows XP), and haven't noticed any problems, but I haven't tested it thoroughly. The one thing which I remember is that "make test" in lib/vector/diglib fails (it compares the output against test64.ok and fails because of the 32-bit off_t). You could just modify Platform.make by hand after running configure.

in Platform.make there is after running configure

#Large File Support (LFS)
USE_LARGEFILES      = 1

should this be?

USE_LARGEFILES      =

[hellik]

Replying to hellik:

Replying to glynn:

Replying to hellik:

so Grass7-compiling on Win-OS 32-bit and testing won't be possible (at the moment)?

Remind me again: what is being broken by the LFS mis-detection?

see  https://trac.osgeo.org/grass/ticket/930 i get errors in /vector/diglib, /raster/r.li/r.li.patchdensity, r.li.patchnum, /raster/r.patch, /gem. and I don't get any usable Grass7 (following the instructions in  http://trac.osgeo.org/grass/wiki/CompileOnWindows#Grass-7.0.svntrunk), that means nothing is installed in C:\OSGeo4W\apps\grass. Helmut

so I did a completely fresh svn-checkout of g7.

there are still compiling errors.

Errors in:
/c/osgeo4w/usr/src/grass_trunk/lib/vector/diglib
/c/osgeo4w/usr/src/grass_trunk/raster/r.li/r.li.patchdensity
/c/osgeo4w/usr/src/grass_trunk/raster/r.li/r.li.patchnum
/c/osgeo4w/usr/src/grass_trunk/raster/r.patch
/c/osgeo4w/usr/src/grass_trunk/vector/v.patch
/c/osgeo4w/usr/src/grass_trunk/gem

- in diglib, that's

Glynn:
The one thing which I remember is that "make test" in lib/vector/diglib fails (it compares the output against test64.ok and fails because of the 32-bit off_t). 

in v.patch, r.patch r.li.patchdensity,r.li.patchnum, that seems again to be the problem with UAC and reserverd words for safety in the windows world. :o(

[...]
r.patch.exe: Bad file number
[...]

that's interesting, because all manifests for all exe-files are built. so there seems to be problems with exe-files (partly) labelled with reserverd words and executed outside a system-folder like C:\Program Files during compilation.

but I've got a little bit further.

now both folders C:\OSGeo4W\usr\src\grass_trunk\bin.i686-pc-mingw32 and C:\OSGeo4W\usr\src\grass_trunk\dist.i686-pc-mingw32 are build and grass7 is working from in there.

but nothing is in installed in C:\OSGeo4W\apps\grass.

so this report should only be valid for lib/vector/diglib, all other problems should be continued in  https://trac.osgeo.org/grass/ticket/930.

Helmut

[glynn]

Replying to hellik:

You could just modify Platform.make by hand after running configure.

in Platform.make there is after running configure

#Large File Support (LFS)
USE_LARGEFILES      = 1

should this be?

USE_LARGEFILES      =

Yes.

[glynn]

Replying to hellik:

in v.patch, r.patch r.li.patchdensity,r.li.patchnum, that seems again to be the problem with UAC and reserverd words for safety in the windows world. :o(

That would be my guess.

that's interesting, because all manifests for all exe-files are built.

Ah, but they're all built in one operation at the very end of the build process. They need to be built before "<cmd> --html-description" is run to generate the HTML documentation.

but I've got a little bit further. now both folders C:\OSGeo4W\usr\src\grass_trunk\bin.i686-pc-mingw32 and C:\OSGeo4W\usr\src\grass_trunk\dist.i686-pc-mingw32 are build and grass7 is working from in there. but nothing is in installed in C:\OSGeo4W\apps\grass.

I've never tested the OSGeo4W packaging. I normally just test building to dist.<arch>, and recently "make install" (to put it into "C:\Program Files").

so this report should only be valid for lib/vector/diglib,

The diglib issue should only happen if you don't unset USE_LARGEFILES, and should be harmless (the test is the last step, so failure doesn't cause anything important to be skipped). As MinGW doesn't understand _FILE_OFFSET_BITS, the value of USE_LARGEFILES should have no effect, other than selecting test64.ok rather than test32.ok. IOW, it's the test which is broken; the library itself works fine.

[glynn]

Replying to glynn:

in v.patch, r.patch r.li.patchdensity,r.li.patchnum, that seems again to be the problem with UAC and reserverd words for safety in the windows world. :o(

That would be my guess.

that's interesting, because all manifests for all exe-files are built.

Ah, but they're all built in one operation at the very end of the build process. They need to be built before "<cmd> --html-description" is run to generate the HTML documentation.

I've changed 7.0 (r41457 and r41458) to build manifests at the same time as the executable and (by default) to embed them into the executable. However, I only have XP, so I can't test this; please test 7.0 on Vista or Win7. It should be possible to build external manifests instead with "make MANIFEST=external".

[hellik]

Replying to glynn:

Replying to glynn:

in v.patch, r.patch r.li.patchdensity,r.li.patchnum, that seems again to be the problem with UAC and reserverd words for safety in the windows world. :o(

That would be my guess.

that's interesting, because all manifests for all exe-files are built.

Ah, but they're all built in one operation at the very end of the build process. They need to be built before "<cmd> --html-description" is run to generate the HTML documentation.

I've changed 7.0 (r41457 and r41458) to build manifests at the same time as the executable and (by default) to embed them into the executable. However, I only have XP, so I can't test this; please test 7.0 on Vista or Win7. It should be possible to build external manifests instead with "make MANIFEST=external".

I've had time for only a very quick test for compiling 7.0 on WinVista?32 (this time only again time for the ./mswindows/osgeo4w/package.sh-approach, so the diglib- and gem issue doesn't matter here at the moment, and also that installing in C:\OSGeo4W\apps\grass doesn't work; for a very basic testing grass7.0 is starting from C:\OSGeo4W\usr\src\grass_trunk\bin.i686-pc-mingw32).

embedding the manifests in the executables works quite well, no compiling errors for v.patch, r.patch r.li.patchdensity,r.li.patchnum etc. and no working/executing errors for v.patch, r.patch.

given grass64/65 installed in C:\OSGeo4W\apps\grass and with external manifests, i've seen sometimes a r.patch/v.patch-failure because of the reserverd-words-for-safety-in-the-windows-world-issue.

so maybe the embedded manifests would be also an option for grass64? I see that with the embedded manifests the v.patch/r.patch-executables are no longer marked with a mswindows-symbol like the executables without any manifests/with external manifests. so maybe the approach embedding the manifest would be better way?

Helmut

[glynn]

Replying to hellik:

embedding the manifests in the executables works quite well, no compiling errors for v.patch, r.patch r.li.patchdensity,r.li.patchnum etc. and no working/executing errors for v.patch, r.patch.

so maybe the embedded manifests would be also an option for grass64? I see that with the embedded manifests the v.patch/r.patch-executables are no longer marked with a mswindows-symbol like the executables without any manifests/with external manifests. so maybe the approach embedding the manifest would be better way?

It would probably be the better approach, but I don't know how easy it would be. The build system has been cleaned up a lot in 7.0; there were only a handful of executables which required special treatment, the rest being handled automatically by changes to Compile.make. The 6.x Makefiles have far more special cases.

A large part of the problem is that 6.x tries to support older versions of GNU make, while 7.0 requires version 3.81. That might not seem like much of a constraint, given that 3.81 has been out for nearly four years, but both MacOSX and MSys were using 3.79 (nearly ten years old) until fairly recently.

If someone wants to try back-porting the changes to 6.x: for normal modules, you would just need to modify the linking rule for $(BIN)/$(PGM)$(EXE) in Module.make. But you'll find dozens of programs with their own linking commands in their Makefiles (grep for LDFLAGS). You can check whether an executable has an embedded manifest by running "objdump -h" on it and looking for a ".rsrc" section.

[hellik]

Replying to hellik:

in v.patch, r.patch r.li.patchdensity,r.li.patchnum, that seems again to be the problem with UAC and reserverd words for safety in the windows world. :o( {{{ [...] r.patch.exe: Bad file number [...] }}}

see r41457 MinGW: embed manifests in EXEs

these are compiling now.

Helmut