php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #78681 Can't locate API module structure `php8_module' in file /BUILD/php-8.0.0/libs/l
Submitted: 2019-10-17 21:08 UTC Modified: 2019-10-18 09:16 UTC
From: bugreports at gmail dot com Assigned: nikic (profile)
Status: Closed Package: Apache2 related
PHP Version: master-Git-2019-10-17 (Git) OS: Linux
Private report: No CVE-ID: None
 [2019-10-17 21:08 UTC] bugreports at gmail dot com
Description:
------------
can you please rename the module properly so that templatd environments parsing the major vesion out of the cli binary are working as expected

i prepared all the build and pgo profiling stuff long ago php major agnostic

Can't locate API module structure `php8_module' in file /BUILD/php-8.0.0/libs/libphp8.so: /BUILD/php-8.0.0/libs/libphp8.so: undefined symbol: php8_module


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-10-17 21:20 UTC] bugreports at gmail dot com
how do you load the apapche module at all wehn even "php7_module" is not known

httpd: Syntax error on line 9 of /PHP-PGO/httpd.conf: Can't locate API module structure `php7_module' in file /BUILD/php-8.0.0/libs/libphp8.so: /BUILD/php-8.0.0/libs/libphp8.so: undefined symbol: php7_module
 [2019-10-17 21:40 UTC] requinix@php.net
-Assigned To: +Assigned To: nikic
 [2019-10-17 21:40 UTC] requinix@php.net
If you want your process to be major-agnostic then you should love that it's called "php_module".
https://github.com/php/php-src/commit/6e3600f41b95d97d11ef48f817e6389a4ee95091

What I don't know is whether that's a permanent change or only intended until PHP $major.0 is branched.
 [2019-10-17 22:35 UTC] bugreports at gmail dot com
well, 'php_module' would be cool but only in combination with libphp.so instead libphp8.so, i hate stuff like below from the bottom of my heart since many years :-)

<IfModule mod_php5.c>
 php_flag engine off
</IfModule>

<IfModule mod_php7.c>
 php_flag engine off
</IfModule>

<IfModule mod_php8.c>
 php_flag engine off
</IfModule>
 [2019-10-18 09:16 UTC] nikic@php.net
Do I understand correctly that the bug report here is that we should generate "libphp.so" rather than "libphp8.so", and nothing more? Or is there some additional issue?
 [2019-10-18 09:51 UTC] bugreports at gmail dot com
PHP5: php5_module, libphp5.so
PHP7: php7_module, libphp7.so
PHP8: php_module, libphp8.so

don't you see the inconsistency?

either stay at "php8_module" and "libphp8.so" as all the years before or one and for all stop the number nosense which makes configuartion and upgrade/downgrade harder then it could be

what you are currently doing is breaking templates on buildsystems which are designed to build and autotest/profile whatever with no real gain while a test for "libphp.so" would be easy to implement
 [2019-10-29 15:06 UTC] nikic@php.net
Automatic comment on behalf of nikita.ppv@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=ad53bacf3872c22919fc2620112ae64917f1c26a
Log: Fix bug #78681 by renaming libphp8.so to libphp.so
 [2019-10-29 15:06 UTC] nikic@php.net
-Status: Assigned +Status: Closed
 [2020-07-29 18:33 UTC] lzsiga at freemail dot c3 dot hu
Hi, I have the same problem: if the previous versions were able to include the major version number into the filename (libphp5.so, libphp7.so) also into the DT_SONAME header, why cannot version 8 do the same? Why does it generate libphp.so instead of libphp8.so?
 [2020-07-29 18:39 UTC] lzsiga at freemail dot c3 dot hu
Note: I could even bring up the idea of using standard major and minor version numbers like `libphp.so` and `libphp.so.8` being symlinks to `libphp.so.8.0.0`.
 [2020-07-29 18:54 UTC] bugreportsxyz at gmail dot com
because thanks god you don't need dozens of IfModule in the future to cover all major versions for the same thing
 [2021-06-07 15:30 UTC] arekm at maven dot pl
Note that this is breaking some use cases. For example I have 5 php versions installed, each one provides libphpX.so (so filenames don't conflicts). There are also 5 separate apache instances running, each loading one php so module version.

Making it all unversioned will break things for such scenario - filename conflicts.

Also it will no longer be possible to use one and (almost the) same config set for all apache instances (and only ifmodule based separate options for some php variants when needed).

(not a big deal for me since I can patch things the way I want but I'm letting you know that there are really different use cases)
 [2021-06-07 15:46 UTC] rtrtrtrtrt at dfdfdfdf dot dfd
> Note that this is breaking some use cases. For example I have 
> 5 php versions installed, each one provides libphpX.so 
> (so filenames don't conflicts). There are also 5 separate 
> apache instances running, each loading one php so module version.

and how do you deal with extensions in such a setup given that they are not compatible between versions and have conflictiong filenames?

i tell you: install the httpd-module and the extensions in a specific, versioned directory

> Also it will no longer be possible to use one and 
> (almost the) same config set for all apache instances 
> (and only ifmodule based separate options for some 
> php variants when needed)

<IfFile "modules/libphp7.so">
 LoadModule "php7_module" "modules/libphp7.so"
</IfFile>
<IfFile "modules/libphp.so">
 LoadModule "php_module" "modules/libphp.so"
</IfFile>
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sun Sep 19 00:03:39 2021 UTC