Re: Binary apps linked against libdl

[Christopher Seawood <cls@seawood.org>]

On 22 Apr 1999, Andreas Jaeger wrote:

> >>>>> Christopher Seawood writes:
> 
>  > with db2 but I've also witnessed this problem with the jdk.  As far as I
>  > can tell, jdk does not call any _dl functions itself (I grepped the code).
>  > It appears as though these symbols are called by libc.so.6.
> jdk 1.1.7 uses calls to internal _dl functions, have a look at the
> blackdown patch.

I should've clarified.  I was testing with the 1.1.6v5 patch from
blackdown.  I don't have access to 1.1.7 src so I can't comment on that.

>  > [root@voltaire install]# LD_LIBRARY_PATH=/usr/glibc2.0/lib
>  > /usr/glibc2.0/lib/ld-linux.so.2 ./db2inst 
>  > sh: /usr/glibc2.0/lib/libc.so.6: no version information available
>  > (required by sh)
> It seems that db2inst is a shell script and was linked against glibc
> 2.1.  You've got to patch the shell script to use the above command
> line when actually calling the binary.

[root@amadeus /usr/src/beta1123/db2/install] file db2inst 
db2inst: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically
linked (uses shared libs), not stripped

[root@amadeus /usr/src/beta1123/db2/install] sh -x ./db2inst 
./db2inst: ./db2inst: cannot execute binary file

As far as I can tell, db2inst is the actual install binary.  db2setup is a
shell script.  I think the sh errors are coming from the db2inst execing
another sh script.  I replaced pdksh with a glibc2.0 version and
changed the /bin/sh link. Now I get the following error:

[root@amadeus /usr/src/beta1123/db2/install] env
LD_LIBRARY_PATH=/usr/glibc2.0/lib:`pwd` /usr/glibc2.0/lib/ld-linux.so.2
./db2inst
sh: /usr/glibc2.0/lib/libc.so.6: no version information available
(required by /lib/libNoVersion.so.1)
sh: error in loading shared libraries: /usr/glibc2.0/lib/libc.so.6:
undefined symbol: _dl_global_scope_end

>  > sh: error in loading shared libraries: /usr/glibc2.0/lib/libc.so.6:
>  > undefined symbol: _dl_global_scope_end

I'm pretty sure that this is part of the problem.  If libc requires libdl,
will it try to load it from the LD_LIBRARY_PATH or use the hardcoded
/lib/libdl.so.2?  I would assume it'd do the former, but it appears to be
doing the latter.

- cls