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

Edit report at https://bugs.php.net/bug.php?id=77463&edit=1 ID: 77463 Comment by: spam2 at rhsoft 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: > 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 Previous Comments: ------------------------------------------------------------------------ [2019-02-20 13:51:34] 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 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? .................................................................... ------------------------------------------------------------------------ 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