dynamically linked libraries [was Re: Debian 2.0 release requirements]

[Douglas Bates <bates@stat.wisc.edu>]

dark@xs4all.nl (Richard Braakman) writes:

> I think there is a confusion of terms here.  This is not about linking
> shared vs. static.  But it's easy to get that idea, because when ldd
> is run on a library that is not linked with anything else, you get:
> 
> % ldd /usr/lib/libdpkg.so.0.0
>         statically linked
> 
> But this is not true!
> libdpkg does not include code from any other library.  Symbols like
> sprintf are left unresolved.  Any program that is dynamically linked
> with libdpkg must also be dynamically linked with a libc that provides
> these symbols, so that they can be resolved at program startup time.
> 
> This is described in 
>   ftp://tsx-11.mit.edu/pub/linux/packages/GCC/elf.ps.gz
> particularly section 5.4.
> 
> If libdpkg were compiled with -lc, then the soname of the libc it was
> linked with (i.e. libc.so.6) would be listed in its dynamic
> dependencies.  This means that when the dynamic linker links in
> libdpkg, it also links in libc.so.6.  Thus, you can't accidentally
> combine libdpkg with the wrong libc version.
> 
> (gcc adds -lc by default when compiling a program, but not when compiling
>  a shared library.)
> 
> So you see, the code is shared either way.  The point of this release
> goal is to put explicit dependency information in the shared
> libraries.

I am running into a conflict in the behaviour of bo and hamm systems
when building a library within a package.  I believe it is related to this 
issue of dynamically linked libraries.  I hope someone can straighten
me out on what I should change in the call to make.

The call to make to build one of these libraries looks like
 make CC="gcc" CFLAGS="-O2 -Wall -fpic -I${RHOME}/include" \
    SHLIBLDFLAGS="-shared" FC="g77" FFLAGS="-O2 -Wall -fpic"
and the Makefile itself looks like
------- beginning of Makefile ----------
LIBNAME=eda 
LD=ld 
 
OBJS=   line.o \ 
        smooth.o 
 
eda.so: $(OBJS) 
        @$(LD) $(SHLIBLDFLAGS) -o $(LIBNAME).so $(OBJS) 
 
clean: 
        @rm -f *.o *.so 
 
realclean: 
        @rm -f Makefile *.o *.so 
--------- end of Makefile ---------- 

If I compile the package on a hamm system then check it I get
$ ldd ./eda.so
	statically linked
but compiled on a bo system I get
$ ldd ./*.so 
        ./eda.so => ./eda.so 
        libc.so.5 => /lib/libc.so.5 

That first line in the output on the bo system seems to be tripping up 
dpkg-shlibdeps.  

Am I violating the release goal by having a Debian 2.0 package with a
library that says it is "statically linked" or is that just a
confusing phrase.  Should I have specified additional flags in
SHLIBLDFLAGS?


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .