2 replies to this topic

[gooseyard]

I was happy to spot the openssl 1.1.x-based versions of p4api in the r19.1 release, as this has been a longstanding problem for a p4python based application I maintain.

However, on x86_64 with openssl 1.1.1c, I get a runtime symbol error if I try to load P4 from the most recent p4python release built against p4api r19.1.

ImportError:<snipped>/lib/python3.7/site-packages/P4API.cpython-37m-x86_64-linux-gnu.so: undefined symbol: _ZNK12ClientScript7CanLoadEv

it looks like p4python's tools/PlatformInfo.py is missing the new libp4client_c.a, but patching PlatformInfo.py to include the new libraries in the linker invocation doesn't work, as it looks like some of the code (e.g. P4Result) has moved into the new libraries.

Any chance that a p4python release for r19.x is coming soon?

Thanks!

[bdurbin]

+1. This is also a problem for me and keeping me from using p4python. Instead I use a wrapper for the p4 command line client, which is not ideal.
I am hoping that a p4python that works with openssl 1.1.x can be uploaded to PyPI soon.

[gooseyard]

bdurbin, on 12 July 2019 - 04:51 PM, said:

+1. This is also a problem for me and keeping me from using p4python. Instead I use a wrapper for the p4 command line client, which is not ideal.
I am hoping that a p4python that works with openssl 1.1.x can be uploaded to PyPI soon.

I just discovered that this issue can be avoided by using the "glibc2.3" based p4api packages.

I'm not sure if its related, but the "glibc2.12" packages appear to have been built with a much more recent version of binutils, which causes link issues on older platforms like Ubuntu Trusty, which don't support type 0x2a relocations, but the 2.3-based package appears to work fine everywhere, so I'm just going to use those for now.