Okay, corrected I stand. Although I *suspect* this problem could be
corrected too. The library is coming in via the libc, not via the
application pulling it in directly. (So if the relevant 4lib libraries
were compiled to use normal libc, or got the important bits of libucb
linked in directly, then wouldn't that resolve the main concern here?)
- Garrett
Peter Tribble wrote:
> On Thu, Oct 8, 2009 at 3:14 PM, Garrett D'Amore <gdamore at sun.com> wrote:
>
>> Actually, looking at the code, I don't see how /usr/ucblib is used by 4.x
>> *binaries*. I.e. if you have a SunOS 4.x binary, it looks like you get the
>> libraries in /usr/4lib, using the a.out exec module. I don't think you wind
>> up using any of the ELF stuff in /usr/ucblib.
>>
>
> % ldd /usr/4lib/libc.so.1.9
> libucb.so.1 => /usr/ucblib/libucb.so.1
> libc.so.1 => /lib/libc.so.1
> libnsl.so.1 => /lib/libnsl.so.1
> libsocket.so.1 => /lib/libsocket.so.1
> libelf.so.1 => /lib/libelf.so.1
> libmp.so.2 => /lib/libmp.so.2
> libmd.so.1 => /lib/libmd.so.1
> libscf.so.1 => /lib/libscf.so.1
> libdoor.so.1 => /lib/libdoor.so.1
> libuutil.so.1 => /lib/libuutil.so.1
> libgen.so.1 => /lib/libgen.so.1
> libm.so.2 => /lib/libm.so.2
> /platform/SUNW,T5140/lib/libc_psr.so.1
> /platform/SUNW,T5140/lib/libmd_psr.so.1
>
> % dump -Lv /usr/4lib/libc.so.1.9
>
> /usr/4lib/libc.so.1.9:
>
> **** DYNAMIC SECTION INFORMATION ****
> .dynamic:
> [INDEX] Tag Value
> [1] NEEDED libucb.so.1
> [2] NEEDED libc.so.1
> [3] NEEDED libnsl.so.1
> [4] NEEDED libsocket.so.1
> [5] INIT 0x42f7c
> [6] FINI 0x42f90
> [7] SONAME libc.so.1.9
> [8] RUNPATH /usr/ucblib
> [9] RPATH /usr/ucblib
> ...
>
> It's definitely pulling libucb in.
>
>
