Missing Symbols in 4.1.2 libraries

2007-12-25 7:41:00

Many many thanks to the net! As usual, I got a solution in less than 24

hours. During that time, I might add, Sun was still scratching it's

technical support head. Here's my original query:

> This is a surprise and I hope it's not a permanent condition.

>

> We have many people here (students, for a class, and faculty) using Sun

> GKS 4.1. They compile programs like this:

>

> cc -I/usr/openwin/include prog.c -o prog -lgks -lxgl -lxview -lolgx -lX11 -lm

>

> With 4.1.1, this worked like a charm. Now that we have upgraded to

> 4.1.2, we get the following link errors:

>

> ld: Undefined symbol

> _i_len

> _f_inqu

> _f_clos

> _s_cmp

> _s_copy

> _s_stop

> _do_l_out

> _e_wsle

> _s_wsle

>

> There is no mention of a problem in the docs with either the XGL library

> or the SunGKS libraries (which we had to install when we installed

> SunGKS). Oh...We use Sun C 1.1.

The reason for this error: There is FORTRAN support built into the Sun

GKS libs -- yes, even for C. A bug in the 4.1.1 version of "ld" caused

compiles under 4.1.1 not to show the fact that these routines were never

resolved. A fixed 4.1.2 "ld" caused these unresolved references to show

up.

Solution/Workaround: There are two possible solutions:

  (1) Compile the GKS programs separately, then link with the "f77"

      command. As in

                 cc -I/usr/openwin/include -c prog.c

                 f77 -o prog prog.o -lgks -lxgl -lxview -lolgx -lX11 -lm

        

           I can't verify that this works. We do not have the "f77" compiler.

      But Doug Neuhauser (doug@perry.berkeley.edu) suggested this fix and

      says it works for him.

  (2) Compile your code with the "-assert nodefinitions" argument to "ld"

      (you can pass it through the "cc" command). This works for us

      fine, but has the undesired side effect of not warning you about

      REAL routines that are unresolved.

  (3) Compile your code using the "-Bstatic" option, which will avoid

      using the shared GKS libraries. This results in a much longer

      compile time and a much bigger object module.

So, choose your poison. I've griped very loudly at Sun -- for whatever

good it'll do.

Thanks to the following folks:

  Doug Neuhauser (doug@perry.berkeley.edu)

  Matt Crawford (matt@oddjob.uchicago.edu)

  Russ Poffenberger (poffen@sj.ate.slb.com)

  Dieter Muller (dworkin@merlin.rootgroup.com)

  Mark Wiederspahn (mark@utig.ig.utexas.edu)

  Mike Raffety (miker@sbcoc.com)

  Mario Migrovic (mario@wdc.sps.mot.com)

  Michael Meystel (meystel@impaqt.drexel.edu)

      Mike Jipping

      Hope College Department of Computer Science

      jipping@cs.hope.edu (BITNET: JIPPING@HOPE)

        

Comments

Got something to say?

You must be logged in to post a comment.