[GRASS5] Re: bug in configure routine

Eric G . Miller egm2 at jps.net
Thu Nov 23 12:09:55 EST 2000


On Thu, Nov 23, 2000 at 01:55:54PM +0700, Justin Hickey wrote:
> Hi Eric
> 
> "Eric G . Miller" wrote:
> > On Wed, Nov 22, 2000 at 02:51:39PM +0700, Justin Hickey wrote:
> > > How about
> > >
> > > o XDRLIB empty for SGI machines
> > 
> > SGI doesn't have XDRLIB? It's required for encoding rasters.  Anyway,
> > if no special linking is needed for this, then $(XDRLIB) should
> > evaluate to an empty string.  Currently I have it set for the three
> > -lsun, -lnsl, and -lrpclib (if they exist).  Otherwise it now should
> > come up empty.
> 
> Yeah it's strange. On SGI, the XDRLIB is usually -lsun, however, I
> noticed that a lot of modules were indicating that -lsun wasn't being
> used when I was compiling. So to determine which modules were dependent
 
Does the -lsun "not used" or whatever break the compile or is it just an
informative message?  I'm not sure, but I'd think most modules don't
need it, but libgis.a does.  If libgis.a already has the XDRLIB compiled
in statically, then maybe the linker just refuses to include it twice
(good!).  But where it is not built into libgis.a, not having the flag
will cause libgis.a to fail.  If it doesn't break the compile, I'd
rather leave it in for now.  Seems at least libgis.a would need it, even
if the modules don't???  Maybe the functions or XDRLIB are built into
SGI's C library?  I could put in a check before the checks for XDRLIB if
that is the case.  Then I'd feel comfortable allowing XDRLIB to be
empty.

> > The "common" search directories can be looked for.  There's also the
> > --with-includes and --with-libs directives.  I wasn't aware of this
> > /usr/freeware separation with SGI.
> 
> Yeah, SGI has a page on their website for precompiled binaries of
> freeware (most of the GNU programs are there along with a lot of other
> stuff). But they bundle it into distributions that have pre-determined
> target directories, in this case /usr/freeware. I assume the
> --with-includes and --with-libs directives simply add on their values to
> the default search paths? We'll have to put this in an IRIX FAQ or
> something once we get configure working decently.

I'm trying to put in some hooks, so that if the --with-includes and/or
--with-libs directives are used, later searches for headers/functions
will use those extra paths.  I think I need to move that to before all
of the other checks.


> Oh yeah, do you recall that there is a dependency on some library for
> r.in.gdal? I seem to recall reading a message indicating this, but I'm
> not sure. Just thought I'd mention it.

Needs Frank's libgdal (or some such name).  I haven't had a chance to
try it out (suppose I should, since it seems to afford alot of
functionality).


-- 
Eric G. Miller <egm2 at jps.net>

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list