When is a shared library not a shared library?

When is a shared library not a shared library?

Post by l.. » Tue, 14 Jan 1997 04:00:00



(As a preamble, I should mention I've read the Linux FAQ, the ELF
 FAQ, and the GCC FAQ on the subject of shared libraries.  I now
 think I understand shared libraries under Linux reasonably well, but I
 can't say I understand my problem at all!)

A few days ago, I started playing about with Tcl/Tk on my Linux
system.  I compiled and installed tk4.1a2 and tcl7.5a2, with no
problems.

Then I thought I'd try out some gui builders. Well, of course
neither guiBuilder nor xf2.3 worked, since they wanted _old_
versions of Tk/Tcl.  Sad, but I've come to expect that of Tk/Tcl.

But the whizz-bang SpecTcl (v. 0.1a) lead to a weirder problem.

Basically, I couldn't get my system to believe that various
shared libraries needed, were actually shared libraries!  Here's
some detailed info:

    I'm running Linux 1.2.13:

    # uname -a
    Linux genius 1.2.13 #18 Sun Oct 20 17:42:47 GMT 1996 i486

    The version of libc is 4.5.26

    # ls -l /lib/libc.so.4
    lrwxrwxrwx   1 root     system         14 May 17  1996 /lib/libc.so.4 ->
            libc.so.4.5.26*

    gcc is 2.6.3:

    # gcc --version
    2.6.3

Now, I compiled up the following shared library myself, on the above
system - so I'm pretty sure it really _is_ a shared library!  I used
the -fPIC option for position-independent-code, and linked with -shared
to produce the table geometry manager Blt.so.

I copied this into /usr/local/lib and made a symbolic link to Blt.so.7.5
And here's the interesting bit:

    # file /usr/local/lib/Blt.so
    /usr/local/lib/Blt.so: ELF 32-bit LSB shared object, Intel 80386, \
        version 1

So it's a shared library, I take it.  But that's not what the shared
library tools say!

    # ldconfig -l -v /usr/local/lib/Blt.so
    ldconfig: version 1.7.0
    ldconfig: /usr/local/lib/Blt.so is not a shared library

Here's another, just like it:

    # file /usr/local/lib/libtcl*.so
    /usr/local/lib/libtcl7.5.so: ELF 32-bit LSB shared object, Intel 80386, \
        version 1
    # ls -l /usr/local/lib/libtcl*.so
    -r-xr-x--x   1 luke     kendall    277033 Aug 21 21:16 \
        /usr/local/lib/libtcl7.5.so*
    # ldconfig -l /usr/local/lib/libtcl*.so
    ldconfig: /usr/local/lib/libtcl7.5.so is not a shared library

The same thing happened with the Nextstep-look version of tk, tkstep.
`file' says the .so is a shared library, ldconfig says it isn't!
Here's another program, provided by my Yggdrasil installation:

    # file /usr/local/bin/bltt_wish
    /usr/local/bin/bltt_wish: Linux/i386 demand-paged executable (QMAGIC)

When I run this, I get similar problems.  Yet, for this program, I
get a different paradox for the installed libtk.so.4 library,
which I use often with tkmail4!  Behold:

    # file /usr/lib/libtcl.so.7.4
    /usr/lib/libtcl.so.7.4: ELF 32-bit LSB shared object, Intel 80386, \
        version 1

    # ldd /usr/local/bin/bltt_wish
        libtcl.so.7 (DLL Jump 7.4) => not found
    /usr/local/bin/bltt_wish: can't load library '/usr/lib/libtk.so.4'
        Exec format error
        libtk.so.4 (DLL Jump 4.0) => not found
        libX11.so.6 (DLL Jump 6.0) => /usr/X11R6/aout/lib/libX11.so.6.0
        libm.so.4 (DLL Jump 4.6pl27) => /lib/libm.so.4.5.26
        libc.so.4 (DLL Jump 4.6pl27) => /lib/libc.so.4.5.26

    # file /usr/lib/libtk.so.4
    /usr/lib/libtk.so.4: symbolic link to libtk.so.4.0
    # file /usr/lib/libtk.so.4.0
    /usr/lib/libtk.so.4.0: ELF 32-bit LSB shared object, Intel 80386, version 1
    # ldconfig -l -v /usr/lib/libtk.so.4.0
    ldconfig: version 1.7.0
            libtk.so.4 => libtk.so.4.0

Note that tk4.0 and tcl7.4 work just fine together on my system.

This is astonishingly frustrating!  Can anyone explain what's going
wrong here?

luke

 
 
 

When is a shared library not a shared library?

Post by Daniel Robert Frankl » Wed, 15 Jan 1997 04:00:00


[stuff about trying to use ELF libraries on an a.out systyem snipped]

When is a shared library not a shared library? When it's ELF and you are
running an a.out system. You have old C libraries & ld.so, which won't
recognise the ELF library.

Building a.out libraries is painful if the makefile does not cater for
the possibility already... so I would suggest the (less) painful step of
getting a current distribution and doing a complete re-installation ) of
the ENTIRE system). This may seem more trouble than it is worth, but you
will have to change over eventually... you will also be able to run
legacy a.out stuff if you need to (and you kernels supports it and the
shared libraries are still there).

Debian 1.2 is excellent if you wish to try this. Even handles RPMs.
--

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

 
 
 

When is a shared library not a shared library?

Post by Paco Mo » Thu, 23 Jan 1997 04:00:00


:     # file /usr/local/lib/Blt.so
:     /usr/local/lib/Blt.so: ELF 32-bit LSB shared object, Intel 80386, \
:       version 1
:
: So it's a shared library, I take it.  But that's not what the shared
: library tools say!
:
:     # ldconfig -l -v /usr/local/lib/Blt.so
:     ldconfig: version 1.7.0
:     ldconfig: /usr/local/lib/Blt.so is not a shared library

The message with ldconfig 1.8.5 would be different but the effect is the
same. You don't follow standard naming convention for libs. Rename the
file to libBlt.so.

This doesn't mean the library doesn't work. You have (hopefully) a
working lib but there is nothing to do for ldconfig.

For example:
p.c:  int f(){}
q.c:  int main(){f();}

gcc -fPIC -shared -o p.so p.c
gcc -o q q.c p.so

export LD_LIBRARY_PATH=.
ldd q
        p.so.1.85 => ./p.so.1.85
        libc.so.5 => /lib/libc.so.5.4.17

:     /usr/local/lib/libtcl7.5.so: ELF 32-bit LSB shared object, Intel 80386, \
:       version 1
:     # ls -l /usr/local/lib/libtcl*.so
:     -r-xr-x--x   1 luke     kendall    277033 Aug 21 21:16 \
:       /usr/local/lib/libtcl7.5.so*
:     # ldconfig -l /usr/local/lib/libtcl*.so
:     ldconfig: /usr/local/lib/libtcl7.5.so is not a shared library

May be you are using an inconsistent soname for libtcl? For example:

gcc -shared -Wl,-soname,libtcl7.so -o libtcl7.5.so

This time ldconfig 1.8.5 would complain about inconsistent naming.
soname should be exactly as filename except for (possibly) omitting
minor version number (after the .so suffix).

:     # file /usr/local/bin/bltt_wish
:     /usr/local/bin/bltt_wish: Linux/i386 demand-paged executable (QMAGIC)

a.out binaries require a.out libraries.

:     # file /usr/lib/libtcl.so.7.4
:     /usr/lib/libtcl.so.7.4: ELF 32-bit LSB shared object, Intel 80386, \

ELF lib, not a.out lib

:     # ldd /usr/local/bin/bltt_wish
:         libtcl.so.7 (DLL Jump 7.4) => not found

ldd points he is searching for DLL Jump table a.out lib, not ELF

:     /usr/local/bin/bltt_wish: can't load library '/usr/lib/libtk.so.4'
:         Exec format error
:         libtk.so.4 (DLL Jump 4.0) => not found

same as above

: Note that tk4.0 and tcl7.4 work just fine together on my system.

with ELF executables.

: This is astonishingly frustrating!  Can anyone explain what's going
: wrong here?

nothing wrong, just use ELF binaries or recompile the sources

Paco

 
 
 

1. Will strip(debug shared library) == nodebug shared library ?

compiling the C++ code without debug option to produce object
files(.o) and then producing the shared library with them. Say, the
size of this library is SIZE_SO_NoD.

compiling the C++ code with debug option to produce object files(.o)
and then producing the shared library with them. Then, do 'strip
library_name'. Say, the size of this library is SIZE_SO_D.

Will SIZE_SO_NoD & SIZE_SO_D be exactly/almost equal ? If yes/no, why?
Also, what exactly 'mcs -d library_name' do? Does it reduce symbols
from the shared library which was produced without debug option also?

2. Win95 & Linux

3. Help with building shared libraries with dependencies on other shared libraries

4. Looking for canonical termcap / terminfo sources

5. Question: Inclusion of shared libraries during linking of shared libraries

6. Insight

7. Shared library loading shared library.

8. Kernel Compile problem (1.2.8)

9. Need a Shared Library Guru: beyond simple shared library question

10. FORTRAN common in AIX shared library not shared at runtime (0/1)

11. Shared libraries sharing from main app?

12. Compiling static libraries as shared libraries

13. Building shared library which includes static libraries