Python extensions using MinGW and CXX

cmkl cmkleffner at gmx.de
Fri Feb 14 16:26:30 CET 2003


Reinhard Nadrchal <reinhard at proceryon.at> wrote in message news:<mailman.1045220630.6078.python-list at python.org>...
> Gerhard Häring wrote:
> 
> >Reinhard Nadrchal <reinhard at proceryon.at> wrote:
> >  
> >
> >>To create the python import library I did the following (with my 
> >>specific paths provided):
> >>
> >>pexports /C/WINDOWS/system32/python20.dll > python20.def
> >>dlltool  --dllname /C/WINDOWS/system32/python20.dll --def python20.def 
> >>--output-lib libpython20.a
> >>and copied libpython20.a to the Python20/libs directory.
> >>    
> >>
> >
> >Try not to use any paths for python20.dll. I. e.:
> >
> >$ pexports python20.dll >python20.def
> >$ dlltool --dllname python20.dll --def python20.def --output-lib libpython20.a
> >
> >You'll need to have copied python20.dll in your working directory first.
> >
> >I remember another user had weird problems when he used absolute paths and
> >the above method worked for him.
> >  
> >
> This doesn't change anything, here some excerpts from what the linker says:
> <snip>
> Info: resolving _PyFloat_Type by linking to __imp__PyFloat_Type 
> (auto-import)
> .
> fu000002.o(.idata$3+0xc): undefined reference to `libpython20_a_iname'
> .
> nmth000000.o(.idata$4+0x0): undefined reference to `_nm__PyFloat_Type'
> <snap>
> 
> >  
> >
> >>If I, on the other hand, link in python20.dll I get no errors and ld 
> >>seems to be happy. The trouble starts when I execute 'import foo' from 
> >>the python interpreter -  it simply crashes without  any comment.
> >>
> >>g++ -shared -lpython20 foo.o -ofoo.pyd
> >>
> >>That's the way I've tried it so far. I've also tried to link without the 
> >>-shared option using -mdll,
> >>    
> >>
> >
> >Python's distutils uses -mdll, but I really don't know the meaning of
> >either one in the win32 context :-(
> >  
> >
> The only think I've seen so far is that you cannot mix -mdll and -shared.
> 
> >  
> >
> >>but in this case Python doesn't recognize 
> >>the 'initfoo' entry point - maybe this is the key ?! Ho do I have to 
> >>declare/define the init function ???
> >>    
> >>
> >
> >With DL_EXPORT:
> >
> >
> >extern "C" {
> >DL_EXPORT(void) initfoo() {
> >    // ...
> >}
> >}
> >#v-
> >
> This doesn't help; if I try c++ -mdll instead of c++ -shared the 
> entrypoint (initfoo) is not recognized by python. By the way: the 
> init... function is declared in a header (foo.h) and defined in the 
> source file. Would it be ok to skip the declaration in the header (I 
> think so) ???
> 

Here is what -shared on mingw32 does:

gcc -shared runs the linker with: -shared -e _DllMainCRTStartup at 12
and changes crt2.o to dllcrt2.o 

-mdll is deprecated or useful only in special cases:

Citation from mingw-user mailing list:
= > > --dll only says: 'use default image base for dlls'.  
= > > It doesn't do any of the relocateability magic.
= > > -shared says: "build a relocateable dll (or more generally, 
= > > a shareable library)"  ie, do all the things that 
= > > dllwrap/dlltool would do
= > So the use of -mdll or --dll should not be used by libtool.
= > Only  -shared  should be used.
= Correct, unless there is a reason to build a non-relocateable 
= library or an  .exe that exports symbols, or want a 
= non-default entry point or do other things
= where you need more control over base files and exp files.
= Danny                           
= > Earnie.
-------------------------------------------------------------

So you may try to use distutils but change -mdll to -shared and 
get rid of the '--entry _DllMain at 12' in cygwinccompiler.py

Sincerly cmkl

> >
> >-- Gerhard
> >  
> >
> Oh god, I'm afraid that we will have to use VC++ ;-) with some 60,000 
> lines of c++ sourcecode written for gcc - or do you have any other ideas ???
> 
> reinhard




More information about the Python-list mailing list