Very Computer

Legato provides a 32-bit NMO (Network Module for Oracle) which contains:

  /usr/lib/libnwora.so

Legato also provides a 64-bit NMO which contains 64-bit library but
it gets installed in the same place:

  /usr/lib/libnwora.so

I have both 32-bit and 64-bit Oracle running on the same box, so
I need both library installed.

I tried to rename 64-bit libnwora.so to libnwora64.so, but this
does not work. When linked to this library, Oracle still looks
for libnwora.so, and then get the 32-bit version.

What is the right place that I should to use to install 64-bit libnwora.so?
I would like to avoid using LD_LIBRARY_PATH as much as I can.

I noticed that Solaris has /usr/lib/32 and /usr/lib/64 but
Solaris binaries uses /usr/lib only. How Solaris binaries find the
library of the right bitness?

Thanks.
--

Why pay $35 for a domain only if you can get domain and hosting at

The binaries are ELF binaries; their library paths are included within the
binary:

[sbin]$ ldd named
        liblwres.so.1 =>         /usr/sfw/lib/liblwres.so.1
        libdns.so.8 =>   /usr/sfw/lib/libdns.so.8
        libcrypto.so.0.9.6 =>    /usr/lib/64/libcrypto.so.0.9.6
        libisccfg.so.0 =>        /usr/sfw/lib/libisccfg.so.0
        libisccc.so.0 =>         /usr/sfw/lib/libisccc.so.0
        libisc.so.4 =>   /usr/sfw/lib/libisc.so.4
        libnsl.so.1 =>   /usr/lib/64/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/64/libsocket.so.1
        libpthread.so.1 =>       /usr/lib/64/libpthread.so.1
        libthread.so.1 =>        /usr/lib/64/libthread.so.1
        libc.so.1 =>     /usr/lib/64/libc.so.1
        libdl.so.1 =>    /usr/lib/64/libdl.so.1
        libmp.so.2 =>    /usr/lib/64/libmp.so.2
        librt.so.1 =>    /usr/lib/64/librt.so.1
        libaio.so.1 =>   /usr/lib/64/libaio.so.1
        libmd5.so.1 =>   /usr/lib/64/libmd5.so.1
        /usr/platform/SUNW,Ultra-1/lib/sparcv9/libc_psr.so.1
        /usr/platform/SUNW,Ultra-1/lib/sparcv9/libmd5_psr.so.1

Complain to Legato then, there is really no excuse for this.

Quote:> I tried to rename 64-bit libnwora.so to libnwora64.so, but this
> does not work.

Nor would one expect it to work. If you rename some arbitrary
library from foo.so to bar.so, you would not expect a binary that
depends on foo.so to keep on working, would you?

Quote:> I would like to avoid using LD_LIBRARY_PATH as much as I can.

Until Legato fixes their code, your choices are LD_LIBRARY_PATH
(if that works; it may not), patching the binary that performs
the actual load of libnwora.so or a chroot(1)ed environment.

Of these, LD_LIBRARY_PATH appears to be the lesser evil.

Quote:> I noticed that Solaris has /usr/lib/32 and /usr/lib/64 but
> Solaris binaries uses /usr/lib only. How Solaris binaries find the
> library of the right bitness?

Obviously they don't *just* use /usr/lib, or else what would
be the point of having /usr/lib/64 ?

The way is this works is this: when you compile an executable
in 64-bit mode, compiler passes special flags to the linker:

  -L /usr/lib/64 -R /usr/lib/64

the first tells the linker itself where to look for libraries.
The second gets encoded into the executable, and runtime loader
ld.so uses it to locate (proper) libraries at run-time.

You can examine the RPATH encoded into an exe with (GNU)
"objdump -p", or (Solaris) elfdump(1).

Cheers,
--
In order to understand recursion you must first understand recursion.

It should be moved to:

        /usr/lib/sparcv9/libnwora.so

Quote:>I noticed that Solaris has /usr/lib/32 and /usr/lib/64 but
>Solaris binaries uses /usr/lib only. How Solaris binaries find the
>library of the right bitness?

64 bit libraries use /usr/lib/sparcv9 but most binaries are
32 bits.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Quote:>> I tried to rename 64-bit libnwora.so to libnwora64.so, but this
>> does not work.

>Nor would one expect it to work. If you rename some arbitrary
>library from foo.so to bar.so, you would not expect a binary that
>depends on foo.so to keep on working, would you?

It is not like that. What we are supposed to do is:

cd $ORACLE_HOME/lib
rm libobk.so
ln -s /usr/lib/libnwora.so libobk.so

cd $ORACLE_HOME/lib64
rm libobk.so
ln -s /usr/lib/libnwora.so libobk.so

The first /usr/lib/libnwora.so is the 32-bit library, and
the second is 64-bit library. Obviously, they can be in
the same place. So I tried to rename 64-bit libnwora.so to
libnwora64.so, and did

ln -s /usr/lib/libnwora64.so libobk.so

But this did not work. After relink the Oracle executables, Oracle
still looks for libnwora.so (instead of libnwora64.so as I thought),
and find the 32-bit libnwora.so. I do not how this happens, is there
something inside the library that says "I am libnwora.so"?

Thanks.

That's prbably because you did something like:

  -L $ORACLE_HOME/lib64 -lobk

and the loader followed symbolic link, and found
/usr/lib/libnwora64.so (just like you wanted it to), but that library
has DT_SONAME set to libnwora.so, and that name got encoded into
your executable [you can verify my guesses with objdump/elfdump] ...

If so, the workaround is trivial: instead of 'ln -s', just do

   cp /usr/lib/libnwora64.so $ORACLE_HOME/lib64/libnwora.so

and link your executable such that it looks in $ORACLE_HOME/lib64
first:

  cc -Wl,-R,$ORACLE_HOME/lib64 -L$ORACLE_HOME/lib64 ... -lnwora

Cheers,
--
In order to understand recursion you must first understand recursion.

|Is there something inside the library that says "I am libnwora.so"?

Yes.  To see the name recorded in the library run:
        /usr/ccs/bin/elfdump -d /usr/lib/libc.so.1 | grep SONAME

--
________________________________________________________________________


  Working for, but definitely not speaking for, Sun Microsystems, Inc.