I have had a similar problem with functions. After much searching the
result is as follows
1. Don't Load the module with RTLD_GLOBAL, which is what it sounds like
you are doing. If you absolutely have to do this then depending on the
version of the compiler that you are using I would recommend compiling
the code with the -fvisibility=hidden and making sure you only call
functions that you have extern'ed when calling across shared library
boundaries. This switch makes all symbols part of the local (dll/so)
namespace when its loaded and only pushes symbols you have explicitly
declared as global in to the global namespace.
2.Another alternative is to put the following in front of your
declaration for 'value'
__attribute__ ((visibility("hidden")))
This will only be honoured if your compiler has had this functionality
included (or back ported). Basically this tells the compiler to look in
the local namespace then the global namespace when attempting to resolve
symbols using shared libraries. I honestly don't know what version this
was officially included in the compiler (I think it was 3.4, since it
has been back ported to many compilers even 3.2.3)
So that's the quick fix - more information can be found at:
http://gcc.gnu.org/wiki/Visibility
And
http://www.google.co.uk/url?sa=U&start=1&q=http://people.redhat.com/drep
per/dsohowto.pdf&e=10431
3. Namespace the variable in each so and make sure that the functions
that update it reference it via the correct name space.
E.g. namespace a {
value ;
}
void someFunc() {
a::value = 10 ;
}
namespace b {
value ;
}
Void someOtherFunc() {
b::value = 21 ;
}
Regards,
Robert Keith
-----Original Message-----
From: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On
Behalf Of Weber, Scott
Sent: 13 June 2005 17:13
To: gcc-help@xxxxxxxxxxx
Subject: Globals visible in shared object libraries
I have been digging at this for days, Now I'm turning to the experts.
Given:
executable module A has a global variable (long) called 'value'
It loads module B.so using dlopen() and loads a function pointer
(called 'test') .
Module B.so also has a global variable (some other type) called 'value'
When I call test() in B.so and that function changes the contents of
'value', it
changes to one in the A executable. Not the one in in B.so. (or I
assume they
have been 'linked' into the same memory location)
How can I DISABLE the dynamic linker from doing what appears to be
binding
the variable 'value' in the two modules together? It's this a HUGH
hole where
any shared library can get access to (and corrupt) variables in the main
executable?
Everything think I've seen written seems to be regarding doing the
opposite.
Any help is appreciated.
-Scott Weber
(sorry if this is not exclusively plain text - Outlook... :-( )
--------------------------------------------------------
If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
--------------------------------------------------------
