#1422 PYSTAF.so is not properly linked against libPython.so

[Garron Moore]

After installing the binary linux download (STAF347-linux.tar.gz ), PYSTAF.so has unresolved symbols. I believe this is due to an incorrect path in makefile.linux.

When I run "ldd -r PYSTAF.so", I see the following output. The python library is not listed anywhere:
undefined symbol: Py_BuildValue (./PYSTAF.so)
undefined symbol: PyEval_RestoreThread (./PYSTAF.so)
undefined symbol: Py_InitModule4 (./PYSTAF.so)
undefined symbol: PyEval_SaveThread (./PYSTAF.so)
undefined symbol: PyArg_ParseTuple (./PYSTAF.so)
undefined symbol: PyErr_NewException (./PYSTAF.so)
linux-gate.so.1 => (0x0067a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00bdc000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x004e9000)
libdl.so.2 => /lib/libdl.so.2 (0x002fa000)
libSTAF.so (0x0095f000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00da5000)
libm.so.6 => /lib/libm.so.6 (0x00b7b000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a19000)
libc.so.6 => /lib/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x00f27000)

When I build STAF from source, I do not have the same issue if I remove the trailing "config" from the PYTHON_V27_LIBDIRS path in makefile.linux.

After building from source, the output includes the following additional line and no undefined symbols:
libpython2.7.so.1.0 => /usr/lib/libpython2.7.so.1.0 (0xf7cdf000)

This issue prevents some of our tools from working with PySTAF and we currently have to build STAF from source to get around this issue.

[Sharon Lucas]

Did you download Python 2.7 from http://www.python.org and build it? Or, are you using Python that came "pre-packaged" with a Linux distro?

The STAF Python support makefiles assume you downloaded Python from http://www.python.org and built it. The PYTHON_V27_LIBDIRS need to be set to $(PYTHON_V27_ROOT)/lib/python2.7/config (when running with Python that you've downloaded and built) because that's where libpython2.7.a is located and it needs to link with it.

We have no problems using PYSTAF.so that is provided in the STAF V3.4.7 build for Linux. Are you sure you are really using the Python 2.7 version of PYSTAF.so when using the STAF Python support provided? Note that you can choose which version of Python support is used when installing STAF (the default is STAF Python 2.2 support). What is the error that you get when you run a simple Python script that tries to register with STAF and what install options did you select when installing STAF?

[Garron Moore]

I'm using Python 2.7 that I downloaded and built. However, I built python using the --shared option which builds the .so instead of the .a. PySTAF works just fine under typical usage of registering a STAF handle and submitting commands.

The issue that I'm running into is related to embedding the python interpreter in a C STAF service. I realize this isn't a typical usage and it appears to be because PYSTAF.so is missing some symbols.

I understand if this isn't something you're able to accomodate. I'm hoping at some point my employer will allow me to contribute back some of the work I've done allowing services to be written in python. It would be nice if that functionality were able to work without rebuilding STAF.

[Kevin Goodsell]

I want to emphasize that this is a problem with the *binary* download
available here, on SourceForge.

You can verify this problem with ldd -r, as described in the initial
report. I understand that you may not have run into any visible
consequences of this problem, but the proof is in the ldd output. If you
happened to have a STAF service that loaded the Python interpreter and
imported PYSTAF, I assume you'd get an error at that point.

Again, this is NOT a problem with an end-user building STAF. It's a
problem with the packages that are pre-built and distributed on
SourceForge.