php73 modules: error: expected '(' after 'asm'

[jvmyers]

Mac OS X El Capitan 10.11.6 MacBook Pro Mid-2009

Upgrading from php73 to php74 - all modules upgrade fine except php74-curl, which fails to build:

vvvvvvvvvv

sh-3.2# port install php74-curl
--->  Computing dependencies for php74-curl
--->  Fetching archive for php74-curl
--->  Attempting to fetch php74-curl-7.4.13_0.darwin_15.x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/php74-curl
--->  Attempting to fetch php74-curl-7.4.13_0.darwin_15.x86_64.tbz2 from https://lil.fr.packages.macports.org/php74-curl
--->  Attempting to fetch php74-curl-7.4.13_0.darwin_15.x86_64.tbz2 from https://mse.uk.packages.macports.org/php74-curl
--->  Fetching distfiles for php74-curl
--->  Attempting to fetch php-7.4.13.tar.xz from http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/php74
--->  Verifying checksums for php74-curl                                             
--->  Extracting php74-curl
--->  Configuring php74-curl
--->  Building php74-curl
Error: Failed to build php74-curl: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_php/php74-curl/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port php74-curl failed

main.log attached:

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_php/php74-curl/main.log

[jvmyers]

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_php/php74-curl/main.log

[ryandesign (Ryan Carsten Schmidt)]

I noticed this with some other modules on our build server when using these older compilers.

/opt/local/include/php74/php/Zend/zend_operators.h:523:10: error: expected '(' after 'asm'
        __asm__ goto(
                ^

I haven't yet investigated.

Oddly we did not experience the problem with php74-curl @7.4.13 on Darwin 15 on our build server.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

I noticed this with some other modules on our build server when using these older compilers.

Like php73-rar: ​https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/129274/steps/install-port/logs/stdio

[ryandesign (Ryan Carsten Schmidt)]

It looks like php73 and later are now using __asm__ goto in the implementation of zend_always_inline. ​This old llvm bug report from 2012 says that at that time clang didn't support __asm__ goto and there was no plan to add it. Support for __asm__ goto was finally ​added in 2019 and included in llvm 9. I guess that explains why it fails to build with clang from Xcode 8 on El Capitan, but doesn't explain why it succeeds when building with earlier clangs from earlier Xcodes on earlier OS X versions.

zend_always_inline has several alternative implementations, only some of which use __asm__ goto. I also see a define called HAVE_ASM_GOTO. In our El Capitan binary build of php73 @7.3.28 I see that /opt/local/include/php73/php/main/php_config.h contains #define HAVE_ASM_GOTO 1 and the configure output contains checking for asm goto... yes. That would appear to be wrong. I don't see that in php74 so maybe they fixed this already but didn't release a new version of php73 containing the fix.

[ryandesign (Ryan Carsten Schmidt)]

Ah... At the time this ticket was filed there was ​a php bug that required us to compile php 7.3 and later with a newer MacPorts compiler on El Capitan only. That newer MacPorts clang supports __asm__ goto so that result was recorded in php's php_config.h. But those results were wrong when later compiling php extensions with Xcode clang.

After this ticket was filed the php bug was fixed in php 7.4 and later but because it was not a security bug and php 7.3 is receiving security fixes only the fix will never be backported to php 7.3 so we will forever need to compile php 7.3 with a newer MacPorts clang.

I suppose the lesson is that we should ensure that php modules get compiled with the same compiler that php was compiled with. So any compiler blacklisting should probably be moved or copied from the php portfile into the php-1.1 portgroup.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

I suppose the lesson is that we should ensure that php modules get compiled with the same compiler that php was compiled with.

I have filed ​https://bugs.php.net/bug.php?id=81124 to see if that requirement can be removed.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

the fix will never be backported to php 7.3 so we will forever need to compile php 7.3 with a newer MacPorts clang.

Or we could backport the fix ourselves. I had not done so because it is a huge patch (their patch for php 7.4 is almost 1MB) but it can be bzip2 compressed (to about 50KB). Their patch for php 7.4 does not simply apply to 7.3 so I may need to use re2c 0.15.3 to regenerate the parsers myself to recreate a patch for 7.3.

[ryandesign (Ryan Carsten Schmidt)]

In 92850e50480bbbdd024f244140e52cb4271dd033/macports-ports (master):

php73: Avoid need for newer compiler on El Capitan

Most versions of Xcode clang on El Capitan miscompile the datetime
parsers that were generated with re2c 2.0.3 resulting in a runtime hang.
Rather than blacklisting Xcode clang for this reason, regenerate the
parsers with re2c 0.15.3. Installing and using re2c 0.15.3 is faster
than installing a new version of clang.

See: #61351

Certain details about the compiler that was used to compile php are
recorded in php_config.h. This causes problems if the compiler used to
compile php is not the same as the compiler used to compile a php
extension later.

Closes: #62022