Edit report at https://bugs.php.net/bug.php?id=77463&edit=1
ID: 77463
User updated by: office at vargapeter dot net
Reported by: office at vargapeter dot net
Summary: gcc warning & PHP doesn't start using own openssl &
curl
Status: Open
Type: Bug
Package: Compile Warning
Operating System: SLES 12.4
PHP Version: 7.2.14
Block user comment: N
Private report: N
New Comment:
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?
Previous Comments:
------------------------------------------------------------------------
[2019-02-20 13:49:31] 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:31:01] 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 00:45:31] 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-19 23:36:26] 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-01-18 14:57:42] cmb@php.net
See <https://bugs.php.net/bugs-generating-backtrace.php>.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=77463
--
Edit this bug report at https://bugs.php.net/bug.php?id=77463&edit=1