[GRASS5] 5.3 shared libraries and other experimental changes

GRASS GRASS developer
,
1

Hello everyone
I made some changes to the 5.3 CVS that are quite experimental and will
probably break some things. However it allows to build the core GRASS
libraries as shared, which hugely reduces the size of the binary
distribution.

Please test it by adding the following option to the configure script:
--enable-gmake=no

This enables the alternate build mechanism, and I made some changes to the
Makefiles and used a more up-to-date version of the SC_CONFIG_CFLAGS macro
from the 5.7 aclocal.m4 (I took the latest from the Tcl CVS). This
SC_CONFIG_CFLAGS seems to have already fixed a lot of the issues discussed
in bug 2232 http://intevation.de/rt/webrt?serial_num=2232&display=History

I also added a section for Cygwin. This does not work currently as there
are problems with circular dependencies and resulting undefined symbols
when compiling libraries. In particular the dig2 and vect libraries had
circular dependencies. I didn't look into this more but it may just be a
compiler/linker flag we need like the "-undefined suppress" on OSX. There
was a new version of the OSX flags in Tcl but I commented this and copied
Markus's tried and tested version instead. Somebody could try changing
these flags just to see what happens if they have time.

r.terraflow doesn't compile properly also as its Gmakefile is non-standard
and the mk/genmake.sed conversion filter doesn't work on it. So it can't
be compiled with the alternate build mechanism.

If you wish to use the alternate build mechanism to build static
libraries, add --enable-shared=no as well. (--enable-shared=yes is the
default).

Feel free to fix up and tidy the changes I have made. Seems to work on
Linux (Red Hat 9) and IRIX (6.2) but I haven't tested anywhere else and
much needs tidied anyway. E.g. generating the makefiles for the alternate
build mechanism only needs to be done once but is done every time the
configure script is run, the way I have left it.

Other changes I made were

1) Change the name of the start-up script to grass53 (also for gmake and
gmakelinks). This is quite an important change and should probably go
higher up in this mail or maybe to the users' list.

2) Make --with-gdal the default as there are now several reports that the
gdalbridge code doesn't work.

3) Re-generate the binary nadgrids datum transformation files when
installing a binary distribution, as these are architecture-specific
files.

(For the alternate build mechanism make must be run from a separate build
directory; for make bindist and make srcdist you need to change back to
the top-level source directory and run make there.)

Something I kind of removed was that with mk/mid.mk.shlib (the old shared
library mechanism) the shared libraries had nice version numbers as part
of the filenames. SC_CONFIG_CFLAGS seems to put version numbers in for
some platforms but not very many. I hope it is all right without them as
the GRASS libraries will all be in their own version-specific
sub-directory anyway.

Please test with ./configure --enable-gmake=no and I would hope to make
this the default before the 5.3.0 release.
I will try to fix any bugs I have introduced with these changes but feel
free to tidy things and help with the Cygwin shared dll problem and
r.terraflow's Gmakefile would be much appreciated as well.

Paul

2

Paul Kelly wrote:

I also added a section for Cygwin. This does not work currently as there
are problems with circular dependencies and resulting undefined symbols
when compiling libraries. In particular the dig2 and vect libraries had
circular dependencies. I didn't look into this more but it may just be a
compiler/linker flag we need like the "-undefined suppress" on OSX.

Unlikely. Windows DLLs are quite different from Unix shared libraries.
In particular, Windows binaries (executables and DLLs) import specific
symbols from specific DLLs; OTOH, Unix binaries don't care where an
imported symbol comes from, so long as it actually gets provided.

AFAICT, the circular dig2/vect dependency must be recent; it doesn't
occur in the last version which I built. There were some circular
dependency issues with the DBMI code, but ISTR that Radim said that he
had fixed that.

3) Re-generate the binary nadgrids datum transformation files when
installing a binary distribution, as these are architecture-specific
files.

Is this related to cross-compilation?

--
Glynn Clements <glynn.clements@virgin.net>

3

On Mon, 5 Jan 2004, Glynn Clements wrote:

AFAICT, the circular dig2/vect dependency must be recent; it doesn't
occur in the last version which I built. There were some circular
dependency issues with the DBMI code, but ISTR that Radim said that he
had fixed that.

Well I *think* that's what the problem was; I didn't have a good look at
it as I'd already spent time on other things. Perhaps it is not as bad as
that and just needs the compile re-ordered or something.

> 3) Re-generate the binary nadgrids datum transformation files when
> installing a binary distribution, as these are architecture-specific
> files.

Is this related to cross-compilation?

Yes---that would be the situation where you'd need to generate the files
upon installation to the target machine. We talked about this before---I
hope that is a satisfactory way to get around it.

4

Paul Kelly wrote:

> AFAICT, the circular dig2/vect dependency must be recent; it doesn't
> occur in the last version which I built. There were some circular
> dependency issues with the DBMI code, but ISTR that Radim said that he
> had fixed that.

Well I *think* that's what the problem was; I didn't have a good look at
it as I'd already spent time on other things. Perhaps it is not as bad as
that and just needs the compile re-ordered or something.

Sorry, my mistake. I was looking at the "ldd" output, which doesn't
show circular dependencies. However, examining the "nm" output
indicates that there is indeed a circular dependency, specifically
that dig2 requires V2_read_line in three files:

  chk_inside.o: U V2_read_line
  find_area.o: U V2_read_line
  point_t_line.o: U V2_read_line

This isn't an issue on Unix, so long as any binary which links against
libdig2 also links against libvect. It is an issue for Windows DLLs.

Can anyone provide a quick summary of the relationship between libdig2
and libvect?

> > 3) Re-generate the binary nadgrids datum transformation files when
> > installing a binary distribution, as these are architecture-specific
> > files.
>
> Is this related to cross-compilation?
>

Yes---that would be the situation where you'd need to generate the files
upon installation to the target machine. We talked about this before---I
hope that is a satisfactory way to get around it.

Yes, although the same issue also applies to src/fonts/for_grass.

--
Glynn Clements <glynn.clements@virgin.net>

5

Paul Kelly wrote:

Feel free to fix up and tidy the changes I have made. Seems to work on
Linux (Red Hat 9) and IRIX (6.2) but I haven't tested anywhere else and
much needs tidied anyway. E.g. generating the makefiles for the alternate
build mechanism only needs to be done once but is done every time the
configure script is run, the way I have left it.

This didn't sink in the first time I read it.

I don't think that configure should do this. If you want to eliminate
the need for the "mk/mkmakefiles" step, it would be better to add the
"makefiles" target to the list of dependencies for the "all" target in
the Makefile. That way, re-creating the makefiles can be skipped by
specifying an explicit list of targets when running "make".

Also, if you wait until the top-level Makefile has been built, you can
use the rule:

%/makefile: %/Gmakefile
  sed -f ${SRCDIR}/mk/genmake.sed < $< > $@

to only build the makefile if it doesn't exist or if the Gmakefile has
changed. I.e. instead of running:

  sed -f ${SRCDIR}/mk/genmake.sed < $$dir/Gmakefile > $$dir/makefile

for each value of $dir, run:

  ${MAKE} $$dir/makefile

Or maybe it's time to finally abandon the use of gmake5 and just
require GNU make?

--
Glynn Clements <glynn.clements@virgin.net>