Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.misc -> Re: HPUX 10.20 and Oracle 7.3 shared library errors
Mikkel Lauritsen wrote:
> Oracle 7.3.2.2 supplies both dynamically and statically linked
versions of
> its access libraries. When linking a small example program from Oracle
with
> the static libraries everything works okay, but the dynamically linked
version
> stops cold with a bus error.
>
> I'd say this looks like an error in the dynamic libraries, but since
it seems
> to run okay on Solaris and IRIX chances are that HPUX is partially in
error.
>
> If any of you have experienced similar problems or perhaps have come
up with
> a workaround I'd very much like to know - any suggestions or hints are
most
> welcome.
>
> Thanks in advance,
> Mikkel Lauritsen - ml_at_thevisionfactory.com
>
> - posted from my university account
I'm assuming you're using C on HP-UX. The example I'm about to use
is not an
Oracle linked program, but it will still show you the funky way HP
executables
are linked. BTW, if you look closely at your library list you'll see
that
specifing the use of Oracle 7.32 shared libraries on HP-UX is almost a
joke. I
only saw _one_ Oracle shared library that was ever used - the rest are
still
archive libraries....and it didn't reduce the executable size very much.
1.) When you link a program with shared libraries on the HP it stores
the
library name, it's path and all into the executable.
2.) HP-UX does _NOT_ use the environment variable "LD_LIBRARY_PATH"
(that every
other UNIX uses...) - "SHLIB_PATH" is used instead to look up shared
libraries.
3.) The use of "SHLIB_PATH" is _NOT_ enabled by default. You must
specify it as
a linker option.
HP-UX executables do not support the use of "ldd" to show what shared
libs it is
going to use.
The "chatr" command can show you what is going on. For one of my
programs named
"logview", when I don't specify the appropriate linker option, "chatr"
shows the
following:
chatr logview
logview:
shared executable shared library dynamic path search: SHLIB_PATH disabled second embedded path disabled first Not Defined internal name: bin/logview shared library list: dynamic ./Xbae_ext/lib/libXbae.sl dynamic /usr/lib/libXm.1 dynamic /usr/lib/libXt.1 dynamic /usr/lib/libX11.1 dynamic ./xpm_ext/lib/libXpm.sl dynamic /usr/lib/libc.1 shared library binding: deferred static branch prediction disabled kernel assisted branch predictionenabled lazy swap allocationdisabled text segment lockingdisabled data segment lockingdisabled data page size: 4K instruction page size: 4K
following error when run:
/usr/lib/dld.sl: Can't open shared library: ./xpm_ext/lib/libXpm.sl /usr/lib/dld.sl: No such file or directory Abort(coredump)
Now I change the Makefile to add "-Wl,+s" to the compile line. The
"-Wl,"
says to the compiler to pass the "+s" to the linker at the link stage.
If you
read the "ld" man page, you'll see that "+s" enables the use of the
SHLIB_PATH
environment variable for shared library lookups. Running "chatr"
against
"logview" now shows:
./logview:
shared executable shared library dynamic path search: SHLIB_PATH enabled first embedded path disabled second Not Defined internal name: bin/logview shared library list: dynamic ./Xbae_ext/lib/libXbae.sl dynamic /usr/lib/libXm.1 dynamic /usr/lib/libXt.1 dynamic /usr/lib/libX11.1 dynamic ./xpm_ext/lib/libXpm.sl dynamic /usr/lib/libc.1 shared library binding: deferred static branch prediction disabled kernel assisted branch predictionenabled lazy swap allocationdisabled text segment lockingdisabled data segment lockingdisabled data page size: 4K instruction page size: 4K
I recommend reading the "chatr" and "ld" man pages. I've given a
simplistic
example. Things can get more exotic when you specify absolute paths for
shared
libraries - then you may need to use "chatr" to modify to the executable
to
ensure all shared libs are tagged dynamic.
Hope this makes sense..... I wish that HP had chosen to enable
SHLIB_PATH as a
default......
If you need more info, send me an email.......we've beat this issue
pretty much
to death over here.
r,
Lance S. Nehring
Systems Engineer
U. S. West Communications
<lnehrin_at_uswest.com> Received on Mon Feb 02 1998 - 00:00:00 CST