[Top][All Lists]

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

libltdl should not always use LT_GLOBAL

From: Scott James Remnant
Subject: libltdl should not always use LT_GLOBAL
Date: Sat, 13 Mar 2004 17:04:25 +0000

package libltdl3
forwarded 195821 address@hidden

Currently libltdl always dlopen()s libraries with the LT_GLOBAL flag
(defined as RTLD_GLOBAL | DL_GLOBAL).

This flag causes the external symbols defined in the library to be made
available for symbol resolution of subsequently loaded libraries.  This
isn't the default behaviour of dlopen().

Imagine the following situation:

    libdriver <-dlopen- libfoo <- libbar <- app

The app links to libbar, which links to libfoo which dlopen()s

libdriver defines the external symbol InitFoo().
libbar also defines an external symbol called InitFoo() with different

If these are dynamically linked, this is a perfectly legal situation.

However because libdriver is dlopen()d its definition of InitFoo is
exported over the top of libbar's, the application will call
libdriver::InitFoo() instead of libbar::InitFoo() even through it is not
directly linked to it.

This causes the situation in Debian bugs #195821 and #221811, both
concerning Perl database drivers which trip exactly this problem.

Perhaps we need an option whether to dlopen() libraries globally or
not?  Any thoughts?

Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]