I have a trivial program to test for availability of python development files:
#include
int main(){Py_Initialize(); Py_Finalize(); }
<
if with python 3.x installed, maybe this command can work:
g++ hw.cpp `/usr/bin/python3-config --cflags` `/usr/python3-config --ldflags`
By the way, you should check you gcc and python version.
As I know, if gcc version is 5.4 and python version is 3.7, it doesn't work.(python 3.5 is work)
When you run /usr/bin/python3-config --cflags
, in fact, it is the compile option.
I encountered the same linking problem as well.
But in my case it was not enough to provide -lpython
. Also -L
was needed. I.e.
g++ -I/usr/include/python3.5 hw.cpp -L/usr/lib/python3.5/config-3.5m-x86_64-linux-gnu -lpython3.5
And yes. Order matters.
Try:
gcc -I/usr/include/python2.7 p.c -lpython2.7
the linker doesn't yet know that Py_Initialize
is a required symbol when it loads libpython2.7.a
, so it tosses it away. And then it gets to p.o and throws a fit about the missing symbol. Ordering it this way will let the linker look for the missing symbol in subsequent inputs.
See: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus,
foo.o -lz bar.o' searches library
z' after file foo.o but before bar.o. If bar.o refers to functions in `z', those functions may not be loaded.
I encountered the same linking problem and personally my problem was that my 32 bit mingw compiler can't load 64 bit python library. I upgrade my mingw to 64 bit and solved my problem. Left a note here in case someone newbie stuck into same problem.