Develop Reference

boost python library linking issue -- undefined symbol

I am using boost-python built for python3 to expose a simple hello-world program. The example can be found here : https://github.com/TNG/boost-python-examples/blob/master/01-HelloWorld/hello.cpp
I ran the following commands to get the shared object:
g++ -fPIC -c -I/usr/include/python3.4m -I/usr/include/python3.4m -Wno-unused-result -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -L/usr/lib/x86_64-linux-gnu/libboost_python-py34 hello.cpp
g++ -shared hello.o -o hello.so
After this, I run the python3 -c 'import hello' command and I get the following error:
Traceback (most recent call last):
File "", line 1, in
ImportError: hello.so: undefined symbol: _ZTIN5boost6python7objects21py_function_impl_baseE
I partly understand this issue may be because my boost-python installation may be built for an alternative python version (for instance python2.7). When I run the command:
ls /usr/lib/x86_64-linux-gnu/libboost_python*.so
There are three .so files:
1. libboost_python-py27.so
2. libboost_python-py34.so
3. libboost_python.so
How can this issue be circumvented?

use pkg-config to retrieve ldflags and cflags of your boost library

Installing miniconda might be an option for you. https://conda.io/miniconda.html
This will provide a complete, isolated, python environment. You can then
conda install boost
I've tested this on my system and it worked well. I modified the Makefile from http://www.shocksolution.com/python-basics-tutorials-and-examples/linking-python-and-c-with-boostpython/
My Makefile can be found here:
https://github.com/grelleum/boost-python-with-anaconda

Cython: Compiling and Cannot Find Library Mac OSX 10.12

I am just getting started with Cython and am trying to compile a "Hello World" script. I am trying to use gcc -Os /User/Documents/Python/Test\ Python/helloCopy.c -I/Library/Frameworks/Python.framework/Versions/3.5/include/python3.5m -l, but I don't know what to add after the -l. Other forum pages say to "include -lpython2.7 (or whatever version of Python you're using) on the linker command-line" but that produces ld: library not found for -lpython3.5
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Should I be directing the -l to a particular folder?

I do not know what resource you're using, but this does not say anything about a -l flag. It suggests
cython -a helloCopy.pyx
This creates a yourmod.c file, and the -a switch produces an annotated html file of the source code. Pass the -h flag for a complete list of supported flags.
gcc -shared -pthread -fPIC -fwrapv -O2 -Wall -fno-strict-aliasing -I/usr/include/python2.7 -o helloCopy.so helloCopy.c
(Linux)
On macOS I would try to compile with
gcc -I/usr/bin/python -o helloCopy.so helloCopy.c
to use the standard version of Python.

Fatal Python error when using SWIG under OSX

I have troubles using a Python interface generated with SWIG (I have OSX 10.11.12). After compiling and linking everything together as such:
swig -python erk_integrator.i
gcc -c -fPIC -O3 model.c auxiliary_functions.c timing_functions.c
gcc -c -fPIC -O3 erk_integrator.c erk_integrator_wrap.c -I. -I/usr/local/include/python2.7
gcc -lpython -dynamiclib model.o erk_integrator.o erk_integrator_wrap.o auxiliary_functions.o timing_functions.o -o _erk_integrator.so
I try a test script, but Python throws a fatal error:
/usr/local/bin/python test_erk.py
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6
But when I run
/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 test_erk.py
everything works as it should. However, I need to use /usr/local/bin/python (from Homebrew) instead of the system Python.
I think something goes wrong in the linking step. Many thanks for helping!

This blog post helped me solve it: blog.tim-smith.us/2015/09/python-extension-modules-os-x
It turns out on OSX you need
-undefined dynamic_lookup
instead of
-lpython

g++ linking and swig

I have a cpp file with functions that I'm using in python with SWIG. I use the following commands to compile the source and create the file to use with python.
swig -c++ -python mini.i
g++ -O2 -c mini.cpp -I/usr/include/python2.4 -I/usr/lib/python2.4
g++ -O2 -c mini_wrap.cxx -I/usr/include/python2.4 -I/usr/lib/python2.4
g++ -shared mini.o mini_wrap.o -o _mini.so
I'm trying now to use GSL in my source cpp source file. If I was just compiling the GSL file I would do
g++ -lgsl -lgslcblas -lm -o mini.o mini.cpp
I've tried adding the -lgsl -lgslcblas -lm to the lines for the swig compile but I get
g++: -lgsl: linker input file unused because linking not done
g++: -lgslcblas: linker input file unused because linking not done
g++: -lm: linker input file unused because linking not done
How can I link the gsl libraries? Thanks

Swig does no linking, as the warning message states. Put the -lgsl etc. on the link command, which is your last g++ command.

Linking GSL (or other library) statically into a shared library

Note: Despite the mentioning of Python in the following there is a good chance for my problem not to be Python related at all. If I am not mistaken the “module” I mention is equivalent to a C library—at least for the concerns of my problem.
On Debian I am trying to create a Python module with C, which in turn uses the GSL. The following Makefile successfully compiles it:
CC = gcc -Wall -fPIC -O3
NAME = meinzeug
matrizenwuerfler: $(SRC)
$(CC) -o $(NAME).o -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/include/python2.5 -c $(NAME).c
$(CC) -shared -o $(NAME).so -lgsl -lgslcblas -lm $(NAME).o
Because this module is supposed to be used by (Linux) machines other than mine, I want the GSL to be included into the module (or be shipped with it).
However, if I add -static as option to the last line of the Makefile, I get the following error:
gcc -Wall -fPIC -O3 -shared -static -o meinzeug.so -lgsl -lgslcblas -lm meinzeug.o
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtbeginT.o: relocation R_X86_64_32 against `__DTOR_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtbeginT.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
Adding -Wl,-Bstatic before the library linking results in a different error:
gcc -Wall -fPIC -O3 -shared -o meinzeug.so -Wl,-Bstatic -lgsl -lgslcblas -lm meinzeug.o
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
Other Stuff, that did not work: Recompiling GSL with fPIC, -static-libgcc, permutating the options.
What I did not try yet, is compiling gcc with fPIC or similar.

Try
gcc -Wall -fPIC -O3 -shared -o meinzeug.so /usr/lib/libgsl.a -lm meinzeug.
as you cannot do
gcc -Wall -fPIC -O3 -shared -static ... # shared and static at the same time ?
so you would provide the static library of GSL alongside with your code.
At the end of the day, I would punt and keep the dependency on the GSL. Just about everybody has it, and the API is pretty stable.

The ordering of the library calls is important. For me, it meant sending the /usr/lib/libgsl.a to the end of the command. That solved it.