symbol name problems? [u]

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

symbol name problems? [u]

Andreas Jellinghaus-2
If I understand libtool documentation right, having the same
symbol name twice can cause problems?

Sure it does in traditional linking, but I have no idea what
happends with dynamic libraries and plugins.

if an application links liba and lib and they have the
same symbol, will it still work?

if an application links liba which loads a plubin foo
which is linked to lib, will the same symbol in liba
and libb cause trouble?

I read parts of libtool documentation today, mostly
the different ways to include libltdl, and the problems
that could arise, and it came to me: we could have
similiar problems. for example pam_pkcs11 has a private
copy of scdl and scconf, unless I'm mistaken? could
there be any problem when pam_pkcs11 loads opensc-pkcs11.so?

I have no idea of the exact internals of the varios linkers
etc, but better discuss this early than be sorry later.

for libltdl it seems best to install and use it as shared
library.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: symbol name problems? [u]

Ludovic Rousseau
On 23/08/05, Andreas Jellinghaus [c] <[hidden email]> wrote:
> If I understand libtool documentation right, having the same
> symbol name twice can cause problems?

Exact.

> Sure it does in traditional linking, but I have no idea what
> happends with dynamic libraries and plugins.
>
> if an application links liba and lib and they have the
> same symbol, will it still work?

I guess the dynamic linker will link with the first symbol it finds.
So if the two functions with the same name are identicall there is
(almost) no problem since they will have the same behavior.

To avoid this situation the much I can I declare most functions of
libpcsclite1 as "hidden".

#define INTERNAL __attribute__ ((visibility("hidden")))

INTERNAL foo(void)
{
   [...]
}

Have a look at [1]. This may be GCC specific and highly non portable.

Bye,

[1] http://gcc.gnu.org/onlinedocs/gcc-3.3.5/gcc/Function-Attributes.html#Function-Attributes

--
 Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: symbol name problems? [u]

Andreas Jellinghaus-2
On Wednesday 24 August 2005 08:24, Ludovic Rousseau wrote:
> To avoid this situation the much I can I declare most functions of
> libpcsclite1 as "hidden".

hmm. is there any way to look at a shared library and see which functions
are exported / which are hidden? To make sure we don't export functions
we don't want to export? for libp11 i would like to export PKCS11_*
functions only, nothing else.

> #define INTERNAL __attribute__ ((visibility("hidden")))

> Have a look at [1]. This may be GCC specific and highly non portable.

we can #ifdef __GCC__ or something (I hope gcc has a define that identifies
itself)?

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: symbol name problems? [u]

Ludovic Rousseau
On 24/08/05, Andreas Jellinghaus [c] <[hidden email]> wrote:
> On Wednesday 24 August 2005 08:24, Ludovic Rousseau wrote:
> > To avoid this situation the much I can I declare most functions of
> > libpcsclite1 as "hidden".
>
> hmm. is there any way to look at a shared library and see which functions
> are exported / which are hidden? To make sure we don't export functions
> we don't want to export?

I use: "objdump -t libname.so | grep \\.text"
The library must not be stripped.

> we can #ifdef __GCC__ or something (I hope gcc has a define that identifies
> itself)?

I think that __GNUC__ [1] is what we need here.

Bye,

[1] http://tigcc.ticalc.org/doc/cpp.html#SEC15_GNUC

--
 Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel