Hi Ben

To answer your second thing first, some extensions are built into the core, and cannot be disabled, these include:
 - Core (functions defined in Zend/, such as func_get_args())
 - date (used in various extensions, like standard)
 - pcre (like date, used in various extensions)
 - Reflection
 - SPL
 - Standard (the standard library, like array and string functions)

These is what we considering something that always must be available to anyone.

Back to the real question about --disable-all, it seems like (unlike Windows), that --disable-all will not disable default enabled SAPIs, why that is I cannot tell but I do know that at least one SAPI is required to build PHP (at least thats how it is on Windows). Maybe a clever mind can give some insight on why this is happening.

so 
1. why it's enable php-cgi and phpdbg? if I did disable-all ?
2. can I disable SPL and Reflection?

and can at least spl and reflection be also changed to support shared module build which makes a lot of sense for machines running a webserver as well as cli scripts

libphp7.so and /usr/bin should be only a tiny wrapper loading shared modules instead both contain a large part identical binary code

@ben

1) The bug is that --disable-all does not work on SAPIs, so thats why its not working.

2) No, SPL and reflection will not be made possible to be disabled

@reindl

No, SPL and Reflection will not be made possible to be compiled as shared, because, like I stated earlier, they are built-into the Core. These are some of the essential extensions we have decided that every install of PHP should have. Some extensions, tho not specifically mentioned, pcre, is used in the Windows implementation of mail(), the get_browser() function just to name one.

If we were to take out SPL for example, then in the next major version there would be no way to autoload classes/interfaces/traits, as the __autoload procedural function is going away, thats not cool.

Instead see these modules as part of the same, tho maybe confusing at first but they are what makes PHP, well PHP!

"These are some of the essential extensions we have decided that every install of PHP should have" is one thing and only means they need to be loaded  but that does not imply you need them statically in all SAPI's

in a package build it's no problem build them shared, include the extensions in php-common and ship a /etc/php.d/ ini-snippet which only means all the built SAPI's are smaller and share the so-files instead have the binary code duplicated multiple times

it's practically the same as mysqli can't work without mysqlnd and hence /etc/php.d/mysql.ini contains these lines

extension = "mysqlnd.so"
extension = "mysqli.so"

the difference is that these 286KB are shared between /usr/lib64/httpd/modules/libphp7.so and /usr/bin/php instead both binaries 286KB larger

-rwxr-xr-x 1 root root 286K 2017-10-21 02:57 /usr/lib64/php/modules/mysqlnd.so

Hi

Yes, thats true it would make the binary sizes smaller and logically make sense as we are talking about shared code between the different modules/SAPIs. However it is not possible currently, and most likely never will be, as the code base is built up around the fact that these extensions always are available, either way it would require "standard" to then depend on each of those modules anyway.

If you are interesting in working out a solution to change this, then I won't hold you and you are welcome to start a thread about it on internals@, but it is not relevant to this bug report, as the extensions part is a part of the current design.

I understand
but what about the bug that I use "--disable-all" and it's enable php-cgi and phpdbg?
it should be fixed...

$ ./configure --help | grep disable-all
  --disable-all           Disable all extensions which are enabled by default