From: Mark Scarborough (mscar-osf@cactus.org)
Date: Tue Nov 05 2002 - 12:35:39 EST
Here is a much overdue Summary for the archives... (Original question at
the end.)
Thanks go to Joe Mario, who is a Tru64 Developer, apparently from the DEC
days. (He still has a @zk3.dec.com email address that some of us
old-timers recognize...)
Anyway, this problem was never really solved, but a satisfactory
work-around was found that has worked fine since.
A couple of relevant (and useful) quotes from Joe:
Joe Mario said:
> You can tell the version of a shared library on Tru64 UNIX with the
> "odump -D libz.so" command. If the library was linked without any
> special version, then the version will be "_null" and it will not
> show up in the odump output. However, if the library was linked with
> the "-set_version <version_string>" flag, then the <version_string>
> will show up in the IVERSION field of the odump output.
>
> There are ways to force the loader to use the libz.so with the older
> version string, but that may lead you into trouble if there were
> api changes in the library.
and
Joe Mario said:
> Based on the loader error message I see in your mail, it looks
> like your applications have linked with /usr/local/lib/libgnorba.so.
> It also looks like when /usr/local/lib/libgnorba.so was built, it
> was linked with a libz.so with a version of "1.0". This can be
> verified with "odump -Dl /usr/local/lib/libgnorba.so".
>
> The libz.so on your system is an older version with a version of
> "_null".
Based on all this information, I was able to figure out how to re-link libz
so that it had multiple valid version numbers internally. That seemed to
make enough difference that things settled down. To do this, I used the
"-set_version <version string>" flag to "ld" when re-linking zlib.
Thanks again, Joe.
Mark
-- Mark Scarborough Lead Unix Admin Broadwing Communications Mark.Scarborough@broadwing.com (mailto:Mark.Scarborough@broadwing.com) On Fri, 06 Sep 2002 15:38:40 -0500, Mark Scarborough <mscar-osf@cactus.org> wrote: > I have a problem on my workstation that has been happening for a while now, > but I've finally had it enough to ask for help. > > (AlphaStation DS10 - T64 v5.1A pk2) > > I think the problem started around the time I upgraded my 'libz' to 1.14 > because of the security hole in 1.13, but I'm not absolutely certain of > that. None of my servers have this problem, but, then again, I don't > install so much "stuff" on them... > > Anyway, here is the problem: I can't run some programs (ever) because I get > a message like this: > > $ xscreensaver-demo > 275333:/usr/local/bin/xscreensaver-demo: /sbin/loader: Fatal Error: object > libz.so from liblist in /usr/local/lib/libgnorba.so has version "1.0", > which does not match the found object: /usr/lib/libz.so (with version > "_null") > > > (This is _not_ limited to xscreensaver - that's just an example.) > > I've tried changing my "LD_LIBRARY_PATH" and even removing it entirely, but > it doesn't help. > > I've tried finding all version of libz.[so|a] on the system and making them > the same and/or getting rid of the old ones. > > I've tried putting the old ones back. > > Nothing seems to help. > > I can no longer run Gnome or KDE and some other apps. It hasn't been a > huge problem, but it's gradually becoming more and more of a pain in the > @ss. > > Thanks in advance for any clues! > > Mark > > > -- > Mark Scarborough > Lead Unix Admin > Broadwing Communications > Mark.Scarborough@broadwing.com (mailto:Mark.Scarborough@broadwing.com) > > >
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:58 EDT