1

I'm trying to create my first SWIG python DLL with Visual Studio 2010, using an example I downloaded from swig,org. I'm running Windows professional 64-bit. I downloaded swigwin-2.0.7 and unzipped it. I've followed the instructions here and here and in both cases, the wrap file gets built, but the project build fails. The linker complains about 56 unresolved external symbols, all with names something like __imp__PyBytes_AsStringAndSize or __imp__PyExc_RuntimeError.

I've tried this using my python 2.7 installation as well as my python 3.2 installation, with similar results. Do I have to build swig from the source for my platform? I've spent the last 6 hours or so on this, and I'm nonplussed.

Community
  • 1
  • 1
saulspatz
  • 5,011
  • 5
  • 36
  • 47
  • What example did you download from swig.org? Common errors are providing the wrong path to the Python library or mixing 32- and 64-bit Pythons and extensions, but those give different errors that what you are seeing. Did you follow the instructions exactly? (I wrote the second set you referenced.) – Mark Tolonen Aug 19 '12 at 01:51
  • Thanks for your help. The example I downloaded was the one called simple. I certainly tried to follow the instructions exactly. The paths to the libraries are correct. I'm sure this is so, because in one of my iterations, I mistyped the library name, and the linker complained, but I'm not getting that error message now. – saulspatz Aug 19 '12 at 13:34

1 Answers1

3

Following the instructions here, using the simple Python example from SWIG, Windows 7 64-bit and Python 2.7 32-bit, I did not see the OP's specific errors. I saw:

1>example_wrap.obj : error LNK2019: unresolved external symbol "int __cdecl gcd(int,int)" (?gcd@@YAHHH@Z) referenced in function __wrap_gcd
1>example_wrap.obj : error LNK2001: unresolved external symbol "double Foo" (?Foo@@3NA)

Two changes had to be made due to the simple example being C source instead of C++:

  1. Do not use the -c++ switch on the swig command line (step 13 of the instructions).
  2. The generated file is now example_wrap.c not example_wrap.cxx (referred to in steps 14 and 19 of the instructions).

Alternatively, just rename example.c to example.cpp in this case before following the instructions and they should work as is.

Community
  • 1
  • 1
Mark Tolonen
  • 166,664
  • 26
  • 169
  • 251
  • Yes, thanks for the follow-up. I remote desktop'ed to my office machine, which has 32-bit python, and did the same thing as you, with the same results as you got. I then tried building 64-bit SWIG from the sources on my home machine, but I still got all the same unresolved symbols. Perhaps SWIG doesn't support 64-bit python yet? – saulspatz Aug 19 '12 at 17:29
  • I tested with 32-bit Python 3.2 and 64-bit Python 3.3b2 as well. 3.3b2 had a problem with the generated example.py proxy, but the _example.pyd worked fine. – Mark Tolonen Aug 19 '12 at 17:58
  • clarification...are you building SWIG from sources? I used the 2.0.7 binary downloaded from swig.org in all cases. – Mark Tolonen Aug 19 '12 at 18:04
  • Originally, I used the binary downloaded from swig.org on both my office machine and my home machine. After I had success on the office machine, I thought that perhaps I had to compile a 64-bit version of SWIG for my machine, since the only difference I could see was that I was using 32-bit python at work and 64-bit python at home. I just tried installing SIP instead on my home machine. I couldn't get NMAKE to work, so I tried with MinGW and I got similar linker errors: all kinds of unresolved symbols whose names start with _imp__. This was with python 3.2. I didn't bother with 2.7 – saulspatz Aug 19 '12 at 19:50
  • 2
    SWIG doesn't need to be 64-bit. The 32-bit binary in the `swigwin` distribution is all you need. – Mark Tolonen Aug 19 '12 at 22:30