[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

960827: XDR problems

>From: Don Garber <address@hidden>
>Organization: Analytical Services & Materials, Inc.
>Keywords: 199608272318.AA21107 netCDF Sun Solaris 2.5

Don,

>I built netcdf-2.4.3 and it apparently survived all of the self tests.
>When I tried to compile and link a FORTRAN program, however, I got a
>series of messages that look like:
>
>Undefined        first referenced
> symbol              in file
>xdr_float       /home1/garber/netcdf-2.4.3/lib/libnetcdf.a(cdf.o)
>xdr_int         /home1/garber/netcdf-2.4.3/lib/libnetcdf.a(array.o)
>xdr_vector      /home1/garber/netcdf-2.4.3/lib/libnetcdf.a(sharray.o)
>xdr_u_long      /home1/garber/netcdf-2.4.3/lib/libnetcdf.a(array.o)
>xdr_double      /home1/garber/netcdf-2.4.3/lib/libnetcdf.a(cdf.o)
>xdr_long        /home1/garber/netcdf-2.4.3/lib/libnetcdf.a(dim.o)
>xdr_opaque      /home1/garber/netcdf-2.4.3/lib/libnetcdf.a(array.o)
>ld: fatal: Symbol referencing errors. No output written ... etc
>
>When asked politely (uname -a), my system thinks it is:
>
>     SunOS albedo 5.5 Generic sun4m sparc SUNW,SPARCstation-10
>
>I saved all manner of log files and can send them to you if you wish
>but I thought you might have seen this before and I don't want to
>flood you with information until it is proved necessary.
>
>Two more things:
>
>     1. It (the FORTRAN program) links and runs just fine with
>        netcdf-2.3.2
>     2. I am not a computer systems expert by a very wide margin,
>        so please be gentle.
>
>I would appreciate any help that you can give me.

The entry points listed as Undefined symbols above should be contained in
the /usr/lib/libnsl.a library.  

Here is a snippit from an 'nm' of libnsl.a on our Solaris system:

Symbols from libnsl.a[xdr_array.o]:
 
[Index]   Value      Size    Type  Bind  Other Shndx   Name
 
[1]     |         0|       0|FILE |LOCL |0    |ABS    |xdr_array.c
[2]     |         0|       0|SECT |LOCL |0    |4      |
[3]     |         0|       0|SECT |LOCL |0    |5      |
[4]     |         0|       0|SECT |LOCL |0    |6      |
[5]     |         0|       0|SECT |LOCL |0    |3      |
[6]     |         0|       0|SECT |LOCL |0    |2      |
[7]     |         0|       0|NOTY |GLOB |0    |UNDEF  |free
[8]     |         0|       0|NOTY |GLOB |0    |UNDEF  |xdr_u_int
[9]     |         0|     312|FUNC |GLOB |0    |2      |xdr_array
[10]    |         0|       0|NOTY |GLOB |0    |UNDEF  |malloc
[11]    |         0|       0|NOTY |GLOB |0    |UNDEF  |memset
[12]    |       312|      80|FUNC |GLOB |0    |2      |xdr_vector
[13]    |         0|       0|NOTY |GLOB |0    |UNDEF  |.umul
[14]    |         0|      25|OBJT |GLOB |0    |3      |mem_err_msg_arr
[15]    |         0|       0|NOTY |GLOB |0    |UNDEF  |syslog

You should make sure that you include this library when linking your program.

Tom Yoksas

>From address@hidden Wed Aug 28 04:54:07 1996
>Thanks, it worked.  I had tried libc.a because of some words in the xdr
>subdirectory, but gave up when it didn't work.  Now that I know the answer,
>I checked the configure log file and found

>     checking for xdr_long in -lnsl... yes

>which is the clue I missed.  It was late, I was going blind from peering at
>the screen for hours, I am not knowledgeable about UNIX systems, and many
>other feeble excuses.
>One other thing.  That was an amazingly fast response and I really appreciate
>it.
>Don Garber (address@hidden)