views:

308

answers:

1

Hey everyone,

I am trying to use SWIG to wrap some C++ code for the use with Python. As described here it seems to be necessary to link my C++ code against an .so file, not a .dylib file. The thread suggests to use libtool in combination with the -module flag to link, but I am using qmake and need more precise instructions on how I do that.

My .pro file (for qmake) looks like this:

TEMPLATE = lib
TARGET = 
CONFIG += qt debug console plugin no_plugin_name_prefix
QT += opengl
DEPENDPATH += . libgm src
INCLUDEPATH += . libgm src /usr/include/python2.6/
LIBS += -L/usr/lib -lpython
MOC_DIR = .moc
OBJECTS_DIR = .tmp
DESTDIR = bin
TARGET = _mylibname
DEFINES  += COMPILE_DL=1

HEADERS += <my_headers> \
           src/swig_wrap.h

SOURCES += <my_sources>
           src/swig_wrap.cxx

I am invoking first swig, then qmake, then make using Eclipse builders:

cd src/
swig -c++ -python swig.i
cd ..
qmake -spec macx-g++
make all

Compile and Link works fine, but leaves me with bin/_mylibname.dylib, and when I run my python application, the statement import _mylibname fails.

Does anyone know how I can get qmake to build a *.so instead of a *.dylib, possibly using libtool (or any other way for all I care)? My platform:

  • Mac OS X Snow Leopard (10.6)
  • Python 2.6
  • SWIG 1.3.31
  • qmake 2.01a with Qt 4.6.2
  • g++ i686-apple-darwin10-g++-4.2.1

I am not very knowledgable with linking issues, so please be gentle :-)

Ole

A: 

I think you might have two issues.

To get the output file to be a .so file, I set the compile option -o mylib.so and that forced gcc to name the file correctly.

The other issue I think you might have is that on the Mac, linking against the python lib is not the same as on a Linux machine. What I found that was on the mac you don't use -lpython to link to the python lib, but rather use -framework python and then the linker will find the correct lib.

Nick Loadholtes