SUMMARY - cc/ld problems

From: Edward Chien (tekbspa!edward@uunet.uu.net)
Date: Fri Feb 22 1991 - 14:14:09 CST


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