PHP :: Bug #77463 :: gcc warning & PHP doesn't start using own openssl & curl

Bug #77463

gcc warning & PHP doesn't start using own openssl & curl

Submitted:

2019-01-15 14:15 UTC

Modified:

2020-04-16 12:57 UTC

Votes:	2
Avg. Score:	4.0 ± 1.0
Reproduced:	1 of 1 (100.0%)
Same Version:	1 (100.0%)
Same OS:	1 (100.0%)

From:

office at vargapeter dot net

Assigned:

Status:

Not a bug

Package:

Compile Warning

PHP Version:

7.2.14

OS:

SLES 12.4

Private report:

CVE-ID:

None

View Developer Edit

Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.

Password:

Status:
Package:
Bug Type:
Summary:
From:	office at vargapeter dot net
New email:
PHP Version:		OS:

New Comment:

[2019-01-15 14:15 UTC] office at vargapeter dot net

Description:
------------
Compiling PHP 7.2.14 with gcc 8.2.0 produces lot of warnings when using openssl 1.1.0h and curl 7.63.0 which differ from the SLES 12.4 distribution versions and have been compiled into a separate directories.

I provide the path to the personalized curl and openssl versions to the ./configure script using
--with-openssl=/FaF/openssl
--with-curl=/FaF/curl

Also then, once PHP compiles and installs it cannot be started.
No error messages are logged in the Apache log file but Apache apparently crashes.

I set also the relative path to the personalized openssl and curl libraries for the linker using:
LDFLAGS="-Wl,--rpath=/FaF/openssl/lib -Wl,--rpath=/FaF/curl/lib" ./configure my-configuration

Using the distribution versions of openssl & curl work.
May be a problem when loading the personalized libraries?



Expected result:
----------------
No warnings and crash when starting the compiled PHP version.

Actual result:
--------------
/builds/php-7.2.14/ext/openssl/xp_ssl.c:965:3: warning: ‘TLSv1_client_method’ is deprecated [-Wdeprecated-declarations]
   return is_client ? TLSv1_client_method() : TLSv1_server_method();
   ^~~~~~
In file included from /FaF/openssl/include/openssl/ct.h:13,
                 from /FaF/openssl/include/openssl/ssl.h:61,
                 from /builds/php-7.2.14/ext/openssl/xp_ssl.c:34:
/FaF/openssl/include/openssl/ssl.h:1629:45: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_client_method(void)) /* TLSv1.0 */
                                             ^~~~~~~~~~~~~~~~~~~
/FaF/openssl/include/openssl/opensslconf.h:99:35: note: in definition of macro ‘DECLARE_DEPRECATED’
 # define DECLARE_DEPRECATED(f)    f __attribute__ ((deprecated));
                                   ^
/FaF/openssl/include/openssl/ssl.h:1629:1: note: in expansion of macro ‘DEPRECATEDIN_1_1_0’
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_client_method(void)) /* TLSv1.0 */
 ^~~~~~~~~~~~~~~~~~
/builds/php-7.2.14/ext/openssl/xp_ssl.c:965:3: warning: ‘TLSv1_server_method’ is deprecated [-Wdeprecated-declarations]
   return is_client ? TLSv1_client_method() : TLSv1_server_method();
   ^~~~~~
In file included from /FaF/openssl/include/openssl/ct.h:13,
                 from /FaF/openssl/include/openssl/ssl.h:61,
                 from /builds/php-7.2.14/ext/openssl/xp_ssl.c:34:
/FaF/openssl/include/openssl/ssl.h:1628:45: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_server_method(void)) /* TLSv1.0 */
                                             ^~~~~~~~~~~~~~~~~~~
/FaF/openssl/include/openssl/opensslconf.h:99:35: note: in definition of macro ‘DECLARE_DEPRECATED’
 # define DECLARE_DEPRECATED(f)    f __attribute__ ((deprecated));
                                   ^
/FaF/openssl/include/openssl/ssl.h:1628:1: note: in expansion of macro ‘DEPRECATEDIN_1_1_0’
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_server_method(void)) /* TLSv1.0 */
 ^~~~~~~~~~~~~~~~~~
/builds/php-7.2.14/ext/openssl/xp_ssl.c:968:3: warning: ‘TLSv1_1_client_method’ is deprecated [-Wdeprecated-declarations]
   return is_client ? TLSv1_1_client_method() : TLSv1_1_server_method();
   ^~~~~~
In file included from /FaF/openssl/include/openssl/ct.h:13,
                 from /FaF/openssl/include/openssl/ssl.h:61,
                 from /builds/php-7.2.14/ext/openssl/xp_ssl.c:34:
/FaF/openssl/include/openssl/ssl.h:1635:45: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_1_client_method(void)) /* TLSv1.1 */
                                             ^~~~~~~~~~~~~~~~~~~~~
/FaF/openssl/include/openssl/opensslconf.h:99:35: note: in definition of macro ‘DECLARE_DEPRECATED’
 # define DECLARE_DEPRECATED(f)    f __attribute__ ((deprecated));
                                   ^
/FaF/openssl/include/openssl/ssl.h:1635:1: note: in expansion of macro ‘DEPRECATEDIN_1_1_0’
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_1_client_method(void)) /* TLSv1.1 */
 ^~~~~~~~~~~~~~~~~~
/builds/php-7.2.14/ext/openssl/xp_ssl.c:968:3: warning: ‘TLSv1_1_server_method’ is deprecated [-Wdeprecated-declarations]
   return is_client ? TLSv1_1_client_method() : TLSv1_1_server_method();
   ^~~~~~
In file included from /FaF/openssl/include/openssl/ct.h:13,
                 from /FaF/openssl/include/openssl/ssl.h:61,
                 from /builds/php-7.2.14/ext/openssl/xp_ssl.c:34:
/FaF/openssl/include/openssl/ssl.h:1634:45: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_1_server_method(void)) /* TLSv1.1 */
                                             ^~~~~~~~~~~~~~~~~~~~~
/FaF/openssl/include/openssl/opensslconf.h:99:35: note: in definition of macro ‘DECLARE_DEPRECATED’
 # define DECLARE_DEPRECATED(f)    f __attribute__ ((deprecated));
                                   ^
/FaF/openssl/include/openssl/ssl.h:1634:1: note: in expansion of macro ‘DEPRECATEDIN_1_1_0’
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_1_server_method(void)) /* TLSv1.1 */
 ^~~~~~~~~~~~~~~~~~
/builds/php-7.2.14/ext/openssl/xp_ssl.c:976:3: warning: ‘TLSv1_2_client_method’ is deprecated [-Wdeprecated-declarations]
   return is_client ? TLSv1_2_client_method() : TLSv1_2_server_method();
   ^~~~~~
In file included from /FaF/openssl/include/openssl/ct.h:13,
                 from /FaF/openssl/include/openssl/ssl.h:61,
                 from /builds/php-7.2.14/ext/openssl/xp_ssl.c:34:
/FaF/openssl/include/openssl/ssl.h:1641:45: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_2_client_method(void)) /* TLSv1.2 */
                                             ^~~~~~~~~~~~~~~~~~~~~
/FaF/openssl/include/openssl/opensslconf.h:99:35: note: in definition of macro ‘DECLARE_DEPRECATED’
 # define DECLARE_DEPRECATED(f)    f __attribute__ ((deprecated));
                                   ^
/FaF/openssl/include/openssl/ssl.h:1641:1: note: in expansion of macro ‘DEPRECATEDIN_1_1_0’
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_2_client_method(void)) /* TLSv1.2 */
 ^~~~~~~~~~~~~~~~~~
/builds/php-7.2.14/ext/openssl/xp_ssl.c:976:3: warning: ‘TLSv1_2_server_method’ is deprecated [-Wdeprecated-declarations]
   return is_client ? TLSv1_2_client_method() : TLSv1_2_server_method();
   ^~~~~~
In file included from /FaF/openssl/include/openssl/ct.h:13,
                 from /FaF/openssl/include/openssl/ssl.h:61,
                 from /builds/php-7.2.14/ext/openssl/xp_ssl.c:34:
/FaF/openssl/include/openssl/ssl.h:1640:45: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_2_server_method(void)) /* TLSv1.2 */
                                             ^~~~~~~~~~~~~~~~~~~~~
/FaF/openssl/include/openssl/opensslconf.h:99:35: note: in definition of macro ‘DECLARE_DEPRECATED’
 # define DECLARE_DEPRECATED(f)    f __attribute__ ((deprecated));
                                   ^
/FaF/openssl/include/openssl/ssl.h:1640:1: note: in expansion of macro ‘DEPRECATEDIN_1_1_0’
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_2_server_method(void)) /* TLSv1.2 */
 ^~~~~~~~~~~~~~~~~~

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2019-01-18 11:25 UTC] nikic@php.net

-Status: Open +Status: Feedback

[2019-01-18 11:25 UTC] nikic@php.net

Would it be possible to provide a stack trace for the crash?

[2019-01-18 11:56 UTC] office at vargapeter dot net

-Status: Feedback +Status: Open

[2019-01-18 11:56 UTC] office at vargapeter dot net

How can I get it?

In the Apache log file is nothing. The Apache process just doesn't start. Please provide instruction how I can post here the stack trace.

Compiling it with the old distribution versions of curl and openssl works fine.

[2019-01-18 14:57 UTC] cmb@php.net

See <https://bugs.php.net/bugs-generating-backtrace.php>.

[2019-02-19 23:36 UTC] office at vargapeter dot net

The error when I run httpd -X from gdb:
httpd: Syntax error on line 233 of /etc/apache2/httpd.conf: Cannot load /usr/local/libexec/mod_dav_svn.so into server: /usr/local/libexec/mod_dav_svn.so: undefined symbol: dav_do_find_liveprop

-------------
Very strange:
-------------
When I DISABLE the PHP7 module then Apache starts!
I can access without any problem the SVN features in the browser.

Enabling PHP7 --> I get the above error message.
+++++++++++++++++++++++++++++++++++++++++++++++++

I am using the subversion 1.11.0 downloaded from the Apache site https://subversion.apache.org/download.cgi

However, it looks like something in libphp7.so prevents mod_dav_svn.so from loading and then it complains regarding the undefined symbol dav_do_find_liveprop.

Maybe this has something to do with this problem:
In PHP 7.2.13 I see while installation this:
libtool --mode=install install libphp7.la /usr/lib64/apache2-prefork/
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Suddenly, even nothing changed in the configuration string [I am using a script] this changed to:
libtool --mode=install install libphp7.la /usr/lib64/apache2/
                                          ^^^^^^^^^^^^^^^^^^^

So, first, I had to set a symbolic link to the new location of libphp7.la in order Apache does find it. But with this new location the mod_dav_svn.so problems started.

For each PHP version I use --with-apxs2=/usr/bin/apxs2-prefork

Any idea? I have this problems since I am using the personalized curl and openssl. I had to do this because I upgraded to SLES 12.4 and while the upgrade process the distribution curl developer version was removed and THEREFORE I am forced to used my own versions.

***************
I could fix it:
***************

When I compile a separated CURL [7.63.0] version USING the distribution openssl version into a DIFFERENT directory and use this [e.q. --with-curl=/php-curl-version] then IT WORKS and the above libtool commands are using the correct paths [e.q. /usr/lib64/apache2-prefork/].

....................................................................
Guys, can it be you have a bug in the above described constellation?
....................................................................

[2019-02-20 00:45 UTC] office at vargapeter dot net

This maybe an important information:

SLES 12.4 distribution openssl version is "OpenSSL 1.0.2p-fips  14 Aug 2018"

Compiling CURL with "OpenSSL 1.1.0h  27 Mar 2018" causes PHP to crash because it differs from the distribution.

[2019-02-20 13:31 UTC] spam2 at rhsoft dot net

well, when you mix different library versions with inter-dependencies within the same process you are in the hands of god - that's why you should avoid override system packages until you know exactly what you are doing

* the webserver loads openssl
* curl loads openssl
* php loads openssl

and pretty sure some other libraries in the mix also are linked against openssl

[2019-02-20 13:49 UTC] office at vargapeter dot net

Yeah, I realized openssl must have a "deal breaker" in the past versions because NOTHING works with the new version when it expects openssl 1.0.x

I may reconsider to use the most current openssl version because this is making me only lot of troubles. More or less the same with glibc - this must also run in a separated installation, otherwise the whole systems crashes...

However guys, compiling it with --enable-debug produces lot of compiler warnings...

[2019-02-20 13:51 UTC] office at vargapeter dot net

I pressed to fast the ENTER key.

BUT, what about the wrong directories used by libtool? This is what I mean. That it doesn't work, OK, due to the openssl mixture, but that the compile process is using wrong paths?

[2019-02-20 14:02 UTC] spam2 at rhsoft dot net

> More or less the same with glibc

frankly, when you try to replace glibc you are asking for troubles as loud as possible and i would ask myself when i start to replace such low level parts of a distribution the following questions:

* what do i gain with it
* is it worth the troubles
* is it worth having a unsupportable system given that nobody
  but you has the same setup for testing
* if i gain someting with it why i am using the wrong distribution

either i use something like Arch/Fedora or a LTS distribution and in case of an LTS distribution he whole point is to not have major bumps of everything

so stick with the distribution libraries and when you can't build a recent PHP with that versions for whatever reason consider upgrade the OS

anyways, this is hardly a PHP issue

[2019-02-20 14:15 UTC] office at vargapeter dot net

Yes my friend, you are right.

[2020-04-16 12:57 UTC] nikic@php.net

-Status: Open +Status: Not a bug

[2020-04-16 12:57 UTC] nikic@php.net

What I gather from the discussion is that the issue here was multiple different openssl versions getting loaded, as dependencies were linked against different openssl versions. As that wouldn't be an issue in PHP, I'm closing this issue, but please correct me if I misunderstood something and we need to address something on our side.

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Sat Dec 21 17:01:58 2024 UTC