FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Mon, Jan 06, 2003 at 09:56:44AM -0800, Michael Peppler wrote:

> > Even if you managed to keep the two modules clear of each other within
> > the Perl namespace, there would still be (unavoidable) namespace
> > collisions at the C level.  If "at the same time in Perl" means "in the
> > same process", anything that would make this work would *always* be a
> > kludge.

> Well, not necessarily. Both DBD::Sybase and Sybase::CTlib can co-exist,
> and they use the same functions. By using dynamic loading we should be
> able to have DBD::Sybase (with the Sybase libs) and (say) DBD::FreeTDS
> (with the freetds libs) in the same process with no problems.

$ ldd /usr/lib/perl5/auto/DBD/Sybase/Sybase.so 
        libct.so.0 => /usr/lib/libct.so.0 (0x4002e000)
        libtds.so.1 => /usr/lib/libtds.so.1 (0x4004f000)
        libdl.so.2 => /lib/libdl.so.2 (0x4006a000)
        libm.so.6 => /lib/libm.so.6 (0x4006d000)
        libc.so.6 => /lib/libc.so.6 (0x4008e000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4019e000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
$

Dynamic loading or not, the resolution of symbols used *by* DBD::Sybase
is handled by the system library loader.  On ELF platforms, this means
you have the "first come, first served" problem of deciding which library
to look in to find the (e.g.) ct_command function.  Now, there are linker
flags that can be used to tell the runtime linker that it should search
for the symbol first in the libraries referenced directly by Sybase.so,
but this appears to be sufficiently non-portable that not much software
uses it.  In the general case, best case scenario is that both Perl
modules are going to end up using functions from the same library; worst
case is that you get a segfault.

-- 
Steve Langasek
postmodern programmer

Attachment: pgpQfpUbUxG5K.pgp
Description: PGP signature