[GRASS5] how to minimize dependencies in GRASS binaries - with specific application to Mac OS X systems

[Glynn Clements]

Scott Mitchell wrote:

> I think that the problem in the example depicted below was because the 
> GNU internationalization libraries are referred to in GRASS, and on our 
> compilation systems, it found them in the fink directories.

Right; that one is a configure bug; it shouldn't be trying to detect
libintl unless you use the --with-nls switch. Note that it doesn't
actually *use* this library unless you use --with-nls, but it does get
added to the list of libraries to link against, resulting in an
unnecessary dependency.

I'll commit a fix for that.

> I will ignore for now one issue that I'm pretty sure about:  this 
> particular library is probably only needed if you were compiling in the 
> alternate language support, which I'm pretty sure right now is only 
> done for Russian,

That is correct.

> I think that if the compilation of this binary package had used static 
> libraries instead of dynamic, then this problem would not have come up 
> because the required functions would have been compiled into the GRASS 
> binary modules.

That is also correct.

However, you can't easily specify that specific libraries should be
linked statically. You can specify that everything is linked
statically with the -static switch (at least with GNU ld; I'm not sure
about the MacOSX linker), but that is far from ideal.

The easiest way to force specific libraries to be linked statically is
to ensure that only static versions of those libraries exist on the
system.

BTW, with GNU ld, you can just put the static libraries in a separate
directory, and ensure that directory comes first in the library search
path. However, this doesn't work with the MacOSX linker. While both
linkers prefer dynamic libraries over static libraries, GNU ld gives
greater priority to the directory search path, and only uses
shared-vs-static as a "tie-breaker", whereas the MacOSX linker does it
the other way around.

> This would get rid of some of the specific issue, but 
> would potentially make the binary distribution much bigger.

You could use static versions of "non-core" libraries which are only
used by a small number of programs (e.g. PNG, JPEG, FFTW etc) without
substantially increasing the size.

Having said that, probably the largest "bloat" issue comes from using
a static version of libgis. And if libgis was built as a shared
library, you could link that against static zlib and RPC libraries.

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