> From: Sven Verdoolaege <skimo@dns.ufsia.ac.be>
>
> > > The problem seems to be: identical function names (eg dbd_db_login)
> > > in both DBD::mSQL and DBD::Oracle.
> > >
> > > I wonder how you managed to get that to work on other machines,
> > > but on this machine it doesn't.
> > >
> > > doing a perl -pie 's/dbd/odb/g' *
> > > seems to have removed the problem (or the symptoms :-)
> > > of course this isn't a ``solution''
> > > (it was the first thing i could think of)
> > >
> > > did i do something wrong that made this not work on my system or
> > > should those names be prefixed or something ?
> >
> > Dynamic linking should avoid the problem.
>
> As you can see i am using dynamic linking.
> I'm not an expert on this, but i can't see how dynamic linking could avoid
> the problem
> Where do you tell the dynamic loader that you need the functions in
> Oracle.so and not the ones already loaded from mSQL.so ?
The dbd_db_login function is called from the XS_DBD__Oracle__db__login
function in Oracle.c that is generated from Oracle.xs. When Oracle.so
is created the linker knows that it needs to resolve that link
when it's loaded.
Firstly, when dynamically loading a shared object the runtime linker
should resolve it using the symbol in the shared object that it's loading.
Secondly, the symbols in the dynamically loaded object should not be
visible for later runtime linking by default (Solaris 2 has a specific
flag for this which dl_dlopen.xs does not use).
> > Static linking should have generated an error at link time.
> > (Yes, static linking of multiple DBD's will require #define's
> > to rename the functions).
> >
> > What platform are you on? (myconfig output would be handy)
> Summary of my perl5 (patchlevel 1) configuration:
> Platform:
> osname=dec_osf, osver=3.2, archname=alpha-dec_osf
> uname='osf1 chulu.ufsia.ac.be v3.2 214 alpha '
> hint=previous
> Compiler:
> cc='cc', optimize='-O2 -Olimit 2900'
> cppflags='-DSTANDARD_C'
> ccflags ='-DSTANDARD_C'
> ldflags =''
> stdchar='unsigned char', d_stdstdio=define, usevfork=false
> voidflags=15, castflags=0, d_casti32=define, d_castneg=define
> intsize=4, alignbytes=8, usemymalloc=y, randbits=15
> Libraries:
> so=so
> libpth=/usr/shlib /lib /usr/lib /usr/ccs/lib
> libs=-ldbm -lm -lc -lbsd -lPW
> libc=/usr/shlib/libc.so
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=
> cccdlflags=' ', ccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -s'
I've not actually tried this yet. Perhaps others could try the mSQL and
Oracle combination on other platforms.
Right now I suspect it's an OSF specific issue so I've CC'd this to
the perl5-porters in the hope that any OSF users can clarify
symbol visibility and resolution behaviour for me.
> Sven
>
Tim.
>
> > > The problem seems to be: identical function names (eg dbd_db_login)
> > > in both DBD::mSQL and DBD::Oracle.
> > >
> > > I wonder how you managed to get that to work on other machines,
> > > but on this machine it doesn't.
> > >
> > > doing a perl -pie 's/dbd/odb/g' *
> > > seems to have removed the problem (or the symptoms :-)
> > > of course this isn't a ``solution''
> > > (it was the first thing i could think of)
> > >
> > > did i do something wrong that made this not work on my system or
> > > should those names be prefixed or something ?
> >
> > Dynamic linking should avoid the problem.
>
> As you can see i am using dynamic linking.
> I'm not an expert on this, but i can't see how dynamic linking could avoid
> the problem
> Where do you tell the dynamic loader that you need the functions in
> Oracle.so and not the ones already loaded from mSQL.so ?
The dbd_db_login function is called from the XS_DBD__Oracle__db__login
function in Oracle.c that is generated from Oracle.xs. When Oracle.so
is created the linker knows that it needs to resolve that link
when it's loaded.
Firstly, when dynamically loading a shared object the runtime linker
should resolve it using the symbol in the shared object that it's loading.
Secondly, the symbols in the dynamically loaded object should not be
visible for later runtime linking by default (Solaris 2 has a specific
flag for this which dl_dlopen.xs does not use).
> > Static linking should have generated an error at link time.
> > (Yes, static linking of multiple DBD's will require #define's
> > to rename the functions).
> >
> > What platform are you on? (myconfig output would be handy)
> Summary of my perl5 (patchlevel 1) configuration:
> Platform:
> osname=dec_osf, osver=3.2, archname=alpha-dec_osf
> uname='osf1 chulu.ufsia.ac.be v3.2 214 alpha '
> hint=previous
> Compiler:
> cc='cc', optimize='-O2 -Olimit 2900'
> cppflags='-DSTANDARD_C'
> ccflags ='-DSTANDARD_C'
> ldflags =''
> stdchar='unsigned char', d_stdstdio=define, usevfork=false
> voidflags=15, castflags=0, d_casti32=define, d_castneg=define
> intsize=4, alignbytes=8, usemymalloc=y, randbits=15
> Libraries:
> so=so
> libpth=/usr/shlib /lib /usr/lib /usr/ccs/lib
> libs=-ldbm -lm -lc -lbsd -lPW
> libc=/usr/shlib/libc.so
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=
> cccdlflags=' ', ccdlflags=' ', lddlflags='-shared -expect_unresolved "*" -s'
I've not actually tried this yet. Perhaps others could try the mSQL and
Oracle combination on other platforms.
Right now I suspect it's an OSF specific issue so I've CC'd this to
the perl5-porters in the hope that any OSF users can clarify
symbol visibility and resolution behaviour for me.
> Sven
>
Tim.