First thanks to both thakur & mattson who would have been within
seconds of each other if they were in the same time zone.
> From thakur@zerkalo.harvard.edu Thu Mar 28 16:01:14 1991
> From mattson@cs.UCSD.EDU Thu Mar 28 16:01:42 1991
I was trying to install GNU emacs-18.57 on a SparcStation II with
SunOS Release 4.1.1 preinstalled. To my surprise I ran into an
undefined symbol referenced in /lib/libc.a and NOT in ANY of the
emacs object files.
The problem was that I had just installed GNU's ld version:
"Thu Mar 7 17:29:09 1991 Mike Haertel (mike at ducky)"
and the makefile was calling ld directly and thus using GNU/ld
instead of SUN/ld. GNU`s ld was correctly reporting that some
of the object files used from libc.a referenced the symbol
__Q_get_rp_rd which is not defined in any of SUN's libraries.
Fortunately the symbol __Q_get_rp_rd while referenced, is apparently
not ever used. This leads to the following workarounds.
Work Arounds:
1) Use SUN's (broken?) /bin/ld which doesn't complain about the
unresolved reference. I've tested this method.
2) Use GNU's ld, but "patch" the /lib/libc.a file with:
One line file ld_hack.c
int _Q_get_rp_rd = 0;
and shell script
#!/bin/sh
# Quick fix "patch" script, by Bill Voss (no rights reserved)
cp -ip /lib/libc.a /lib/libc.a.orig
cc -c ld_hack.c
ar r /lib/libc.a ./ld_hack.o
ranlib /lib/libc.a
# end of script
I have also tested this method.
3) Get SUN patchid 100208-01 (as of 1/22/91) to repair bug 1045471.
I have NOT tested this method.
------------------------------------------------------------------------
For those wishing full details, the two responses are appended.
Thanks again you two.
Bill Voss
------------------------------------------------------------------------
>From thakur@zerkalo.harvard.edu Thu Mar 28 16:01:14 1991
To: Bill Voss <voss@jerry.cs.uiuc.edu>
Subject: Re: Undefined symbol __Q_get_rp_rd
In-Reply-To: Your message of Thu, 28 Mar 91 01:06:55 -0600.
<9103280706.AA07782@jerry.cs.uiuc.edu>
Date: Thu, 28 Mar 91 11:36:11 EST
From: "Manavendra K. Thakur" <thakur@zerkalo.harvard.edu>
>>>>> On Thu, 28 Mar 91 01:06:55 CST, Bill Voss <voss@jerry.cs.uiuc.edu> said:
> Here is the actual output I get from `ld` on machine laslo.
[...]
> symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_add.o)
> symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_sub.o)
> symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_mul.o)
> symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_div.o)
> symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_qtos.o)
> symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_qtod.o)
> symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_sqrt.o)
> /lib/libc.a(_Q_add.o): Undefined symbol __Q_get_rp_rd referenced from text segment
> /lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segment
> /lib/libc.a(_Q_mul.o): Undefined symbol __Q_get_rp_rd referenced from text segment
> /lib/libc.a(_Q_div.o): Undefined symbol __Q_get_rp_rd referenced from text segment
> /lib/libc.a(_Q_qtos.o): Undefined symbol __Q_get_rp_rd referenced from text segment
> /lib/libc.a(_Q_qtod.o): Undefined symbol __Q_get_rp_rd referenced from text segment
> /lib/libc.a(_Q_sqrt.o): Undefined symbol __Q_get_rp_rd referenced from text segment
This means that someone has installed the Jumbo patch (Patch-ID#
100170-03) to ld on your machine.
To get rid of these undefined symbols, you can install Patch-ID#
100208-01. Or you can provide some compile-time flags to suppress the
messages. Here is the relevant information:
=============================================================================
Patch-ID# 100170-03
Keywords: jumbo-patch shared LD_LIBRARY_PATH -Bstatic
Synopsis: SunOS 4.1;jumbo patch to fix various ld problems
Date: 12/7/90
SunOS release: 4.1
Unbundled Product:
Unbundled Release:
Topic: jumbo ld patch
BugId's fixed with this patch: 1034833 1034788 1042261 1045272 1037879
1032739 1044524
1.132 fixes bugs :1034833 1034788 1042261 1045272 1037879
1032739 1044524
1.135 includes all of the above and in addition includes:
1019004: -assert definitions can fail to report undefined
symbols, as well as all follow-on problems relating
to previous alleged fixes for this bug.
Architectures for which this patch is available: sun3 sun4
Patches which may conflict with this patch:
Obsoleted by: SunOS SVR4
Problem Description:
Since this patch is a "jumbo" patch consisting of several fixes including
one fix which, in turn, surfaces another problem whose fix is not available
at this writing, there are two sets of fixes included in this one patch.
Version 1.135 supersedes 1.132, except that to be fully useful it
requires a new shared C library which repairs bug #1045471. The
only difference between them is that 1.135 contains the fix to #1019004.
ADDENDUM! As of 1/22/91, patchid 100208-01 is the new libc needed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
to repair bug 1045471. Please read the remainder of this
note carefully to see if bug 1045471 really pertains to you.
Many applications may be linked with 1.135 without
necessarily being affected by bug 1045471.
The reason for separating 1019004 from the other fixes is that if
you run an "ld" with 1019004, you will run into bug #1045471, which
is a C library bug that has gone unnoticed until now (because of
1019004). You *CAN* use 1.135 without a fix for 1045471, but it may
be annoying to see that the C library tells you there are undefined
symbols. As it happens, it is almost certainly safe to ignore the C
library undefines, but if you're the nervous type you're going to
want a new C library.
If you use ld version 1.135 with the trivial C program;
main() {}
you will get the following undefined symbols;
__Q_get_rp_rd
_dlclose
_dlopen
_dlsym
_nl_langinfo
Symbols _dlclose, _dlopen, _dlsym can be eliminated by explicitly
passing libdl.a to ld (-ldl). nl_langinfo() is a simple query
function dealing with internationalization and it is unknown as
to who __Q_get_rp_rd is. If the application doesn't call the
either the programming interface of the dynamic linker
(_dlopen/_dlclose/_dlsym) NOR the internationalization functions,
then there may be no problem in running with these unresolved symbols.
The messages are a result of applying the '-assert definitions'
switch to ld (the default). If there are ANY other undefined
symbols in addition to the ones above, they are the problem of the
application. If these are the only unresolved symbols found, then
the application itself contributes no unresolved symbols. To build an
a.out without unresolved symbol messages being emitted, use the
'-assert nodefinitions' flag.
e.g. cc ... -assert nodefinitions ... trivial.c
The ld "patches" are in fact complete ld's.
=============================================================================
You can certainly get the patches by contacting Sun support. You may
also be able to ftp the patches. Try ftp.uu.net in /sun-fixes and
also try princeton.edu in /pub/sun-fixes/sunos4.1 or
/pub/sun-fixes/sunos4.1.1.
Hope this helps, and good luck.
Manavendra K. Thakur Internet: thakur@zerkalo.harvard.edu
Systems Programmer, High Energy Division BITNET: thakur@cfa.BITNET
Harvard-Smithsonian Center for DECNET: CFA::thakur
Astrophysics UUCP: ...!uunet!mit-eddie!thakur
===============================================================================
>From mattson@cs.UCSD.EDU Thu Mar 28 16:01:42 1991
To: voss@jerry.cs.uiuc.edu
Subject: Re: Undefined symbol __Q_get_rp_rd
In-Reply-To: Your message of Thu, 28 Mar 91 01:06:55 CST.
<9103280706.AA07782@jerry.cs.uiuc.edu>
Date: Thu, 28 Mar 91 09:36:57 PST
From: Jim Mattson <mattson@cs.UCSD.EDU>
Sounds to me like you are using Gnu's ld. Yes, libc.a does have these
undefined symbols, but the routines that reference them are never used. For
some reason, Gnu ld seems to put them in anyway. Sun's ld does not. (At
least, I have never seen this with Sun's ld). Check your path.
--jim
--------
In reply to the following message:
--------
I'm trying to install GNU emacs-18.57 on a SparcStation II with
SunOS Release 4.1.1 preinstalled. To my surprise I'm running
into an undefined symbol referenced in /lib/libc.a and NOT in
ANY of the emacs object files.
Running strings on /lib/*.a /usr/5lib/*.a shows that __Q_get_rp_rd
is only found in libc.a and libc_p.a. However it is NOT in their
respective __.SYMDEF files, even after running `ar -s` on them.
Here is the actual output I get from `ld` on machine laslo.
laslo% ld -e __start -Bstatic -o temacs -y __Q_get_rp_rd crt0.o dispnew.o s
croll.o xdisp.o window.o term.o cm.o emacs.o keyboard.o macros.o keymap.o sy
sdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filem
ode.o cmds.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc
.o editfns.o callint.o eval.o fns.o print.o lread.o abbrev.o syntax.o unexec.
o mocklisp.o bytecode.o process.o callproc.o doprnt.o tparam.o lastfile.o -l
termcap -lg -lc
symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_add.o)
symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_sub.o)
symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_mul.o)
symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_div.o)
symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_qtos.o)
symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_qtod.o)
symbol __Q_get_rp_rd referenced in /lib/libc.a(_Q_sqrt.o)
/lib/libc.a(_Q_add.o): Undefined symbol __Q_get_rp_rd referenced from text segm
ent
/lib/libc.a(_Q_sub.o): Undefined symbol __Q_get_rp_rd referenced from text segm
ent
/lib/libc.a(_Q_mul.o): Undefined symbol __Q_get_rp_rd referenced from text segm
ent
/lib/libc.a(_Q_div.o): Undefined symbol __Q_get_rp_rd referenced from text segm
ent
/lib/libc.a(_Q_qtos.o): Undefined symbol __Q_get_rp_rd referenced from text seg
ment
/lib/libc.a(_Q_qtod.o): Undefined symbol __Q_get_rp_rd referenced from text seg
ment
/lib/libc.a(_Q_sqrt.o): Undefined symbol __Q_get_rp_rd referenced from text seg
ment
laslo%
This is all using SUN's `cc` compiler, using `gcc` gives similar results.
Ironically I built `gcc` without any problems earlier today, including
the full stage1 stage2 cmp cycle. Despite what "strings lib*.a | grep"
reported, I also did try adding the math library with no effect.
Anyone seen this before?
Anyone have any suggestions? (other than learning vi ;-)
Bill - desperate for my editor - Voss <voss@jerry.cs.uiuc.edu>
-- Yes I'll send a SUMMARY.--------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:12 CDT