I downloaded the 2003_09_06 snapshots for 5.0 and 5.1.
I successfully built 5.0.
I am using a Sun with Solaris 9, gcc version 2.95.3, and GNU make.
I used configure --with-motif --without-postgres --without-odbc --without-fftw --without_gdal.
(1) When I tried to configure with proj, configure failed while trying to find proj_api.h. But proj_api.h does not exist in either snapshot. So I added --without_proj to the configure.
(2) There is no setenv function for Solaris. I solved that by adding a setenv function in lib/db/dbmi_client/start.c. #ifdef __sun
int setenv (const char *name, const char *value, int overwrite) {
/* Allocate more space each call */
char *buffer;
int len;
if (!overwrite && getenv(name)) return 0;
len = strlen(name) + strlen(value) + 2;
buffer = (char *) G_malloc (len);
sprintf (buffer, "%s=%s", name, value);
return putenv (buffer);
} #endif /* __sun */
(3) It then fails in lib/proj with the message
proj_api.h: No such file or directory
Is there supposed to be a proj_api.h file?
Since I configured without-proj, why is it trying to compile lib/proj?
I hope someone can help. Thanks for your time.
Bev Wallace
Lockheed Martin, Sunnyvale, CA, USA
beverly.t.wallace@lmco.com
I downloaded the 2003_09_06 snapshots for 5.0 and 5.1.
I successfully built 5.0.
I am using a Sun with Solaris 9, gcc version 2.95.3, and GNU make.
I used configure --with-motif --without-postgres --without-odbc --without-fftw --without_gdal.
(1) When I tried to configure with proj, configure failed while trying to find proj_api.h. But proj_api.h does not exist in either snapshot. So I added --without_proj to the configure.
You need to have an external PROJ library from remotesensing.org
installed, version 4.4.6 or later. GRASS 5.7 (as it is now) does not
include the internal copy of PROJ any more so an external PROJ is an
absolute requirement. This should probably be documented somewhere; I'm
not familiar with all the 5.1/5.7 documentation and am not sure where is
the best place; can you suggest a file this information could be added to?
(2) There is no setenv function for Solaris. I solved that by adding a setenv function in lib/db/dbmi_client/start.c.
No setenv in IRIX either. It was suggested to me before to replace
setenv() by putenv() and I recall that that worked. I haven't had that
particular error compiling on IRIX; maybe I have disabled something in
configure that doesn't compile that part of the database code.
(3) It then fails in lib/proj with the message
proj_api.h: No such file or directory
Is there supposed to be a proj_api.h file?
Since I configured without-proj, why is it trying to compile lib/proj?
(See above) It is set up that you are expected to have PROJ; quite a lot
of modules depend on it and it would need more changes to all their
Makefiles to disable compiling them if PROJ was not present. But could be
done if we decided it was worthwhile. The PROJ library is small and easy
to compile and install however.
On Thu, Sep 11, 2003 at 08:43:01PM +0100, Paul Kelly wrote:
Hello
On Thu, 11 Sep 2003, Wallace, Beverly T wrote:
> Hi Grass Developers,
>
> I am trying to build the experimental GRASS 5.1.
>
> I downloaded the 2003_09_06 snapshots for 5.0 and 5.1.
> I successfully built 5.0.
> I am using a Sun with Solaris 9, gcc version 2.95.3, and GNU make.
> I used configure --with-motif --without-postgres --without-odbc --without-fftw --without_gdal.
>
> (1) When I tried to configure with proj, configure failed while trying to find proj_api.h. But proj_api.h does not exist in either snapshot. So I added --without_proj to the configure.
You need to have an external PROJ library from remotesensing.org
installed, version 4.4.6 or later. GRASS 5.7 (as it is now) does not
include the internal copy of PROJ any more so an external PROJ is an
absolute requirement. This should probably be documented somewhere; I'm
not familiar with all the 5.1/5.7 documentation and am not sure where is
the best place; can you suggest a file this information could be added to?
It should go into INSTALL.
But ./configure should stop with an error when
--without_proj
is used. Then the situation were clear.
But ./configure should stop with an error when
--without_proj
is used. Then the situation were clear.
I have fixed this now---moved the PROJ test earlier in the sequence and
disabled --with-proj / --without-proj (the test is mandatory).
--with-proj-includes and --with-proj-libs still work if required.
> (1) When I tried to configure with proj, configure failed while
> trying to find proj_api.h. But proj_api.h does not exist in either
> snapshot. So I added --without_proj to the configure.
You need to have an external PROJ library from remotesensing.org
installed, version 4.4.6 or later. GRASS 5.7 (as it is now) does not
include the internal copy of PROJ any more so an external PROJ is an
absolute requirement. This should probably be documented somewhere;
I'm not familiar with all the 5.1/5.7 documentation and am not sure
where is the best place; can you suggest a file this information could
be added to?
Perhaps a hint ("Is PROJ.4 installed? See INSTALL file.") in the error
message when configure fails to find proj_api.h? Or is that not
possible/desirable.
On Thu, Sep 11, 2003 at 08:43:01PM +0100, Paul Kelly wrote:
On Thu, 11 Sep 2003, Wallace, Beverly T wrote:
> I am trying to build the experimental GRASS 5.1.
>
> I downloaded the 2003_09_06 snapshots for 5.0 and 5.1.
> I successfully built 5.0.
[...]
>
> (2) There is no setenv function for Solaris. I solved that by adding a
> setenv function in lib/db/dbmi_client/start.c.
No setenv in IRIX either. It was suggested to me before to replace
setenv() by putenv() and I recall that that worked. I haven't had that
particular error compiling on IRIX; maybe I have disabled something in
configure that doesn't compile that part of the database code.
We should aim at portability. Is there anything we could do to get
that code portion working? Go for "putenv()" or use the proposed
patch (modified?):
patch for lib/db/dbmi_client/start.c
#ifdef __sun
int setenv (const char *name, const char *value, int overwrite) {
/* Allocate more space each call */
char *buffer;
int len;
if (!overwrite && getenv(name)) return 0;
len = strlen(name) + strlen(value) + 2;
buffer = (char *) G_malloc (len);
sprintf (buffer, "%s=%s", name, value);
return putenv (buffer);
} #endif /* __sun */
G_setenv() modifies the GRASS settings in $GISRC, not environment
variables. Similarly for everything else in src/libes/gis/env.c
(except that G__getenv() explicitly handles "GISBASE" as a special
case).
> > But ./configure should stop with an error when
> > --without_proj
> > is used. Then the situation were clear.
>
> I have fixed this now---moved the PROJ test earlier in the sequence
> and disabled --with-proj / --without-proj (the test is mandatory).
> --with-proj-includes and --with-proj-libs still work if required.
Should this be done for GRASS 5.3 as well?
or not?
No, not until Frank has decided on the future direction of PROJ
development which seems to be a bit up in the air at the minute what with
Gerald's new competing version etc. GRASS needs to use 'Frank's' version
for datum support.
Main reason for not wanting to rely totally on it is a bug http://bugzilla.remotesensing.org/show_bug.cgi?id=368
that causes the wrong results to be given in the modules that use PROJ to
convert to/from lat/long co-ordinates on the same ellipsoid (r.sun etc.)
*iff* the PROJ_INFO file contains a 'nadgrids' line (sorry, just thinking
I should probably have mentioned this earlier. Hope it hasn't caused you
any trouble). The above bugzilla report contains a patch I submitted but
hasn't been accepted yet. We could apply it to the internal GRASS copy of
PROJ but then if Frank decides to do something different later it would
get inconsistent. And also the internal GRASS proj is only 4.4.5 with a
few bugfixes so e.g. you couldn't do NTv2 gridshifts with it unless
somebody wants to work out which files should be updated and do the work?
The bug is only because of the way we specify the lat/long 'co-ordinate
system' inside those modules like r.sun, which simply gets the ellipsoid
parameters from the current location and passes them on. If we used the
internal PROJ function pj_latlong_from_proj() (which I wasn't aware of
until recently) that would work around the PROJ bug (it makes sure the
datum information is exactly the same, which IMHO should be unnecessary as
if the elllipsoids are the same the datum shift info should be ignored). I
have implemented a wrapper for this in 5.7, called
GPJ_get_equivalent_latlong() which we can use to work around the bug. The
new ps.map contains somewhere it can be implemented already (but I
haven't changed it yet)
I have put some Doxygen-style comments and descriptions for the new 5.7
proj library functions in the files, however I'm not sure how to make the
appear in the programmer's manual.
Sorry this is a bit long but there are a few issues to be addressed about
relying on an external PROJ (not just those discussed here---how to bundle
the PROJ library with binary releases is another one). Hope it makes it a
little clearer.
Main reason for not wanting to rely totally on it is a bug http://bugzilla.remotesensing.org/show_bug.cgi?id=368
that causes the wrong results to be given in the modules that use PROJ to
convert to/from lat/long co-ordinates on the same ellipsoid (r.sun etc.)
*iff* the PROJ_INFO file contains a 'nadgrids' line (sorry, just thinking
I should probably have mentioned this earlier. Hope it hasn't caused you
any trouble). The above bugzilla report contains a patch I submitted but
hasn't been accepted yet. We could apply it to the internal GRASS copy of
PROJ but then if Frank decides to do something different later it would
get inconsistent.
I decided to go ahead and apply this patch to the 5.3 CVS. So now even if you
have a nadgrids line in your PROJ_INFO (i.e. most likely a NAD27 location,
e.g. spearfish), if you use the internal GRASS copy of PROJ you will be OK
and not affected by this bug (affects r.sun, new d.where etc. and other
programs that convert co-ordinates to lat/long).
This means you probably shouldn't use the --with-proj option with 5.3,
unless you really rely on some feature that is in the latest version of
remotesensing.org PROJ.4. The only such feature I can think of is the NTv2
gridshifting support so if you need it you can add the nadgrids: line to
the PROJ_INFO when you need to use [rsv].proj, and delete it when you need
to use the modules that do lat/long conversion.
I hope this is clear enough. It does seem to be a bit of a backward step
to go back to using the internal static library and it would be possible
to work around the PROJ bug by changing all the affected modules to use
the pj_latlong_from_proj() function; unfortunately I don't have time to do
that now.