Patch-ID# 100170-02
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 *1019004

			       *1019004 surfaces a libc bug

Architectures for which this patch is available: sun3 sun4

Patches which may conflict with this patch:

Obsoleted by: 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.132 supersedes 1.128 of the Version 1 patch.

Version 1.133 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.133 contains the fix to #1019004.  The specifics of each version 
follow.

1.132 includes fixes for these bugs:

	1032739: ld core dumps with many libs in multiple directories
	1034788: -r and -pic do not mix bad secondary magic number on...
		 (also includes 1034844 as a side effect.)
		 ** NOTE: the above were previously supplied as the XEROX
		          patch.
	1034833: ld: can't mixed -r with -Bstatic or -A flag in 4.1prefcs...
	1037879: Cannot create executable with shared object which points...
		 (This includes the "fix to the fix" for the new problem
		 that Brown U. reported.)
	1042261: ld only recognized first directory in LD_LIBRARY_PATH
	1044524: multiply defined symbols and seg. fault caused by 4.1's ld
	1045272: ld -u & -r do not seem to work properly

1.133 includes all of the above and in addition includes:

	1019004: -assert definitions can fail to report undefined symbols.

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.133 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.133 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 international-
ization 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


INSTALL:

	1) su as "root"
	2) rename /bin/ld to something else (e.g. /bin/ld.org)
	3) cp <appropriate arch ld> to /bin

The ld "patches" are in fact complete ld's.