[Patches] Extension building on Win32 using Gnu C

Greg Stein gstein@lyra.org
Fri, 16 Jun 2000 02:59:27 -0700


On Wed, Jun 14, 2000 at 01:41:24PM +0200, Rene Liebscher wrote:
> Greg Ward wrote:
> > > --- python.patched/dist/src/Include/object.h  Tue May 30 10:34:33 2000
> > [...]
> > > --- 107,120 ----
> > >       PyObject_HEAD \
> > >       int ob_size; /* Number of items in variable part */
> > >
> > > ! typedef DL_CLASSIMPORT_BEG struct _object {
> > >       PyObject_HEAD
> > > ! } DL_CLASSIMPORT_END PyObject;
> > >
> > >
> > > + typedef DL_CLASSIMPORT_BEG struct {
> > > +     PyObject_VAR_HEAD
> > > + } DL_CLASSIMPORT_END PyVarObject;
> > 
> > This strikes me as really weird style.  Do those macros really *have* to
> > be wormed into the typedefs in that way?  Isn't there a cleaner way to
> > do it?
> 
> The Gnu-C compilers need these imports, there are two ways to do so
> 
> struct name { ... } __declspec(dllimport);
> 
> or 
> 
> struct __declspec(dllimport) name { ... };
> 
> Read also 
> http://gcc.gnu.org/onlinedocs/gcc_4.html#SEC95  (paragraphs 3 and 4)
> __declspec is another name for __attribute 
> They don't mention dllimport and types in the same context, I don't know
> why.

Maybe because it doesn't apply?

I have never seen *linkage* information applied to a typedef. That just
doesn't make sense.

> (However, MS Visual C++ uses the same import statements for imports of
> classes from dll's. egcs 1.1.x uses __declspec() in MS compatible way.)

Importing classes is different than importing typedefs. A class usually has
some associated data, which needs to have linkage information associated
with it.

> In typedefs you could have unnamed structs, so I prefer the second.
> Even if it seems to work to have such a definition:
> typedef struct __declspec(import) { ... } name;
> 
> If you don't have these imports in C-mode you get warnings and in C++
> mode the compiler chrashs.

Can you post the warnings that you're receiving? I gotta believe there is
something else going on.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/