[GRASS5] Error building 5.1 CVS head on Solaris 8 sparc <solved>

[Glynn Clements]

Radim Blazek wrote:

> > In order to complete a build of grass51 CVS head on Solaris 8 Sparc I had
> > to make the following changes:
> >
> > 1) Remove "$(SOCKLIB) $(INTLLIB)" from the definition of GISLIB in
> > Grass.make.in. This was causing the "No rulle to make target" errors.
> 
> We should probably remove $(SOCKLIB) from GISLIB and use it only in 
> Makefiles of modules using this library.

libgis itself uses socket functions (unix_socks.c). If libgis is built
as a shared library, any program which requires libgis requires
$(SOCKLIB); if libgis is built as a static library, only those
programs or libraries which use the socket functions (e.g. libraster,
all d.* programs, display drivers) will need $(SOCKLIB).

> $(INTLLIB) - I don't know where is the right place for this, 
> Makefile of each module? 

Now that libgis itself has been internationalised, any program which
uses libgis (i.e. everything) needs $(INTLLIB).

> Real problem causing above error is that GISLIB is used somewhere
> in Makefile as dependency, can you tell us where it is?

The real problem is that the 5.1 build system uses a single set of
library variables (e.g. $(GISLIB)) for two separate purposes:

1. As the path to the library file itself, either as a target or as a
dependency.

2. As the command line arguments which are required for linking
programs which use the library.

The 5.0 build system has two separate variables for each library,
e.g.:

	DEPGISLIB      = $(LIBDIR)/libgis.a
	GISLIB         = -lgis $(SOCKLIB) $(INTLLIB)

	...

The DEP*LIB forms are suitable for use as both targets, e.g.:

	$(DEPGISLIB): $(LIBOBJS)

and as dependencies, e.g.:

	$(BIN_CMD)/$(PGM): $(OBJS) $(DEPGISLIB)

The *LIB forms are suitable for use as linker switches, e.g.:

	$(CC) $(LDFLAGS) -o $@ $(OBJS) $(GISLIB)

This distinction is necessary for two reasons:

1. So that you can have a single variable which provides all of the
necessary flags for linking against a library (including the library's
dependencies as well as the library itself). If you don't do this,
every Makefile which uses the library has to include all of the
libraries dependencies; if a library acquires a new dependency, you
have to change all of the individual Makefiles.

2. So that shared libraries can be used correctly. To correctly link
against a shared library, you have to use "-lfoo"; a pathname won't
work correctly (e.g. it will result in an executable which depends
upon the library's build-time pathname, which probably won't be where
the library ends up).

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