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

Scott_W_Mitchell1 · December 19, 2002, 4:54pm

Short version: how come my grass 5.0.1-cvs compile on solaris can't find the socket functions ? Is it related to warnings about wide character functions being redefined when compiling the grass libes ?

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

/dat0/smitch/grass5src/src/display/devices/CELL
make -f OBJ.sparc-sun-solaris2.8/make.rules

make[1]: Entering directory `/dat0/smitch/grass5src/src/display/devices/CELL'
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)
accept /dat0/smitch/grass5src/src/libes/LIB.sparc-sun-solaris2.8/libgis.a(unix_socks.o)
bind /dat0/smitch/grass5src/src/libes/LIB.sparc-sun-solaris2.8/libgis.a(unix_socks.o)
listen /dat0/smitch/grass5src/src/libes/LIB.sparc-sun-solaris2.8/libgis.a(unix_socks.o)
connect /dat0/smitch/grass5src/src/libes/LIB.sparc-sun-solaris2.8/libgis.a(unix_socks.o)
ld: fatal: Symbol referencing errors. No output written to /dat0/smitch/grass5src/dist.sparc-sun-solaris2.8/driver/CELL
collect2: ld returned 1 exit status
make[1]: *** [/dat0/smitch/grass5src/dist.sparc-sun-solaris2.8/driver/CELL] Error 1
make[1]: Leaving directory `/dat0/smitch/grass5src/src/display/devices/CELL'
GISGEN failure at STEP: src/display/devices/CELL

I haven't found anything comparable in list archives, hopefully I haven't just missed them with bad searches. I have a feeling that it has to do with the conflicting library versions talked about with regards to the wide character functions, but I didn't find any solutions in there... ?

I don't know if this helps or not, but through an accidental fluke I discovered that if I go into the particular module source directory and run gmake5, the module WILL compile successfully. BUT then I realized that the gmake5 that gets found in the path is from the 5.0.0 compile, and the 5.0.0 source tree it refers to is still there. The only difference in the head files in these two trees is the section referring to curses, which I don't THINK is applicable, so I guess it's the different compiled libraries that it gets linked against. Which lead me back to thinking it was an issue with the wide character warnings.

So - anyone else compiling under Solaris 8 ? What compilers/libs/patches ?
Do these errors mean anything more to anyone ?

I've tried with gcc (found by default by configure) and cc - the Sun devel stuff installed on both machines I've tried are from the Sun Forte suite version 6. I just tried applying all sorts of Sun patches, and got no change.

Thanks for any suggestions.

Scott Mitchell

Eric_G_Miller · December 20, 2002, 3:50am

On Thu, Dec 19, 2002 at 11:54:05AM -0500, Scott W Mitchell wrote:

Short version: how come my grass 5.0.1-cvs compile on solaris can't
find the socket functions ? Is it related to warnings about wide
character functions being redefined when compiling the grass libes ?

[snip]

It then builds the libraries, apparently successfully, but with lots of
warnings about the wide character functions (putwc, getwc, etc) being
redefined. 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)

Well, it's apparently a link error. I vaguely recall some platform
needed -lsocket (for libsocket) as a linker argument. You'll need
to find out what library provides the socket functions (apparently
the C library doesn't?).

--
"...the plural of anecdote is [not?] data." - attrib. to George Stigler

Glynn_Clements · December 20, 2002, 1:06pm

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@virgin.net>

Scott_W_Mitchell1 · December 20, 2002, 1:41pm

OK, thanks again to you, and to Eric Miller, that was indeed all that was needed. So I had the sockets library "by accident" last time, but now I've explicitly requested it and the missing modules are compiling.

Cheers,

Scott Mitchell

On Friday, December 20, 2002, at 08:06 AM, Glynn Clements wrote:

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