Original question:
> Because of an application we had to upgrade our C++ compiler to
>6.0. This requires a newer revision of libcxx.so as we have not
>upgraded to DUnix 4.0D. The kit installs the new one into
>/usr/lib/cmplrs/cxx. This is far from optimal as the application
>contains precopmpiled binaries (which look at /usr/shlib/libcxx.so).
>I know I can work around this by wrapper scripts, but it's ugly,
>tedious, etc. Instead I just moved the new libcxx.so to the standard
>place (/usr/shlib -- of course saving the original libcxx.so).
> Was this a stupid idea? So far nothing seems to be broken. Soon
>the machine will go up to 4.0D (through a scratch install, NOT an upgrade),
>but I don't want to do it right now. We are just not ready for it.
> Will the whole OS blow up? How much of the OS needs libcxx.so? We
>don't run any other 3rd party application, etc.
Thanks to Tom Blinn, it seems to be that upgrading the libcxx.so shared
library is probably safe to do. Probably it will create an unsupported
configuration, but I have no problem with that. Probably there is nothing in
the OS that relies on libcxx.so. I don't know WHY is it in the BASE subset, in
that case, though. Problems may show up with 3rd part applications, but
unlikely as backward compatibility is required. If something shows up,
we will just rebuild those (as we have source code for almost everything
we use).
Gyula
-----------------------------------
> Was this a stupid idea? So far nothing seems to be broken. Soon
> the machine will go up to 4.0D (through a scratch install, NOT an upgrade),
> but I don't want to do it right now. We are just not ready for it.
>
Sounds like a perfectly reasonable thing to do.
> Will the whole OS blow up? How much of the OS needs libcxx.so? We
> don't run any other 3rd party application, etc.
As far as I know, NOTHING in the base OS depends on libcxx.so. But it is in
the OSFBASE subset, so you might break something if you removed it.
However, you should be able to replace the existing version with a newer one
(but not necessarily with an older one) without breaking applications or any
other base components, since shared libraries are REQUIRED to be compatible
in almost every case. (There is a way to "version" shared libraries, but it
isn't pretty, and it's rarely used if it can be avoided.)
Of course, as a test, you could move your libcxx.so aside and see whether
you can see anything that's broken.
By the way, in the standard system setup:
/usr/lib/cmplrs -> ../ccs/lib/cmplrs
and in /usr/ccs/lib/cmplrs/cxx
libcxx.a -> ../../libcxx.a
libcxx.so -> ../../../../shlib/libcxx.so
which is really /usr/shlib/libcxx.so
which is where you said you put the software.. Gee..
Tom
Received on Sat Sep 19 1998 - 21:54:10 NZST