elastic
PHP Startup: Unable to load dynamic library 'elastic_apm.so' (tried: /usr/lib/php/20180731/elastic_apm.so (/usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by /usr/lib/php/20180731/elastic_apm.so))
PHP Startup: Unable to load dynamic library 'elastic_apm.so' (tried: /usr/lib/php/20180731/elastic_apm.so (/usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by /usr/lib/php/20180731/elastic_apm.so))
Same issue on Debian 9, using PHP 7.4 from Sury (might be used by all Debian and Ubuntu installations as almost nobody would stay with the default one from the distro).
PHP Warning: PHP Startup: Unable to load dynamic library '/opt/elastic/apm-agent-php/extensions/elastic_apm-20190902.so' (tried: /opt/elastic/apm-agent-php/extensions/elastic_apm-20190902.so (/usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by /opt/elastic/apm-agent-php/extensions/elastic_apm-20190902.so)), /usr/lib/php/20190902//opt/elastic/apm-agent-php/extensions/elastic_apm-20190902.so.so (/usr/lib/php/20190902//opt/elastic/apm-agent-php/extensions/elastic_apm-20190902.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Investigated and libcurl.so.4 in Debian 9 is actual from libcurl v3, and there is no way to replace with libcurl v4 as would break all system. Compiling from sources might be the only way on old systemd. Altough, other software, like nodejs installed with nvm (precompiled binaries), do not complain on using it, as they might not be enforcing to discover by CURL_OPENSSL_4 presence of it. I am not sure exactly how Debian is packing libcurl*, but sure thing apps needing either v3 or v4 can run, just by having libcurl3 installed.
I can confirm that works perfect if compiled from sources on Debian 9. Possible needs to be done on older Ubuntu (18, 16) as well.
I can confirm that the bundled .deb file is not compatible with Debian 9, whereas building from source on Debian 9 works fine.
If I'm correct, the package is build using the php:7.4-fpm image, which uses Debian 10 as a base image. I guess it uses a too new openssl/curl version to be compatible with Debian 9?
Actually, this is build using libcurl4, which might cause this failures (IIRC, libcurl3 is used in Debian 9?): https://github.com/elastic/apm-agent-php/blob/83bec1aa22fa3fbd4cebfbc3c0eede3c014fca80/Dockerfile#L10
I have tried to install the APM agent on Ubuntu 16.04.6 LTS and it is not working with the same error.
The PHP is 7.3 installed from ondrej repository
PHP Warning: PHP Startup: Unable to load dynamic library '/opt/elastic/apm-agent-php/extensions/elastic_apm-20180731.so' (tried: /opt/elastic/apm-agenxtensions/elastic_apm-20180731.so (/usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by /opt/elastic/apm-agent-php/ens/elastic_apm-20180731.so)), /usr/lib/php/20180731//opt/elastic/apm-agent-php/extensions/elastic_apm-20180731.so.so (/usr/lib/php/20180731//opt/elastigent-php/extensions/elastic_apm-20180731.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Is this issue still reproducible for anybody with the latest version of the agent (v1.5 at the moment)?
Yes, the following Dockerfile allows you to reproduce this issue:
FROM debian:9
RUN apt-get update && apt-get install -y apt-transport-https ca-certificates curl \
&& curl -fsS https://packages.sury.org/php/apt.gpg | tee /etc/apt/trusted.gpg.d/php.gpg \
&& sh -c 'echo "deb https://packages.sury.org/php/ stretch main" > /etc/apt/sources.list.d/php.list'
RUN apt-get update && apt-get install -y php8.0-common php8.0-cli
RUN curl -fsSL https://github.com/elastic/apm-agent-php/releases/download/v1.5/apm-agent-php_1.5_all.deb > /tmp/apm-gent-php.deb \
&& dpkg -i /tmp/apm-gent-php.deb
CMD ["php", "--version"]
Running this image produces:
PHP Warning: PHP Startup: Unable to load dynamic library '/opt/elastic/apm-agent-php/extensions/elastic_apm-20200930.so' (tried: /opt/elastic/apm-agent-php/extensions/elastic_apm-20200930.so (/usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_4' not found (required by /opt/elastic/apm-agent-php/extensions/elastic_apm-20200930.so)), /usr/lib/php/20200930//opt/elastic/apm-agent-php/extensions/elastic_apm-20200930.so.so (/usr/lib/php/20200930//opt/elastic/apm-agent-php/extensions/elastic_apm-20200930.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP 8.0.18 (cli) (built: Apr 21 2022 10:50:46) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.18, Copyright (c) Zend Technologies
with Zend OPcache v8.0.18, Copyright (c), by Zend Technologies
@wouterj Thank you very much for providing the setup to reproduce the issue.
It seems that in your docker image installed libcurl.so.4 contains CURL_OPENSSL_3 while the agent requires CURL_OPENSSL_4. The same situation is mentioned for example here. I followed the workaround from the above link by replacing debian:9 with debian:buster-slim and it fixed the issue.
I think it is safe to close this issue as "won't fix" and indicate the requirement for openssl v4 in the setup documentation.
Debian 9/Stretch is oldoldstable and more tools are stopping the support (because of this, we recently upgraded our servers). If necessary, compiling from source using openssl v3 seems to work fine on Debian 9.
I think it is safe to close this issue as "won't fix" and indicate the requirement for openssl v4 in the setup documentation.
Debian 9/Stretch is oldoldstable and more tools are stopping the support (because of this, we recently upgraded our servers). If necessary, compiling from source using openssl v3 seems to work fine on Debian 9.
I would clearly explain in the documentation requirement to compile it on older distributions versions. There are companies that still use older versions of PHP and Linux distributions, and long term support used from Zend (3+ years supported PHP after community support end).
You see, a combination of Ubuntu ESM and Enterprise PHP gives us more reasonable longer time for enterprise developed applications. I think that actually this is also needed by companies using lager ELK clusters for their needs.
Closing as "won't fix" for now because now it's not directly possible to build with dependency on libcurl.so.3 Please let us know if it's an issue and we will revisit it.