My original posting:
>> SunOS: 4.1.1
>> Machine: 4/280 SS1+
>> Memory: 32M 28M
>> Swap: 90M 40M
>>
>> Problem:
>> cc/ld core dumps while loading .o modules and X libraries (static).
>> It happens when programs are larger than 200K bytes. There were no
>> problems under 4.0.3.
There are two problems that I had:
1. Sun's "ld" problem. Patches are available. The description is attached.
We tried the new "ld" (1.132 version). It seems to work. We will try
1.135 version when we receive the new libc.
2. The disk is changing bits in the .o files. I am still not sure which
component(s) in the chain. We are getting it fixed.
Thanks for the following who replied:
Jim Mattson <uunet!UCSD.EDU!jmattson>
Mike Raffety <uunet!oddjob.uchicago.edu!oconnor!trinity!miker>
Robert L Krawitz <uunet!Think.COM!rlk>
David Kaelbling <uunet!Rational.COM!drk>
############# Description of bugs and patches for "ld" ######################
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.
############################## END ###########################################
Edward Chien edward@tss.com or uunet!tekbspa!edward
Teknekron Software Systems, Inc.
(415)325-1025
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:11 CDT