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

GRASS GRASS developer
2

About Grass Makefile/Compilation : I once (time of 4.2.0 ?) modified
the makefiles in order to made dynamic libraries (libxxx.so) instead
of static ones (libxxx.a). All the .so files were put in a "lib" directory
at the same level than etc, dev, bin, scripts, ...
The whole binary tree took about one third of the space of the regular
binary distribution. It ran also faster (launch time reduced).
If I remember correctly it took me about 3 or 4 nights to figure
out what to do, how to do it, automatically edit (shell + ed scripts),
which took many hours on my poor Pentium 100 box :slight_smile: and test the
resulting compilation (which was also a long process !)

I was forced to modify *all* the makefile, src/CMD/generic/make.mid
in addition to src/CMD/head/linux because the previous makefile sheme
was a little bit rigid. I wonder if it is still the case, and if one
can add a flag in configure option sto use dynamic libraries when
available.

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.

--
Michel Wurtz ENGEES - CEREG
                1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
                Tel: +33 03.88.24.82.45 Fax: +33 03.88.37.04.97

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

3

On Wed, Apr 26, 2000 at 09:52:46AM +0200, Michel Wurtz - ENGEES/CEREG wrote:

About Grass Makefile/Compilation : I once (time of 4.2.0 ?) modified
the makefiles in order to made dynamic libraries (libxxx.so) instead
of static ones (libxxx.a). All the .so files were put in a "lib" directory
at the same level than etc, dev, bin, scripts, ...
The whole binary tree took about one third of the space of the regular
binary distribution. It ran also faster (launch time reduced).
If I remember correctly it took me about 3 or 4 nights to figure
out what to do, how to do it, automatically edit (shell + ed scripts),
which took many hours on my poor Pentium 100 box :slight_smile: and test the
resulting compilation (which was also a long process !)

Dear Michel,

this sounds very promising. What about changing GRASS 5 to
dynamic libraries? Are there any restrictions (beside the
missing time, we all have)?

I was forced to modify *all* the makefile, src/CMD/generic/make.mid
in addition to src/CMD/head/linux because the previous makefile sheme
was a little bit rigid. I wonder if it is still the case, and if one
can add a flag in configure option sto use dynamic libraries when
available.

Michel, it would be great if you could provide these patches!
I hope you still have your old code there to diff against
GRASS 5.

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.

This should be a flag for "configure".

Kind regards

Markus Neteler

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

4

Markus Neteler wrote:

Dear Michel,

this sounds very promising. What about changing GRASS 5 to
dynamic libraries? Are there any restrictions (beside the
missing time, we all have)?

> I was forced to modify *all* the makefile, src/CMD/generic/make.mid
> in addition to src/CMD/head/linux because the previous makefile sheme
> was a little bit rigid. I wonder if it is still the case, and if one
> can add a flag in configure option sto use dynamic libraries when
> available.
Michel, it would be great if you could provide these patches!
I hope you still have your old code there to diff against
GRASS 5.

> 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.
This should be a flag for "configure".

Kind regards

Markus Neteler

Hi!

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.

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'.

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.

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

For programming i think that dynamic libraries are only really useful if
documentation for the functions exists.

The autoconf / configure setup would be a big advance, i will report my
problems (due to problems of the GISGEN/gmake procedure) compiling beta7
on IRIX later.

cu

Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de, A.C.Lange@GMX.net

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

5

> > 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@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@geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 4567
max: 0

6

On Fri, Apr 28, 2000 at 08:53:00AM -0400, Eric Mitchell wrote:
[...]

> 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.

I agree. We should have a package
"GRASS-CORE" or "GRASS-BASE" including *all* libraries.

> 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.

Thanks, Eric,
we stay tuned!

Markus

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

7

Eric Mitchell wrote:

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.

Hi Eric, hi developers,

i was a bit too pessimistic about the GNU tools on IRIX. I verified that
i am able to build shared libraries on IRIX with egcs/libtool.
I don't think that the state of the GNU tools on IRIX is sketchy, gcc
2.8.1 and egcs 2.91 use the IRIX linker and assembler. Only the
deprecated gcc 2.7 used the GNU linker and assembler. SGI changed their
attitude and with IRIX 6.5 standard distribution you get all header
files, linker and assembler, which is IMHO an optimal solution, better
than the GNU binutils, which may interfere with other components of the
system.

Most problems on IRIX are due to the complicated library system: IRIX
supports the old 32bit library format, a new 32bit library format (n32)
and the 64bit library format. There is a complete set of libraries for
each format in lib, lib32 and lib64 respectively. So if you link against
a library you have to give the appropriate flag to the compiler (-32,
-n32/-mabi=n32, -64/mabi=64) and to set the library path (lib, lib32,
lib64) accordingly. There may be problems with older versions of GNU gcc
which compile in the old 32 bit format by default or if you try to link
n32 programs to o32 libraries in the lib-directory used by default.

I compiled Mesa3.2 on IRIX (yes, this is carrying coals to
newcastle...), the configure procedure worked, the libraries are
compiled in n32 format, but put in /usr/freeware/lib. Executables are
ok.

Another problem is that with using libtool compiling will be tied to
gcc/egcs. Has anyone tested if libtool works with the 'native'
compilers?

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

looking forward to that,

many thanks for your effort with autoconf,

Andreas

--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de, A.C.Lange@GMX.net

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