Thanks for the tip. I am not using RTLD_GLOBAL. And it appears there is no real definition for RTLD_LOCAL (i.e. 0x0000) Forgot to mention, I can make B.so declaration 'static short value' and solve the problem. But that's not the fix I want. But I'm concerned about the main execuable being corrupted by the shared libs, which are to be created by anybody. I want to secure the main executable, not tell dozens of people they have to code the sared module a specific way, and have to keep up with all the vendors everytime there is a problem. Who gets the 'fvisibility' flag? And does it apply if I'm not using the RTLD_GLOBAL flag? -----Original Message----- From: Keith, Robert (London) [mailto:robert_keith@xxxxxx] Sent: Monday, June 13, 2005 11:26 AM To: Weber, Scott; gcc-help@xxxxxxxxxxx Subject: RE: Globals visible in shared object libraries 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/ --------------------------------------------------------
