php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #80435 Bus Error compiling phar.phar on Apple M1
Submitted: 2020-11-27 20:59 UTC Modified: 2020-11-30 16:33 UTC
Votes:5
Avg. Score:4.8 ± 0.4
Reproduced:5 of 5 (100.0%)
Same Version:1 (20.0%)
Same OS:5 (100.0%)
From: cja987 at gmail dot com Assigned:
Status: Open Package: Compile Failure
PHP Version: 8.0Git-2020-11-27 (Git) OS: macOS 11
Private report: No CVE-ID: None
View Add Comment Developer Edit
Have you experienced this issue?
Rate the importance of this bug to you:

 [2020-11-27 20:59 UTC] cja987 at gmail dot com 
Description:
------------
Using the compile command shown in the test script below, compilation proceeds normally and it even builds some of the SAPIs, but once it gets to phar, things go sideways:

Generating phar.php
Generating phar.phar
PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled.
make: *** [ext/phar/phar.phar] Bus error: 10



Test script:
---------------
make distclean; ./buildconf && PATH=/opt/homebrew/opt/bison/bin:$PATH ./configure --with-iconv=/opt/homebrew/opt/libiconv && make -j10 YACC=/opt/homebrew/opt/bison/bin/bison

# The above shows another minor bug: I should not have to set YACC, 
# but the makefile sets it to just "bison" rather than the full path,
# which causes it to find the obsolete system bison in the path instead.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-11-27 21:01 UTC] cja987 at gmail dot com 
As requested, these values from the makefile:

PHP_PHARCMD_SETTINGS = -n -d 'open_basedir=' -d 'output_buffering=0' -d 
'memory_limit=-1' -d phar.readonly=0

PHP_PHARCMD_BANG = `$(top_srcdir)/build/shtool echo -n -- "$(INSTALL_ROOT)$(bindir)/$(program_prefix)php$(program_suffix)$(EXEEXT)";`
 [2020-11-30 14:54 UTC] nikic@php.net 
I suspect the build might be entirely borked, and the phar generation is just the first part that actually uses the produced binary.

Does running `sapi/cli/php -v` work? If so, does running `sapi/cli/php run-tests.php Zend -j8` produce any failures?
 [2020-11-30 16:33 UTC] cja987 at gmail dot com 
sapi/cli/php -v does work, but it does immediately get run over by the bus (error)  when running the test suite.  I can't convince gdb to install either, so there's not a lot that's debuggable.  Homebrew does build php successfully, and it appears it even applies a patch or two, so I'll work backwards from that.
 [2021-05-08 01:15 UTC] hao dot sun at arm dot com 
In my Apple M1 machine, using the method mentioned in this link(https://qiita.com/shirai_suguru/items/894dc1e71cbc96f4a857) would fix this bug.

$ brew install pcre2
$ ./configure --with-external-pcre=$(brew --prefix pcre2)
$ make
$ make test

Note: the link is in Japanese. you may need to translate it to English.
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved. 		Last updated: Sun Aug 07 15:05:45 2022 UTC