Re: sleep contains crypto stuff?
[Moving to debian-policy per Joey's request, please continue
there]
On Sun, 12 Apr 1998, Martin Schulze wrote:
joey> > They are not. I pointed this out on debian-policy a while ago,
joey> > but nobody seemed to care. :-(
joey>
joey> Ok, now at least one care about it. Please bring it up on -policy
joey> again.
Ok, I'm enclosing the same message I posted to policy a while
ago. It's long. It's intent is to show the behaviour of the
linker.
Marcelo
Date: Mon, 26 Jan 1998 20:24:52 -0600 (CST)
Subject: Re: PW#5-7: Linking shared libraries with -lc
On Mon, 26 Jan 1998, Christian Schwarz wrote:
> It would be good if someone more experienced than I am could comment on
> Marcelo's arguments against linking shared libraries with `-l'. If his
> arguments are valid (I really can't tell) then we'll have to drop this
> release goal and the policy proposal.
Just to clean things a little bit. Here's what I have (please excuse me
for the long output transcription)
$ echo 'void hello() { printf("Hello,"); }' > libhello.c
$ gcc -c -fPIC libhello.c
$ gcc -shared -Wl,-soname,libhello.so.0 -o libhello.so.0 libhello.o -lc
$ ldd ./libhello.so.0
libc.so.6 => /lib/libc.so.6 (0x40005000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
$ echo 'void main() { hello(); printf(" world!\n"); }' > hello.c
$ gcc -o hello -Wl,-rpath,`pwd` hello.c ./libhello.so.0
$ ldd ./hello
libhello.so.0 => /home/mmagallo/develop/shlib-test/libhello.so.0 (0x4000c000)
libc.so.6 => /lib/libc.so.6 (0x40011000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ rm hello libhello.so.0
$ gcc -shared -Wl,-soname,libhello.so.0 -o libhello.so.0 libhello.o -lc -lm
$ ldd ./libhello.so.0
libc.so.6 => /lib/libc.so.6 (0x40005000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
libm.so.6 => /lib/libm.so.6 (0x400a8000)
$ gcc -o hello -Wl,-rpath,`pwd` hello.c ./libhello.so.0
$ ldd ./hello
libhello.so.0 => /home/mmagallo/develop/shlib-test/libhello.so.0 (0x4000c000)
libc.so.6 => /lib/libc.so.6 (0x40011000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libm.so.6 => /lib/libm.so.6 (0x400b4000)
As you can see from the output above, ./hello ends up depeding on whatever
the library depends on. strace reveals the libm is loaded. I don't know
what for, but it's loaded. (Can somebody do this, and strace ./hello and
tell what's going on there?)
I think this is a bug in the GNU linker... or at least something to watch
out for. Please note that you can compile the programs without specifying
-lm. Hmmm... let's see about that:
$ echo 'void hello() { printf("Hello,"); }
void hello_math() { printf("%.2g", sin(1.57)); }' > \
libhello_math.c
Now libhello_math depends on libm
$ gcc -c -fPIC libhello_math.c
libhello_math.c: In function `hello_math':
libhello_math.c:1: warning: type mismatch in implicit declaration for built-in function `sin'
$ gcc -shared -Wl,-soname,libhello_math.so.0 -o libhello_math.so.0 libhello_math.o -lc
note I'm not putting -lm here... this is current policy. This enables
dpkg-shlibdeps to make the package depend on libc6, which is desirable.
$ ldd ./libhello_math.so.0
libc.so.6 => /lib/libc.so.6 (0x40005000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
$ echo 'void main() { hello(); printf(" world!\n"); }' > hello_a.c
$ gcc -o hello_a -Wl,-rpath,`pwd` hello_a.c ./libhello_math.so.0
./libhello_math.so.0: undefined reference to `sin'
and hello_a is not linked. Note that hello_a.c doesn't call hello_math(),
just hello(). Let's try it again:
$ gcc -o hello_a -Wl,-rpath,`pwd` hello_a.c ./libhello_math.so.0 -lm
note -lm was added!
$ ldd ./hello_a
libhello_math.so.0 => /home/mmagallo/develop/shlib-test/libhello_math.so.0 (0x4000c000)
libm.so.6 => /lib/libm.so.6 (0x40011000)
libc.so.6 => /lib/libc.so.6 (0x4002a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
$ echo 'void main() { hello_math(); printf(" world!\n"); }' > hello_b.c
$ gcc -o hello_b -Wl,-rpath,`pwd` hello_b.c ./libhello_math.so.0 -lm
$ ldd ./hello_b
libhello_math.so.0 => /home/mmagallo/develop/shlib-test/libhello_math.so.0 (0x4000c000)
libm.so.6 => /lib/libm.so.6 (0x40011000)
libc.so.6 => /lib/libc.so.6 (0x4002a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
No difference. It doesn't matter if the program uses the functions calling
sin() or not. This is definitely a problem in the linker. The program has
to be linked with -lm.
Now I don't know what to think. What I posted before was based on a
problem I had, and it was related somehow to this, but I didn't perform
any tests like this. It seemed reasonable to me that the linker would
notice which functions were not being called, and should not force one to
link agaisnt every library required by the library. Is there a way arround
this?
> > > IMO, shared libraries should use `-lsomelib' for each library they directly
> > > depend on, not just `-lc'. For example, the LessTif shared library depends
Considering the above facts, I now think this may desireable, but it's a
pain, specially since the upstream authors won't do it this way, and one
would have to hunt makefiles for the correct places to put the linker
options (with the current proposal, it's enough to add LD_FLAGS="-lc" in
most cases). I mean, I don't want libraries listing a ton of other
libraries they don't depend on, and fooling dpkg-shlibdeps into thinking a
package depends on many things it doesn't even know about. (This can
happen! That was precisely my problem)
Marcelo
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: