ARM (Raspberry Pi 4) error on import: undefined symbol: __atomic_fetch_sub_8

Hi,

I was trying to use pynng on a raspberry pi 4 running 32bit raspbian buster and it compiled and installed just fine. I however got the following error when importing pynng:

Python 3.7.3 (default, Apr  3 2019, 05:39:12) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pynng
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/pi/oprint/lib/python3.7/site-packages/pynng/__init__.py", line 3, in <module>
    from ._nng import lib, ffi
ImportError: /home/pi/oprint/lib/python3.7/site-packages/pynng/_nng.abi3.so: undefined symbol: __atomic_fetch_sub_8

I found a similar problem in a github issue from opencv (https://github.com/opencv/opencv/issues/15278). One proposed workaround was to preload libatomic, which indeed worked:

(oprint) pi@mprint:~ $ LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/libatomic.so.1 python
Python 3.7.3 (default, Apr  3 2019, 05:39:12) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pynng
>>> 

There is also a related issue+merged PR in the upstream nng repo: https://github.com/nanomsg/nng/issues/1195

This however did not fix the problem for me when updating the nng_rev to the latest master. Also it seems the problem was build related and not occuring during runtime.

I am struggling with understanding how pynng wraps nng and how to further debug the issue. Any help appreciated 😃

[codypiersall]

I was wondering how a proper solution would look like, adding a platform check in build_pynng.py or some cmake magic like in the nng library?

That’s a great question and I’m open to input. For now I added a change to link libatomic… in a pretty hacky way, and better fixes are welcome. (The change I made is https://github.com/codypiersall/pynng/commit/ac4d0a603107b2646d4731f4f65a7fde2fc433a3 if anyone wants to check it out)

The reason this happens is that I am building the upstream libnng as a static library, which essentially throws away all the information that Garrett’s carefully crafted CMakeLists.txt file has about what libraries need to be linked. The reason I build and link it statically instead of a shared library is that it makes vendoring the .whl files really easy; no external dependencies, and everything is just vendored right in there.

It turns out it is possible to include shared libs in .whl files, at least on Linux, but I think for now it’s just easier to track what libraries need to be linked manually instead of trying to vendor.

I’m closing for now because the change I made just now should fix this.

[cpresty]

Hi @codypiersall,

Thanks ever so much for the quick response and explanation. That all makes sense, although I’m a C++ dev by trade and fairly new to Python so haven’t played with LD_PRELOAD before now. Hadn’t spotted that it was actually a command line with that declaration BEFORE the “python” program call and I could just add my command line parameters on the end. Linux is strange and I’ve had a long day 😃

Thanks, I’m up and running now.

Thanks for the awesome library!