[GRASS5] [emitchell@altaira.com: Re: grass autoconf]

Eric Mitchell emitchell at altaira.com
Fri Apr 28 08:53:00 EDT 2000



> > > On system that can do that (Linux, Solaris and probably some others),
> > > the benefits are evident for the binary distribution.  Of course,
> > > this should be avoided for development, since you want be able to
> > > run a debugger, hence use static libs.

You should still be able to debug programs build with dynamic
libs. I do this all the time at work.

> > This should be a flag for "configure".

The standard options are --enable-shared and --enable-static.
The defaults depend on the platform.  This really only affects
the building of "libtool" libraries.  libtool is basically a 
script that wraps around platform specific linker behaviour, 
so the process of creating a shared library is the same on 
all supported platforms.

> there are some problems with dynamic libraries.
> 
> If GRASS will be split into several subpackages, it will be complicated
> to track all dependencies. You will have to do some
> scripting/programming to get the right libraries with the packages.

It would probably be best/easiest to just include all the libraries 
with the "base" package.  Splitting grass into several subpackages 
will require some assumptions as far as dealing with interpackage 
dependencies.  There are many ways of dealing with these dependencies,
but all of them have some drawbacks.

> If the libraries are stored in a private directory or in a non-standard
> directory, the path must be added to the loader configuration or
> exported via 'LD_LIBRARY_PATH'.

As with any shared library.  Libtool mentions this specifically 
when installing a shared library.  The default INSTALL instructions
mention it as well, IIRC.

> I can not say if there will be problems on other platforms than Linux,
> but on my SGI IRIX machine there are some problems with gcc and the IRIX
> linker (reported by others on the list too). Can not promise if i can
> dig into this.

The state of the GNU toolset on platforms other than Linux
and Solaris is sketchy at best.  Some require the GNU linker,
some require the platform linker, some require the platform's
native assembler, etc.  With IRIX, the last problem we ran
into was that the compiler couldn't generate code for the 
"new 32bit ABI".  This caused problems with 3rd party code 
we were attempting to compile against, and forced us to use
the SGI compiler for our project.  It's possible that with
SGI's recent efforts behind Linux, they may have improved the
condition of the GNU tools on their hardware.

> I would vote for a step-by-step approach. If the autoconf system works,
> we could discuss again if it is worth the effort.

I should be able to do some preliminary autoconf work over
the next week or so.  I'll keep you posted.


> Andreas

-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell         mailto:emitchell at altaira.com |
| tel: (301) 809 - 3534    Altair Aerospace Corporation |
| tel: (800) 7 - ALTAIR    4201 Northview Dr. Suite 410 |
| fax: (301) 805 - 8122    Bowie, MD  20716             |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
              ,___
          /"\  / o=\  /"""---===/
         /   \_/  \__/   ---===/ 
         |    //\   || /""TT""/ //\   || ||""\
         |   //  \  ||    ||   //  \  || ||__/
         |  //--==\ |L--/ ||  //--==\ || || "=,
          \      ---===/
           \____---===/

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



More information about the grass-dev mailing list