Undefined symbol under Sun 4.1.3
2007-12-25 7:58:00
Sun Managers:
When I had Sun 4.1.1, I was able to build xgopher.1.1.GIF package on
my workstation. Last week, we upgraded the OS to Sun 4.1.3, everything is fine,except that I could not build the same xgopher.1.1.GIF package anymore. I got
the following message after I tried "make":
cc -o xgopher xgopher.o list.o util.o misc.o net.o gui.o options.o help.o panel.o save.o text.o error.o cso.o index.o KeyWSink.o -g -lXaw -lXmu -lXt -lXext
-lX11
ld: Undefined symbol
_sin
_cos
_pow
_floor
_get_wmShellWidgetClass
_get_applicationShellWidgetClass
*** Error code 2
make: Fatal error: Command failed for target `xgopher'
Does anyone of you konw what is the problem? Please help, we will appreciate.
==============================================================================
The right answer is:
Add an -lm to the compiling line to solve undefined Math symbol _sin, _cos,
_pow and _floor problem, because they are defined in the library file libm.a.
For symbols, get_wmShellWidgetClass and get_applicationShellWidgetClass, as
suggested by Eckhard R"uggeberg, you could either ignore the error or use
-Bstatic to link static when you build the package ( cc .... -Bstatic -lXmu ..).
==============================================================================
Here is another summary posted by Mr. Judy Russell for the similar problems:
My Question :
Is it possible to compile and run X11 programs with Athena widgets using
the X libraries provided (in $OPENWINHOME/lib) with Sun's OpenWindows 3?
And the Answer is ....
YES!
Details :
I had 2 problems
A Undefined symbols on ld with -lXmu
_get_wmShellWidgetClass
_get_applicationShellWidgetClass
B Kludging around this, my executable segmentation faults
Solutions :
A Undefined symbols
1. someone suggested adding
if (0) {
get_wmShellWidgetClass() ;
get_applicationShellWidgetClass () ;
}
this didn't work for me.
2. a couple people suggested using cc for the ld, rather than gcc,
since gcc sometimes uses its own ld. Apparently our gcc is
installed to use the regular ld, so this didn't help me.
3. several people suggested this workaround
compile the program with " ... -Bstatic -lXmu -Bdynamic ..."
surrounding the libXmu inclusion.
this one works fine for me - no Undefined symbols
4. a couple of people told me about some patches available
from Sun. I didn't bother trying this, since even if they
work for me here, I'm not sure I could convince the sys admin
of the other system I want this to run on to install them.
The patches are :
Patch i.d. Bug i.d.'s O/S Description
---------- -------------------------------------------------------
100512-02 1086793 1086912 1074766
4.1.x OpenWindows 3.0 libXt Jumbo patch
100573-03 1087332
4.1.x OpenWindows 3.0 undefined symbols whenusing shared libXmu
B Sementation fault in the resulting code
While fooling around with this I found that if I compiled and linked
the program using MIT X11R5 includes/libs I got something that ran
under MIT X11R5, but under OpenWindows 3 (with LD_LIBRARY_PATH set
to /usr/lib:$OPENWINHOME/lib) it segmentation faults in the same place
as the executable that is compiled/linked with OpenWindows 3's X
includes/libs. Which presumably means that my "simple" program is
doing something that the OpenWindows 3 server doesn't like. I
removed the section of code at the point where it was crashing
(which was calling XtCreateManagedWidget on a label widget, I believe),
and everything else RUNS! I don't know yet what's wrong with the
code it doesn't like, but since it was non-essential, I'll
continue to work with OpenWindows 3.
===============================================================================
With your help I have solved the compiling time errors, no more Undefined
symbols errors. But I got another problem, a run time error. When I run
"xgopher" I got unrecoverable error: cannot access the main gopher directory.
This was never happened before. I again ask your help. Thanks.
Finally, I like to thank you all for your prompt responses including those
who had the same problem and who just provided a clue. Thanks again.
Fengdao Liu
~~~~~~~~~~~~~~~~~~~~~~~
Comments
Got something to say?
You must be logged in to post a comment.
