checking whether to use OpenGL... yes
checking for location of OpenGL includes...
checking for GL/gl.h... yes
checking for GL/glu.h... yes
checking for location of OpenGL library...
checking for glBegin in -lGL... no
checking for glBegin in -lGL... no
checking for glBegin in -lGL... no
checking for glBegin in -lGL... no
configure: error: *** Unable to locate OpenGL library.
regardless of --with-opengl, even for `--with-opengl=no` I am getting
`checking whether to use OpenGL... yes`, mysterious.
Moreover
checking host system type... config.sub: missing argument
Try `config.sub --help' for more information.
i can confirm this with your recent changes in svn with r45429 etc. for grass6-develbranch.
but it's very interesting, in the same osgeo4w-build-environment my patches of http://trac.osgeo.org/grass/ticket/1271 applied, there aren't any configure errors.
i can confirm this with your recent changes in svn with
r45429 etc. for grass6-develbranch.
fwiw, that needs to be reverted, then audited and real fixes
committed piecemeal. it's a collection of private patches and
hacks to get it to run on the osgeo4w stack, not project wide
solutions. e.g. it simply comments out a problematic autoconf
search for geos, and a bunch more like that.
i can confirm this with your recent changes in svn with
r45429 etc. for grass6-develbranch.
fwiw, that needs to be reverted, then audited and real fixes
committed piecemeal. it's a collection of private patches and
hacks to get it to run on the osgeo4w stack, not project wide
solutions. e.g. it simply comments out a problematic autoconf
search for geos, and a bunch more like that.
I agree that some changes need to be fixed/reverted. Anyway 80% of
changes are relevant, so I do not feel that it should be reverted all.
The winGRASS packaging is broken for more then 10 days, I don't think
that this commit made situation worse than it is now. Unfortunately I
will have time for it on Tuesday not earlier.
On Sun, 20. Feb 2011 at 21:02:42 +0100, Martin Landa wrote:
I agree that some changes need to be fixed/reverted. Anyway 80% of
changes are relevant, so I do not feel that it should be reverted all.
The winGRASS packaging is broken for more then 10 days, I don't think
that this commit made situation worse than it is now. Unfortunately I
will have time for it on Tuesday not earlier.
The configure.in part was actually wrong - shouldn't have gone into the diff.
I tried to fix configure manually to use the library geos-config reports and
removed configure's hardwired assumption that it's always called geos_c - it's
called geos_c_i on Windows (at least in the VC build).
So that still needs to be fixed in configure.in...
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
--
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>> i can confirm this with your recent changes in svn
>> with r45429 etc. for grass6-develbranch.
Hamish:
> fwiw, that needs to be reverted, then audited and real fixes
> committed piecemeal. it's a collection of private patches and
> hacks to get it to run on the osgeo4w stack, not project wide
> solutions. e.g. it simply comments out a problematic autoconf
> search for geos, and a bunch more like that.
Martin:
I agree that some changes need to be fixed/reverted. Anyway
80% of changes are relevant, so I do not feel that it should
be reverted all.
the danger if incomplete/problematic stuff is committed, then is
left in a "just commit it and we'll clean it up later" state, is
that it easily gets forgotten about and the brokenness remains in
svn. As has happened here.
I'd agree it's a bit silly to revert the 80% G_free()s, but now
that I think about it more, that should be reverted too and then
recommitted with a proper commit log message explaining why the
change was needed (DLL spanning problems) as it's not at all
obvious and can't be commented in the code.
The winGRASS packaging is broken for more then 10 days, I don't
think that this commit made situation worse than it is now.
POV choice: broken wingrass nightly build vs. new bugs for all
GRASS builds... if wingrass needs special patches those should
go into mswindows/osgeo4w/ and be applied at build time.
re. the g.region patch, ideally osgeo4w would ship projects.h
until Frank is able to ship a new version of proj4 with the
pj_projects() fn exposed publicly, and we are able to adapt to
whatever that is. for now I'd prefer a patch to be applied at
build time to adding a #ifdef in the code, but maybe it is best
to put such things into grass's include/gprojects.h?
(tbc'd on the proj4 bug for that)
the danger if incomplete/problematic stuff is committed, then is
left in a "just commit it and we'll clean it up later" state, is
that it easily gets forgotten about and the brokenness remains in
svn. As has happened here.
personally I don't think that this the case. winGRASS packaging is
totally broken for more then three weeks. This commit was just first
step to make it working again. winGRASS is very important part of the
project, so I don't think that "it easily gets forgotten about and the
brokenness remains in svn".
i can confirm this with your recent changes in svn with r45429 etc. for grass6-develbranch.
but it's very interesting, in the same osgeo4w-build-environment my patches of http://trac.osgeo.org/grass/ticket/1271 applied, there aren't any configure errors.
I have completely reinstalled osgeo4w environment on my Windows
machine, fixed package.sh in r45464. GRASS has been compiled without
any error. Note that I haven't applied any changes in g.region. Helmut
could you try it out please?
I have completely reinstalled osgeo4w environment on my Windows
machine, fixed package.sh in r45464. GRASS has been compiled without
any error. Note that I haven't applied any changes in g.region. Helmut
could you try it out please?
winGRASS 6.5 daily builds are back [1]. GRASS 6.4/7.0 will be fixed in
the next few days.
i can confirm this with your recent changes in svn with r45429 etc. for grass6-develbranch.
but it's very interesting, in the same osgeo4w-build-environment my patches of http://trac.osgeo.org/grass/ticket/1271 applied, there aren't any configure errors.
I have completely reinstalled osgeo4w environment on my Windows
machine, fixed package.sh in r45464. GRASS has been compiled without
any error. Note that I haven't applied any changes in g.region. Helmut
could you try it out please?
I've done a completly fresh checkout of grass65svn:
Revision: 45468
Author: martinl
Date: 21:48:43, Samstag, 26. Februar 2011
Message:
G_ftell() and G_fseek(): off_t replaced by int @TODO: enable LFS
----
Modified : /grass/branches/develbranch_6/include/gisdefs.h
Modified : /grass/branches/develbranch_6/lib/gis/seek.c
[...]
Revision: 45464
Author: martinl
Date: 20:39:55, Samstag, 26. Februar 2011
Message:
fix package.sh/configure
----
Modified : /grass/branches/develbranch_6/mswindows/osgeo4w/package.sh
[...]
but I haven't done a new setup of my osgeo4w-building-environment.
very interesting that wingrass compiles without any error at your side, because
I'm still getting an error in g.region:
I can do make in the directory after compiling has finished.
now make in /general/g.region:
_________________________________________________________________________
syringia@NADA /c/osgeo4w/usr/src/grass6_devel
$ ./mswindows/osgeo4w/package.sh
GRASS GIS compilation log
-------------------------
Started compilation: Sat Feb 26 23:33:10 GMT 2011
--
Errors in:
/c/osgeo4w/usr/src/grass6_devel/general/g.region
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Sun Feb 27 00:09:19 GMT 2011
syringia@NADA /c/osgeo4w/usr/src/grass6_devel
$ cd general/g.region
syringia@NADA /c/osgeo4w/usr/src/grass6_devel/general/g.region
$ make
../../include/Make/Module.make:25: warning: overriding commands for target `install'
../../include/Make/Rules.make:90: warning: ignoring old commands for target `install'
gcc -I/c/osgeo4w/usr/src/grass6_devel/dist.i686-pc-mingw32/include -I/c/OSGeo4W/include -g -O2 -I/c/OSGeo4W/include -I/c/OSGeo4W/include -I/c/OSGeo4W/include -DPACKAGE=\""grassmods"\" -I/c/OSGeo4W/include -I/c/osgeo4w/usr/src/grass6_devel/dist.i686-pc-mingw32/include -o OBJ.i686-pc-mingw32/printwindow.o -c printwindow.c
printwindow.c:3:22: projects.h: No such file or directory
printwindow.c: In function `print_window':
printwindow.c:500: error: storage size of 'fact' isn't known
printwindow.c:587: error: `LP' undeclared (first use in this function)
printwindow.c:587: error: (Each undeclared identifier is reported only once
printwindow.c:587: error: for each function it appears in.)
printwindow.c:587: error: syntax error before "lp"
printwindow.c:588: error: `lp' undeclared (first use in this function)
printwindow.c:588: error: `iproj' undeclared (first use in this function)
printwindow.c:588: error: `fact' undeclared (first use in this function)
printwindow.c:591: error: `in_proj_info' undeclared (first use in this function)
printwindow.c:592: error: `in_unit_info' undeclared (first use in this function)
printwindow.c:596: error: `convergence' undeclared (first use in this function)
printwindow.c: At top level:
printwindow.c:606: error: syntax error before "if"
printwindow.c:613: error: syntax error before "if"
printwindow.c:622: error: syntax error before "if"
printwindow.c:632: warning: initialization makes integer from pointer without a cast
printwindow.c:632: error: initializer element is not constant
printwindow.c:632: warning: data definition has no type or storage class
printwindow.c:633: warning: initialization makes integer from pointer without a cast
printwindow.c:633: error: initializer element is not constant
printwindow.c:633: warning: data definition has no type or storage class
printwindow.c:635: error: syntax error before string constant
printwindow.c:635: warning: data definition has no type or storage class
printwindow.c:643: error: syntax error before string constant
printwindow.c:643: warning: data definition has no type or storage class
printwindow.c:644: error: syntax error before string constant
printwindow.c:644: warning: data definition has no type or storage class
printwindow.c:645: error: syntax error before string constant
printwindow.c:645: warning: data definition has no type or storage class
printwindow.c:650: warning: parameter names (without types) in function declaration
printwindow.c:650: warning: data definition has no type or storage class
printwindow.c:651: warning: parameter names (without types) in function declaration
printwindow.c:651: warning: data definition has no type or storage class
printwindow.c:652: warning: parameter names (without types) in function declaration
printwindow.c:652: warning: data definition has no type or storage class
printwindow.c:653: warning: parameter names (without types) in function declaration
printwindow.c:653: warning: data definition has no type or storage class
printwindow.c:674: error: `window' undeclared here (not in a function)
printwindow.c:674: warning: data definition has no type or storage class
printwindow.c:675: warning: data definition has no type or storage class
printwindow.c:676: error: syntax error before "if"
printwindow.c:679: error: initializer element is not constant
printwindow.c:679: warning: data definition has no type or storage class
printwindow.c:680: error: initializer element is not constant
printwindow.c:680: warning: data definition has no type or storage class
printwindow.c:682: error: redefinition of 'latitude'
printwindow.c:674: error: previous definition of 'latitude' was here
printwindow.c:682: warning: data definition has no type or storage class
printwindow.c:683: error: redefinition of 'longitude'
printwindow.c:675: error: previous definition of 'longitude' was here
printwindow.c:683: warning: data definition has no type or storage class
printwindow.c:684: error: syntax error before "if"
printwindow.c:687: error: initializer element is not constant
printwindow.c:687: warning: data definition has no type or storage class
printwindow.c:688: error: initializer element is not constant
printwindow.c:688: warning: data definition has no type or storage class
printwindow.c:690: error: redefinition of 'latitude'
printwindow.c:682: error: previous definition of 'latitude' was here
printwindow.c:690: error: redefinition of 'latitude'
printwindow.c:682: error: previous definition of 'latitude' was here
printwindow.c:690: warning: data definition has no type or storage class
printwindow.c:691: error: redefinition of 'longitude'
printwindow.c:683: error: previous definition of 'longitude' was here
printwindow.c:691: error: redefinition of 'longitude'
printwindow.c:683: error: previous definition of 'longitude' was here
printwindow.c:691: warning: data definition has no type or storage class
printwindow.c:692: error: syntax error before "if"
printwindow.c:695: error: initializer element is not constant
printwindow.c:695: warning: data definition has no type or storage class
printwindow.c:696: error: initializer element is not constant
printwindow.c:696: warning: data definition has no type or storage class
printwindow.c:698: error: redefinition of 'latitude'
printwindow.c:690: error: previous definition of 'latitude' was here
printwindow.c:698: error: redefinition of 'latitude'
printwindow.c:682: error: previous definition of 'latitude' was here
printwindow.c:698: warning: data definition has no type or storage class
printwindow.c:699: error: redefinition of 'longitude'
printwindow.c:691: error: previous definition of 'longitude' was here
printwindow.c:699: error: redefinition of 'longitude'
printwindow.c:683: error: previous definition of 'longitude' was here
printwindow.c:699: warning: data definition has no type or storage class
printwindow.c:700: error: syntax error before "if"
printwindow.c:703: error: initializer element is not constant
printwindow.c:703: warning: data definition has no type or storage class
printwindow.c:704: error: initializer element is not constant
printwindow.c:704: warning: data definition has no type or storage class
printwindow.c:707: error: syntax error before "if"
printwindow.c:752: error: syntax error before '(' token
printwindow.c:752: error: conflicting types for 'libintl_fprintf'
printwindow.c:752: note: a parameter list with an ellipsis can't match an empty parameter name list declaration
c:/OSGeo4W/include/libintl.h:307: error: previous declaration of 'libintl_fprintf' was here
printwindow.c:752: error: conflicting types for 'libintl_fprintf'
printwindow.c:752: note: a parameter list with an ellipsis can't match an empty parameter name list declaration
c:/OSGeo4W/include/libintl.h:307: error: previous declaration of 'libintl_fprintf' was here
printwindow.c:753: error: syntax error before '(' token
printwindow.c:754: error: syntax error before '(' token
printwindow.c:755: error: syntax error before '(' token
printwindow.c:757: error: syntax error before '(' token
printwindow.c:762: error: syntax error before '(' token
printwindow.c:763: error: syntax error before numeric constant
printwindow.c:763: warning: data definition has no type or storage class
printwindow.c:764: error: syntax error before '(' token
printwindow.c:765: error: syntax error before numeric constant
printwindow.c:765: warning: data definition has no type or storage class
printwindow.c:766: error: syntax error before '(' token
printwindow.c:767: error: syntax error before numeric constant
printwindow.c:767: warning: data definition has no type or storage class
printwindow.c:768: error: syntax error before '(' token
printwindow.c:769: error: syntax error before '(' token
printwindow.c:771: error: syntax error before '(' token
printwindow.c:772: error: syntax error before '(' token
printwindow.c:774: error: syntax error before '(' token
make: *** [OBJ.i686-pc-mingw32/printwindow.o] Error 1
just to be sure, projects.h isn't there after Jürgens clean-up of osgeo4w in
your C:\OSGeo4W\include ?
best regards
Helmut
___________________________________________________________
Empfehlen Sie WEB.DE DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.web.de
I have completely reinstalled osgeo4w environment on my Windows
machine, fixed package.sh in r45464. GRASS has been compiled without
any error. Note that I haven't applied any changes in g.region. Helmut
could you try it out please?
I've done a completly fresh checkout of grass65svn:
but I haven't done a new setup of my osgeo4w-building-environment.
very interesting that wingrass compiles without any error at your side, because
I'm still getting an error in g.region:
just to be sure, projects.h isn't there after Jürgens clean-up of osgeo4w in
your C:\OSGeo4W\include ?
I have reinstalled my osgeo4 environment ~10 days ago and `projects.h`
is still in `osgeo4w/include`.
I have completely reinstalled osgeo4w environment on my Windows
machine, fixed package.sh in r45464. GRASS has been compiled without
any error. Note that I haven't applied any changes in g.region. Helmut
could you try it out please?
I've done a completly fresh checkout of grass65svn:
but I haven't done a new setup of my osgeo4w-building-environment.
>very interesting that wingrass compiles without any error at your side, because
>I'm still getting an error in g.region:
>just to be sure, projects.h isn't there after Jürgens clean-up of osgeo4w in
your C:\OSGeo4W\include ?
I have reinstalled my osgeo4 environment ~10 days ago and `projects.h`
is still in `osgeo4w/include`.
maybe I've messed something, so I reinstalled osgeo4w-proj and `projects.h`
is also here now on my side
> maybe I've messed something, so I reinstalled
> osgeo4w-proj and `projects.h` is also here now on my side
Martin wrote:
not sure, I wonder if r45469 is needed.
Frank has indicated that it projects.h will not be installed in
future versions of proj-dev, so as long as it does no harm let's
leave it there for now and only backport if needed / once we get
more info.
I think JEF or someone may have put it back into osgeo4w as a
favour to us.
tested with r45469.
ok, grass65 is also compiling now again here in my osgeo4w-stack.
thanks a lot for bringing back wingras65-compilation.
btw, `make install` puts executables to `c:\osgeo4w\bin\bin`. What
should be a write place for grass start script (sh/bat/py) from
osgeo4w point of view?
btw, `make install` puts executables to `c:\osgeo4w\bin\bin`. What
should be a write place for grass start script (sh/bat/py) from
osgeo4w point of view?
c:\osgeo4w\bin
or
c:\osgeo4w\apps\grass
or
?
hm, I see that `package.sh` tries to install its own version of start
script to `c:\osgeo4w\bin`. It's not necessary. Going to fix `make
install`.
btw, `make install` puts executables to `c:\osgeo4w\bin\bin`. What
should be a write place for grass start script (sh/bat/py) from
osgeo4w point of view?
c:\osgeo4w\bin
or
c:\osgeo4w\apps\grass
or
?
hm, I see that `package.sh` tries to install its own version of start
script to `c:\osgeo4w\bin`. It's not necessary. Going to fix `make
install`.
some time ago, the executables were installed in
c:\osgeo4w\apps\grass\bin
I think this would be a good place.
best regards
Helmut
___________________________________________________________
Schon gehört? WEB.DE hat einen genialen Phishing-Filter in die
Toolbar eingebaut! http://produkte.web.de/go/toolbar
hm, I see that `package.sh` tries to install its own version of start
script to `c:\osgeo4w\bin`. It's not necessary. Going to fix `make
install`.
some time ago, the executables were installed in
c:\osgeo4w\apps\grass\bin
I think this would be a good place.
I have cleaned up the scripts in mswindows\osgeo4w directory. There
are still some open issues, anyway (stand-alone installer) packaging
should work now.
The original osgeo4w package puts these files into `c:\osgeo4w\bin`
(btw including some extra tmpl files, which is not needed). I can't
see any good point why to create some extra directory which is
moreover not included in the path by default. So I would suggest to
forget about `c:\osgeo4w\apps\grass\bin`.
@jef: I understand that you prefer to find someone from the GRASS
community to do GRASS packaging for osgeo4w. Because nobody has taken
this job after your ask for that more times in the past I can offer
you myself for this position.