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