[lug] q: export/import of variables

Scott Herod herod at dimensional.com
Fri Dec 6 08:21:02 MST 2002


I think that you may need to be careful with RTLD_GLOBAL.  A couple of
years ago working with the SGI compiler and linker we ran into a nagging
problem that we finally attributed to multiple dlopened objects containing
the same global variable (in this case a function pointer).  I've not
noticed the same thing with the GCC tools but don't believe that I've seen
anything similar that wasn't using namespaces.

Of course this doesn't really answer your question.  I believe that we
decided that the last in was the variable that you saw.

Scott

On Fri, 6 Dec 2002, Chan Kar Heng wrote:

>
> thanks..
> but i'm not sure if it's what i'm looking for...
>
> perhaps we have differing levels of the term 'general'.. :)
>
> "RTLD_GLOBAL - The object's global symbols are made
> available for the relocation processing of any other object.
> In addition, symbol lookup using dlopen(0, mode) and an
> asso- ciated dlsym(), allows objects loaded with
> RTLD_GLOBAL to be searched. "
>
> it really doesn't give enough insight...
>
> under windows global identifiers are often defaulted
> to dllimport or dllexport types depending on the
> build target (executable or dll) ....
>
> when an executable is linked with an import library
> of a dll, what gets linked in are things somewhat like
> proxy functions.
> these "proxy functions" will call the actual functions
> in respective dlls after dlls are loaded and symbols
> are resolved.
>
> the case might be simpler with exported functions,
> function symbols from import libraries may actually
> be function pointers, or are actual proxy functions
> ultimately calling function pointers.
> in this case, symbol resolution might only involve
> redirecting pointer to functions.
>
> it is however different with exported variables...
> i get the idea that things like:
>
> extern int myint;
>
> ... where myint is an int variable from another dll.
> it would eventually be converted into some sort of
> "proxy function" (?) during either compilation or
> linking. this "proxy function" then allows access
> to the actual variable from the dll.
> the way it could be done on some other platform
> is to have:
>
> #define int int *
> #define extern
> extern int myint;
> #undef extern
> #undef int
> #define myint *myint
>
> .. and then resolve myint to point to the actual myint
> from the dll after the dll is loaded.
>
> otherwise, of none of those are done, when an
> import library is linked in, there would be 2 instances
> of a variable (one in the dll and one in the executable).
> each (executable and dll) would only be accessing
> and changing its own copy of the variable...
>
> so i'm just curious as to how this is avoided under linux
> and most other *nix systems considering they only
> require an extern tag minus things like dllimport and
> dllexport.
>
> (i only know of these through other mailing lists and
> don't know of any actual references to specs detailing
> these yet, otherwise, i could have incorrectly said
> many things there).  :)
>
>
>
> At 2002/12/05 03:35, you wrote:
> >Chan Kar Heng wrote:
> >>hi
> >>would generally like to know how linux/elf binaries
> >>export variables in such a way that doesn't require
> >>dllimport/dllexport attributes.
> >>i'll probably dig up the elf binary specification next
> >>on this...
> >>thanks in advance...
> >>rgds,
> >>kh
> >
> >Check out the RTLD_GLOBAL option (bitmask) in dlopen.
> >
> >D. Stimits
>
>
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
>




More information about the LUG mailing list