Joerg Schilling wrote:
> "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?)
>>
>
> You then break at least stdio and readdir() that uses different physical
> structure layout.
>
No, they still use the 4lib version of libc. Today the dependency tree
looks like
"app" --> 4lib/libc -+-> ucblib/libucb -->lib/libc
| ^
+---------------+
What I'm proposing is that the ucblib/libucb component could be
collapsed into 4lib/libc. So that you'd just have:
"app" --> 4lib/libc --> lib/libc
This would allow true 4.x a.out binaries to just keep working, while
removing the external ucblib/ components. (The way to achieve this
would just to be to statically link libucb into 4lib/libc.)
It's quite possible that this is all just a vain effort to tilt at
windmills, but I at least wanted to have the *discussion*. This seemed
like a rare opportunity to have such a discussion. If we deliver
Solaris.next with these components, then its likely that another
opportunity to discuss it might not come along for a *long* time.
If the end result is a denial of this case, I won't be seeking an
appeal, but at least we'll have recent case history stating *why* we
have to keep these bits around ~forever more.
-- Garrett
