FW: GT2.2 detailed request

Robert Olson olson at mcs.anl.gov
Wed Feb 5 09:54:16 CST 2003

> > Not sure about DLLs, though.  Michael didn't get DLLs during
> > the initial porting work, and I'm not sure that Joe's going
> > to be able to figure it out now, either.  If there's a trick
> > to generating DLLs that someone in your group could just show
> > Joe, it might be helpful.

It's not so much a trick but a process by which the exported symbols are 
tagged in the code. MSDN docs talk about how to do it.

>  If it's not a simple trick, then I
> > guess I'm not as optimistic about that piece.  Could you fill
> > me in on the major difference?  Is it the dynamic vs. static
> > loading that's important to you (i.e., memory footprint), or
> > some other aspect of DLLs?

This desire stems from problems with GASS and pyGlobus where the python 
architecture of multiple DLLs each loading the globus static libraries 
causes the Globus virtual-address-based typing system to break. A summary 
of the problem (for the python win32 crowd) and a reply follow below.


>I'm trying to use a library as an extension under win32. Internal to the 
>library is a hierarchical typing system that uses as type identifiers the 
>address of a structure describing the class; somethign like
>struct object_type
>         struct object_type *parent;
>         func_t  initializer;
>         <etc>
>const struct object_type tobj_struct = {
>     parent_obj, init_func
>tobj_type = &tobj_struct;
>Then later it tags objects using the tobj_type pointer.
>The structure of the python interface is such that multiple extension 
>modules are created, each linking in the C library that has the type 
>structures. The problem is that when Windows loads the DLLs, it maps them 
>into different address spaces. The result is that when an object created 
>by calling one extension is passed through a method in another extension, 
>comparisons made on the object pointers fail.
>I can't change the behavior of this library; does anyone have any ideas on 
>a solution? I've tried what MSDN howto Q109619 " Share All Data in a DLL" 
>suggests by adding ["-section:.data,rws", "-section:.bss,rws"] to the 
>extra_link_args keyword on the Extension in setup.py on all extensions 
>built; no change.
>Also, marking the structure with __declspec(dllexport) didn't help.
>Thank you for any advice.

And the reply I got:

>How interesting. You say that you're linking in the C library into each 
>.dll. Is your C library a static or shared lib? If it is a static lib then 
>the problem is apparent: each .dll gets a copy of that C library and thus 
>its own copy of the static-scoped type objects. If this is the case then 
>you'll have to restrict creation of these structs to just one of the .dlls 
>to make this work. If the C library is a shared lib (.dll) itself then 
>this is interesting. I guess this would mean that each time the .dll is 
>loaded the OS makes a new copy of the data part of the image? I wouldn't 
>think this would be the case. I don't think Q109619 is what you want since 
>this talks about sharing data in a .dll among all processes and in your 
>case this is all within the same process.

More information about the ag-dev mailing list