Xymon Mailing List Archive search

Library Errors on Solaris 9

4 messages in this thread

list Vernon Everett · Thu, 21 Feb 2013 09:15:08 +0800 ·
Hi all

Encountered an interesting problem installing my Xymon client on Solaris 9.
I have solved it, but it's interesting enough that I felt it was worth
sharing with the list.
And maybe get some feedback on other approaches.
The client was compiled on Solaris 10, so I was expecting the Solaris
binary compatibility thing to make it all "just work" when I copied the
client to Solaris 9.
But that would be too easy. :-/

Most of the binaries gave this issue.
ld.so.1: /usr/local/xymon/client/bin/msgcache: fatal: *libresolv.so.2*:
version `SUNW_2.2.2' not found (required by file
/usr/local/xymon/client/bin/msgcache)
zsh: killed     /usr/local/xymon/client/bin/msgcache

Looks like *libresolve.so.2* is missing

The library is there
# grep libresolv.so.2 /var/sadm/install/contents
/usr/lib/libresolv.so=./libresolv.so.2 s none SUNWcsl
*/usr/lib/libresolv.so.2* f none 0755 root bin 316552 9398 1268771224
SUNWcsl
/usr/lib/sparcv9/libresolv.so=libresolv.so.2 s none SUNWcslx
/usr/lib/sparcv9/libresolv.so.2 f none 0755 root bin 385952 24889
1268771224 SUNWcslx

And we have the LD_LIBRARY_PATH set correctly.
% echo $LD_LIBRARY_PATH
/opt/svrexp/dvlpr/2.2/lib:/usr/openwin/lib:*/usr/lib*
:/opt/cics/lib:/opt/dcelocal/lib:/opt/encina/lib:.

So I checked to see if there was another issue, and it turns out it can see
libresolv.so.2, but wants a specific version.
# ldd /usr/local/xymon/client/bin/msgcache
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
*        libresolv.so.2 (SUNW_2.2.2) =>   (version not found)*
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmd5.so.1 =>   /usr/lib/libmd5.so.1
        /usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
        /usr/platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1

Then I recalled hearing about the LD_NOVERSION parameter you can set, which
causes the the runtime linker to ignore version requirements.
A bit of reading here also helped.
http://docs.oracle.com/cd/E19963-01/html/819-0690/docinfo.html
I added the following 2 lines to the top of the ~/client/runclient.sh script
*LD_NOVERSION=1
export LD_NOVERSION*
Restarted, and it all worked fine.

Maybe some of the programmer types can provide us with some feedback on the
correctness of this approach, or even provide a better solution, but for
now, it's working.

Regards
     Vernon

-- 
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton
list Ryan Novosielski · Wed, 20 Feb 2013 21:23:17 -0500 ·
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't have a comment on the rest of it, but bear in mind the Solaris
binary compatibility thing means you can run Solaris 8 binaries on 10,
Solaris 9 binaries on Solaris 11, etc. The other way around doesn't
necessarily hold.
quoted from Vernon Everett

On 02/20/2013 08:15 PM, Vernon Everett wrote:
Hi all

Encountered an interesting problem installing my Xymon client on
Solaris 9. I have solved it, but it's interesting enough that I
felt it was worth sharing with the list. And maybe get some
feedback on other approaches. The client was compiled on Solaris
10, so I was expecting the Solaris binary compatibility thing to
make it all "just work" when I copied the client to Solaris 9. But
that would be too easy. :-/

Most of the binaries gave this issue. ld.so.1:
/usr/local/xymon/client/bin/msgcache: fatal: *libresolv.so.2*: 
version `SUNW_2.2.2' not found (required by file 
/usr/local/xymon/client/bin/msgcache) zsh: killed
/usr/local/xymon/client/bin/msgcache

Looks like *libresolve.so.2* is missing

The library is there # grep libresolv.so.2
/var/sadm/install/contents /usr/lib/libresolv.so=./libresolv.so.2 s
none SUNWcsl */usr/lib/libresolv.so.2* f none 0755 root bin 316552
9398 1268771224 SUNWcsl 
/usr/lib/sparcv9/libresolv.so=libresolv.so.2 s none SUNWcslx 
/usr/lib/sparcv9/libresolv.so.2 f none 0755 root bin 385952 24889 
1268771224 SUNWcslx

And we have the LD_LIBRARY_PATH set correctly. % echo
$LD_LIBRARY_PATH 

/opt/svrexp/dvlpr/2.2/lib:/usr/openwin/lib:*/usr/lib*:/opt/cics/lib:/opt/dcelocal/lib:/opt/encina/lib:.
quoted from Vernon Everett

 So I checked to see if there was another issue, and it turns out
it can see libresolv.so.2, but wants a specific version. # ldd
/usr/local/xymon/client/bin/msgcache libresolv.so.2 =>
/usr/lib/libresolv.so.2 *        libresolv.so.2 (SUNW_2.2.2) =>
(version not found)* libsocket.so.1 =>
/usr/lib/libsocket.so.1 libnsl.so.1 =>   /usr/lib/libnsl.so.1 
librt.so.1 =>    /usr/lib/librt.so.1 libc.so.1 =>
/usr/lib/libc.so.1 libdl.so.1 =>    /usr/lib/libdl.so.1 libmp.so.2
=>    /usr/lib/libmp.so.2 libaio.so.1 =>   /usr/lib/libaio.so.1 
libmd5.so.1 =>   /usr/lib/libmd5.so.1 
/usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1 
/usr/platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1

Then I recalled hearing about the LD_NOVERSION parameter you can
set, which causes the the runtime linker to ignore version
requirements. A bit of reading here also helped. 
http://docs.oracle.com/cd/E19963-01/html/819-0690/docinfo.html I
added the following 2 lines to the top of the ~/client/runclient.sh
script *LD_NOVERSION=1 export LD_NOVERSION* Restarted, and it all
worked fine.

Maybe some of the programmer types can provide us with some
feedback on the correctness of this approach, or even provide a
better solution, but for now, it's working.

Regards Vernon

-- "Accept the challenges so that you can feel the exhilaration of
victory" - General George Patton

- -- 
- ---- _  _ _  _ ___  _  _  _

|Y#| |  | |\/| |  \ |\ |  | |Ryan Novosielski - Sr. Systems Programmer
|$&| |__| |  | |__/ | \| _| |user-ae4522577e16@xymon.invalid - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlElhRIACgkQmb+gadEcsb5SbwCg28a6FdFqgkaAcQ6Jgzr5Ejyl
hyUAn0Rr8/9BKFJfStqF8AF+LhJgli7S
=EBht
-----END PGP SIGNATURE-----
list Paul Root · Thu, 21 Feb 2013 14:09:24 +0000 ·
Solaris binary compatibility is guaranteed going up not going down.

Actually, I have libresolv.so.2 on my last few Solaris 9 boxes.

Did you do an "ls -l /usr/lib/libresolv.*"?

Ultimately, you need to compile on Solaris 9, and that will run on Solaris 9 and Solaris 10.
quoted from Vernon Everett


From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Vernon Everett
Sent: Wednesday, February 20, 2013 7:15 PM
To: Xymon mailinglist
Subject: [Xymon] Library Errors on Solaris 9

Hi all

Encountered an interesting problem installing my Xymon client on Solaris 9.
I have solved it, but it's interesting enough that I felt it was worth sharing with the list.
And maybe get some feedback on other approaches.
The client was compiled on Solaris 10, so I was expecting the Solaris binary compatibility thing to make it all "just work" when I copied the client to Solaris 9.
But that would be too easy. :-/

Most of the binaries gave this issue.
ld.so.1: /usr/local/xymon/client/bin/msgcache: fatal: libresolv.so.2: version `SUNW_2.2.2' not found (required by file /usr/local/xymon/client/bin/msgcache)
zsh: killed     /usr/local/xymon/client/bin/msgcache

Looks like libresolve.so.2 is missing

The library is there
# grep libresolv.so.2 /var/sadm/install/contents
/usr/lib/libresolv.so=./libresolv.so.2 s none SUNWcsl
/usr/lib/libresolv.so.2 f none 0755 root bin 316552 9398 1268771224 SUNWcsl
/usr/lib/sparcv9/libresolv.so=libresolv.so.2 s none SUNWcslx
/usr/lib/sparcv9/libresolv.so.2 f none 0755 root bin 385952 24889 1268771224 SUNWcslx

And we have the LD_LIBRARY_PATH set correctly.
% echo $LD_LIBRARY_PATH
/opt/svrexp/dvlpr/2.2/lib:/usr/openwin/lib:/usr/lib:/opt/cics/lib:/opt/dcelocal/lib:/opt/encina/lib:.

So I checked to see if there was another issue, and it turns out it can see libresolv.so.2, but wants a specific version.
# ldd /usr/local/xymon/client/bin/msgcache
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libresolv.so.2 (SUNW_2.2.2) =>   (version not found)
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmd5.so.1 =>   /usr/lib/libmd5.so.1
        /usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
        /usr/platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1

Then I recalled hearing about the LD_NOVERSION parameter you can set, which causes the the runtime linker to ignore version requirements.
A bit of reading here also helped. http://docs.oracle.com/cd/E19963-01/html/819-0690/docinfo.html
I added the following 2 lines to the top of the ~/client/runclient.sh script
LD_NOVERSION=1
export LD_NOVERSION
Restarted, and it all worked fine.

Maybe some of the programmer types can provide us with some feedback on the correctness of this approach, or even provide a better solution, but for now, it's working.

Regards
     Vernon

--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton
list Ryan Novosielski · Thu, 21 Feb 2013 09:47:58 -0500 ·
Are you sure it's version SUN_2.2.2? That is likely the problem.
quoted from Paul Root


From: Root, Paul [mailto:user-76fdb6883669@xymon.invalid]
Sent: Thursday, February 21, 2013 09:09 AM
To: 'Vernon Everett' <user-b3f8dacb72c8@xymon.invalid>; 'Xymon mailinglist' <xymon at xymon.com>
Subject: Re: [Xymon] Library Errors on Solaris 9

Solaris binary compatibility is guaranteed going up not going down.

Actually, I have libresolv.so.2 on my last few Solaris 9 boxes.

Did you do an “ls –l /usr/lib/libresolv.*”?

Ultimately, you need to compile on Solaris 9, and that will run on Solaris 9 and Solaris 10.


From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Vernon Everett
Sent: Wednesday, February 20, 2013 7:15 PM
To: Xymon mailinglist
Subject: [Xymon] Library Errors on Solaris 9

Hi all

Encountered an interesting problem installing my Xymon client on Solaris 9.
I have solved it, but it's interesting enough that I felt it was worth sharing with the list.
And maybe get some feedback on other approaches.
The client was compiled on Solaris 10, so I was expecting the Solaris binary compatibility thing to make it all "just work" when I copied the client to Solaris 9.
But that would be too easy. :-/

Most of the binaries gave this issue.
ld.so.1: /usr/local/xymon/client/bin/msgcache: fatal: libresolv.so.2: version `SUNW_2.2.2' not found (required by file /usr/local/xymon/client/bin/msgcache)
zsh: killed     /usr/local/xymon/client/bin/msgcache

Looks like libresolve.so.2 is missing

The library is there
# grep libresolv.so.2 /var/sadm/install/contents
/usr/lib/libresolv.so=./libresolv.so.2 s none SUNWcsl
/usr/lib/libresolv.so.2 f none 0755 root bin 316552 9398 1268771224 SUNWcsl
/usr/lib/sparcv9/libresolv.so=libresolv.so.2 s none SUNWcslx
/usr/lib/sparcv9/libresolv.so.2 f none 0755 root bin 385952 24889 1268771224 SUNWcslx

And we have the LD_LIBRARY_PATH set correctly.
% echo $LD_LIBRARY_PATH
/opt/svrexp/dvlpr/2.2/lib:/usr/openwin/lib:/usr/lib:/opt/cics/lib:/opt/dcelocal/lib:/opt/encina/lib:.

So I checked to see if there was another issue, and it turns out it can see libresolv.so.2, but wants a specific version.
# ldd /usr/local/xymon/client/bin/msgcache
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libresolv.so.2 (SUNW_2.2.2) =>   (version not found)
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        librt.so.1 =>    /usr/lib/librt.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmd5.so.1 =>   /usr/lib/libmd5.so.1
        /usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
        /usr/platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1

Then I recalled hearing about the LD_NOVERSION parameter you can set, which causes the the runtime linker to ignore version requirements.
A bit of reading here also helped. http://docs.oracle.com/cd/E19963-01/html/819-0690/docinfo.html
I added the following 2 lines to the top of the ~/client/runclient.sh script
LD_NOVERSION=1
export LD_NOVERSION
Restarted, and it all worked fine.

Maybe some of the programmer types can provide us with some feedback on the correctness of this approach, or even provide a better solution, but for now, it's working.

Regards
     Vernon

--
"Accept the challenges so that you can feel the exhilaration of victory"
- General George Patton