I did a diff of this file between beta and rc and the result is:

❯ diff /Users/mIREK/compile/php8/php-8.0.0rc1/ext/fileinfo/fileinfo.c /Users/mIREK/compile/php8/php-8.0.0beta3/ext/fileinfo/fileinfo.c
74,75c74,75
< 		zend_throw_error(NULL, "Invalid finfo object"); \
< 		RETURN_THROWS(); \
---
>         	php_error_docref(NULL, E_WARNING, "The invalid fileinfo object."); \
> 		RETURN_FALSE; \
273c273
< 		php_error_docref(NULL, E_WARNING, "Failed to load magic database at \"%s\"", file);
---
> 		php_error_docref(NULL, E_WARNING, "Failed to load magic database at '%s'.", file);
385c385
< 			php_error_docref(NULL, E_WARNING, "Failed to load magic database");
---
> 			php_error_docref(NULL, E_WARNING, "Failed to load magic database.");
447c447
< 				zend_argument_type_error(1, "must not contain any null bytes");
---
> 				zend_argument_type_error(1, "must not contain null bytes");

So before it was Just warning and now it throws error, but I am not any C developer, I just can see that this was changed...

> /opt/local/include/magic.h

Apparently, the build includes the system header, although
that is undesired.  I think we want

 ext/fileinfo/fileinfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ext/fileinfo/fileinfo.c b/ext/fileinfo/fileinfo.c
index 0a4ee3c34e..39343f06fc 100644
--- a/ext/fileinfo/fileinfo.c
+++ b/ext/fileinfo/fileinfo.c
@@ -19,7 +19,7 @@
 #endif
 #include "php.h"
 
-#include <magic.h>
+#include "magic.h"
 /*
  * HOWMANY specifies the maximum offset libmagic will look at
  * this is currently hardcoded in the libmagic source but not exported

Also for PHP 7.3+.

I applied the diff change in ext/fileinfo/fileinfo.c, rerun configure and compile, but it still uses the /opt/local/include/magic.h

Is there any way of setup/configuration to force it use this the internal libmagic and this file?

Maybe #include "libmagic/magic.h"?

I tried this
#include "libmagic/magic.h",

and seemed to be working but then I had similar issues in GD library in multiple files. I also used the local links and I was able to finally compiled it, but just calling PHP in cli produces segmentation faut.

Strage is that beta worked fine for me without issues an RC not. So I wait for another release...

Not sure what exactly might be wrong with GD, but that libmagic
include line looks wrong to me.  Isn't that a bug that should be
fixed for PHP-7.3[1] upwards?

[1] <https://github.com/php/php-src/blob/php-7.3.23/ext/fileinfo/fileinfo.c#L24>

I am encountering this as well as I try to add php 8.0.0 to MacPorts. libmagic (part of file 5.39) is also installed with MacPorts, providing /opt/local/include/magic.h. You appear to bundle a modified libmagic with php and want to include its headers.

The problem may be specific to the versions of clang shipped with Xcode 12 and later, which have turned implicit declaration of function into an error. It used to be just a warning.

The problem appears to be that the -I flags are in the wrong order. Here is the compile line:


/bin/sh /path/to/php-8.0.0/libtool --silent --preserve-dup-deps --mode=compile ccache /usr/bin/clang -Iext/fileinfo/ -I/path/to/php-8.0.0/ext/fileinfo/ -I/path/to/php-8.0.0/include -I/path/to/php-8.0.0/main -I/path/to/php-8.0.0 -I/path/to/php-8.0.0/ext/date/lib -I/opt/local/include/libxml2 -I/opt/local/include -I/opt/local/include/editline -I/path/to/php-8.0.0/TSRM -I/path/to/php-8.0.0/Zend  -I/opt/local/include -no-cpp-precomp  -Wall -Wextra -Wno-strict-aliasing -Wno-implicit-fallthrough -Wno-unused-parameter -Wno-sign-compare -pipe -Os -Werror=implicit-function-declaration -arch x86_64 -fvisibility=hidden -DZEND_SIGNALS   -I/path/to/php-8.0.0/ext/fileinfo/libmagic -c /path/to/php-8.0.0/ext/fileinfo/fileinfo.c -o ext/fileinfo/fileinfo.lo 


Note that -I/opt/local/include (which comes from user-specified (or in my case MacPorts-specified) CPPFLAGS) precedes project-local paths like -I/path/to/php-8.0.0/ext/fileinfo/libmagic. All project-local -I flags should precede global -I flags so that you don't accidentally include system headers instead of your local files.

This problem does not happen with php 7.4.13 or earlier. There the compile line is:


/bin/sh /path/to/php-7.4.13/libtool --silent --preserve-dup-deps --mode=compile ccache /usr/bin/clang -I/path/to/php-7.4.13/ext/fileinfo/libmagic -Iext/fileinfo/ -I/path/to/php-7.4.13/ext/fileinfo/ -DPHP_ATOM_INC -I/path/to/php-7.4.13/include -I/path/to/php-7.4.13/main -I/path/to/php-7.4.13 -I/path/to/php-7.4.13/ext/date/lib -I/opt/local/include/libxml2 -I/opt/local/include -I/opt/local/include/editline -I/path/to/php-7.4.13/TSRM -I/path/to/php-7.4.13/Zend  -I/opt/local/include -no-cpp-precomp  -pipe -Os -Werror=implicit-function-declaration -arch x86_64 -fvisibility=hidden -Wall -Wno-strict-aliasing -DZEND_SIGNALS   -c /path/to/php-7.4.13/ext/fileinfo/fileinfo.c -o ext/fileinfo/fileinfo.lo 


Note how -I/path/to/php-7.4.13/ext/fileinfo/libmagic appears earlier in the compile line, before -I/opt/local/include, thus ensuring that your modified copy of magic.h gets used instead of a standard one that might be installed in a system directory.

I'm not sure what changed in php 8 to cause the order of -I flags to change.

Until the order of -I flags is fixed in the php build system, a workaround for the user could be to deactivate or uninstall libmagic before installing php 8. Another workaround for the user could be to add -isystem/opt/local/include to CPPFLAGS, which will override any existing -I/opt/local/include to ensure /opt/local/include gets placed at the end of the search path regardless of where it appears on the compile line.

@ryandesign - I am waiting for the MacPorts version :D

Anyway, I compiled the released 8.0.0 version on the latest macOS BigSur and it died on the GD Library on exactly the same issue.

Then I compiled PHP without GD Library and image support and it went fine. It works, later I even compiled some pecl extensions like igbinary, redis, APCu and this also worked.

I didn't have time to investigate further, but with this 'configure' I used:

'./configure' '--prefix=/opt/local' '--sysconfdir=/opt/local/php80' '--program-suffix=80' '--with-config-file-path=/opt/local/etc/php80' '--with-config-file-scan-dir=/opt/local/etc/php80/conf.d' '--enable-bcmath' '--enable-calendar' '--enable-ftp' '--enable-fpm' '--enable-intl' '--enable-mbregex' '--enable-mbstring' '--enable-mysqlnd' '--enable-pcntl' '--enable-soap' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable-opcache' '--with-curl' '--with-fpm-user=_www' '--with-fpm-group=_www' '--with-iconv=/opt/local' '--with-libxml' '--with-layout=GNU' '--with-mysql-sock=/tmp/mysql.sock' '--with-openssl' '--with-pdo-mysql=mysqlnd' '--with-pdo-pgsql=/opt/local/lib/postgresql13' '--with-pdo-sqlite' '--with-pgsql=/opt/local/lib/postgresql13' '--with-sqlite3' '--with-xsl' '--with-zip' '--with-zlib'

As I said, putting -isystem/opt/local/include in CPPFLAGS when you call ./configure works around the issues. php80 will be in MacPorts shortly and I'm including that workaround there.

Well, I guess we now found out why it was adding the extension CFLAGS to the start rather than the end...

It sounds like it will be necessary to filter the flags and place some of them before (-I) and some after (-W).

Always great when there's a random mix of earlier options and later options taking priority...

FYI issue remains in php 8.0.7 and 8.1.0alpha1.