[lug] q: export/import of variables

D. Stimits stimits at attbi.com
Thu Dec 5 20:04:30 MST 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).  :)
>
I'm not entirely sure what you are looking for, but the dynamic loading 
of modules in Linux is simpler than under Windows...you might be 
expecting to have to jump through more hoops than are there. You might 
find this article useful:
  http://www2.linuxjournal.com/cgi-bin/frames.pl/index.html

Search for "self-registering", it was in Journal 73, March 29, 2000.

The main issue you might need to be weary of is mixing C++ in there, 
where name mangling is used to deal with function overloading and 
namespaces.

D. Stimits, stimits AT attbi.com

>
>
> 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
>




More information about the LUG mailing list