[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#231024: libc6-dev: unresolved symbols for -ldl



On Wed, Feb 04, 2004 at 09:39:35AM -0800, Neale Pickett wrote:
> Daniel Jacobowitz <dan@debian.org> writes:
> 
> > You have somehow developed a copy of libdl.so in /usr/lib.  It's not
> > the right copy; it looks to be from stable instead of unstable.  The
> > right copy is in /lib.
> >
> > This has been happening to lots of people over the last six months and
> > I have no )(!*&@ idea why!
> 
> I'd be happy to help you track it down, if you like.  We can talk on
> IRC, I'm on freenode as neale.  Email is fine, too, but won't be as
> quick.

The question is how it got there.  At this point there's probably no
way to find out.

> I did indeed have a copy of libdl.so in /usr/lib:
>     > pwd
>     /fs/mama/usr/lib
>     > ls -l libdl*
>     -rw-r--r--    1 root     root        10752 Jan 20 09:29 libdl.a
>     lrwxrwxrwx    1 root     root           20 Jan 23 11:08 libdl.so -> ../../lib/libdl.so.2
> 
> I renamed it and tried my compile again:
>     > mv libdl.so libdl.so.dpkg-horked
>     ~/tmp $ cc -o cftest cftest.c -ldl
>     /tmp/cceQnY35.o(.text+0x20): In function `main':
>     : warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
>     ~/tmp $ ./cftest || echo gar
>     ~/tmp $
> 
> So it looks as though that worked, although I'm baffled by it, since it
> was a symlink to the one in /lib.  However, gcc still isn't happy about
> something.  Both libc6 and libc6-dev are version 2.3.3ds1-11.
> 
> Thank you!

Wait, that's not right.  The libdl.so -> ../../lib/libdl.so.2 symlink
is correct.  But it should not trigger static linking.

Something else on your system is badly broken to produce this behavior.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



Reply to: