Peter Tribble wrote:
> On Thu, Oct 8, 2009 at 3:40 PM, Garrett D'Amore <gdamore at sun.com> wrote:
>
>> 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?)
>>
>
> Well, it would split the /usr/ucblib issue from the SunOS 4 binary
> compatibility issue.
> Which would at least clarify the aim of this case. You would then be
> happy to keep
> the binary compatibility for SunOS 4 in, while breaking compatibility
> for SunOS 5.x
> apps?
>
Only for SunOS 5.x apps that used this legacy compatibility library.
These libraries were never intended to be used with "new" source code.
They were only intended for use with /usr/ucb/cc. But that compiler is
*gone*.
We already have broken the source compatibility, therefore. It really
shouldn't be such a big deal.
> However, investigations on the systems I have access to indicates that
> the problem
> is actually more widespread than I initially imagined.
>
> I am seeing use of /usr/ucblib/libtermcap.so.1 and
> /usr/ucblib/libucb.so.1 on x86,
> and given that this location has only ever seen Solaris 10 on x86 that must
> have
> been due to software built recently. (Not by myself, either, so I may
> have to track
> it down.)
>
Wow. That's really unfortunate. I can only imagine this is fallout
from /usr/ucb/cc being in people's paths. This is a the main reason
I've always advised against having /usr/ucb on your path at all, but
only at the *end* if you absolutely must have it.
These libraries have significant limitations, which is why they
shouldn't be used. (For example, they aren't
thread safe. The signal() implementation is not standard conforming. Etc.)
> On sparc, I can see usage of all the libraries in /usr/ucblib that isn't due
> to
> binary compatibility. (More recent than /usr/4lib, in other words.)
>
Can you help us identify some of the culprits? Are these locally
compiled open source applications? Commercial applications? Or home
grown software?
Would any of these applications be seriously impaired by a requirement
to either recompile "with the right flags", or to use S10 containers?
Its possible that if this problem is as widespread as you claim, then
this case cannot go forward.
- 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.
>>>
>>>
>>>
>>
>
>
>
>
