[GRASS5] Can't compile CVS version on solaris 8 - undefined symbols

[Glynn Clements]

Scott W Mitchell wrote:

> Short version:  how come my grass 5.0.1-cvs compile on solaris can't  
> find the socket functions ?

The most probable cause is that the socket functions aren't in libc,
but in some other library. A library which was previously being linked
by coincidence, but isn't any more. The build mechanism doesn't have a
specific symbol, e.g. $(SOCKETLIB), for socket-using code, so if the
socket functions aren't in libc, you just have to hope that the
necessary libraries get linked in for some other reason (e.g. due to
$(XDRLIB)).

> Is it related to warnings about wide  
> character functions being redefined when compiling the grass libes ?

Probably not. That normally suggests a conflict between vendor and GNU
header files, although sometimes that can be caused by specifying
/usr/include as an include directory (--with-*-includes); don't do
that.

> Long version:
> 
> I have been doing periodic cvs updates on 5.0.1-cvs source code, and  
> all is well on my linux and macosX machines.  But I can't get a  
> successful compile out of a solaris machine, unfortunately.  The  
> released version of 5.0.0 compiled fine back in September, and that is  
> still installed on our machines, so I have a working distribution.  But  
> I'd like to figure out what's preventing any updates.
> 
> Hopefully this is just something strange on our machines and won't slow  
> down Markus' Christmas 5.0.1 aspirations ! :)
> 
> I start with getting through the configure step by setting CPPFLAGS to  
> -w to get past the curses check, as found in advice by Glynn in the  
> mailing list archives.
> 
> It then builds the libraries, apparently successfully, but with lots of  
> warnings about the wide character functions (putwc, getwc, etc) being  
> redefined.

Look at which header files the errors are actually occurring in.

> Then when it gets to actual modules, a huge number of them  
> don't get compiled, complaining about missing symbols.  All the ones  
> that I've looked into are complaining about sockets (unix_socks)
> 
> For example, the first failure is in the CELL driver, and this is what  
> happens:

> > gcc -L/dat0/smitch/grass5src/src/libes/LIB.sparc-sun-solaris2.8  -o  
> > /dat0/smitch/grass5src/dist.sparc-sun-solaris2.8/driver/CELL  
> > OBJ.sparc-sun-solaris2.8/bresline.o OBJ.sparc-sun-solaris2.8/file_io.o  
> > OBJ.sparc-sun-solaris2.8/polyfill.o OBJ.sparc-sun-solaris2.8/Can_do.o  
> > OBJ.sparc-sun-solaris2.8/Color.o OBJ.sparc-sun-solaris2.8/Draw_line.o  
> > OBJ.sparc-sun-solaris2.8/Get_w_box.o  
> > OBJ.sparc-sun-solaris2.8/Get_w_line.o  
> > OBJ.sparc-sun-solaris2.8/Get_w_pnt.o  
> > OBJ.sparc-sun-solaris2.8/Graph_Clse.o  
> > OBJ.sparc-sun-solaris2.8/Graph_Set.o OBJ.sparc-sun-solaris2.8/Panel.o  
> > OBJ.sparc-sun-solaris2.8/Polygn_abs.o  
> > OBJ.sparc-sun-solaris2.8/Reset_clr.o -ldriver -lgis  -lm  -lnsl    -lz
> > Undefined                       first referenced
> >  symbol                             in file
> > socket                               
> > /dat0/smitch/grass5src/src/libes/LIB.sparc-sun-solaris2.8/ 
> > libgis.a(unix_socks.o)

You need to find out which library contains "socket" etc and add it to
LDFLAGS, e.g.

	LDFLAGS=-lsocket ./configure ...

There should really be configuration variables for socket functions;
they can't be assumed to exist or to be available without additional
switches. This would mean that code which wanted to use socket
functions would have to reference additional variables in the
Gmakefile in order to add the correct compile/link switches.

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