Closed nikspyratos closed 3 months ago
I'm much more inclined to say there is something wrong with your environment since static builds in CI appear to work fine. That being said, getting an environment in the right conditions when you're trying to do it on a computer you actually need to work on can be a bit frustrating (from experience). I highly recommend using a build environment specific to building this (such as a VM or CI).
That being said, it seems you resolved most of your issues? I'm unclear what the actual issue is here.
You say the issue is ./frankenphp.h:4:10: fatal error: 'Zend/zend_types.h' file not found
but your logs indicate you're trying to install an extension that doesn't exist on the current platform: Extension [hash] not exist !
Can you clarify what issue you're running into?
It's maybe a bug in the extension detection system of our shell script. Could you try to explicitly set PHP_EXTENSIONS
? Could you also copy your composer.json
please?
For the slow builds, try to disable UPX.
Can you clarify what issue you're running into?
I've run into three different problems here, the logs for the GH template are just the first one.
That being said, it seems you resolved most of your issues? I'm unclear what the actual issue is here.
I didn't, I gave up on the third and though it might be worth opening this issue as I surely can't be the only one with this problem. I get the impression macOS support isn't a priority, and I agree it shouldn't really be since prod is most likely going to be the linux build for most, but it's still worth having this report at least posted so others can follow the same trail.
Could you try to explicitly set PHP_EXTENSIONS
Sorry I wasn't clear in my description, I did do that and stripped out the defaults by hand. Then I got down to issue #2. Yes on my todo list for next time is not using UPX.
The warnings are not important and can be safely ignored.
Issue 2 is weird and looks like a static-php-cli issue when building the zip extension (it happens). Could you try deleting entirely the dist/
(or starting with a fresh install) with PHP_EXTENSIONS and NO_COMPRESS explicitly set?
Anyway, we need to do a patch to filter out builtin extensions (like hash
in your case).
The warnings are not important and can be safely ignored.
The search path ones? It wouldn't proceed with the build until I resolved that. The bzip and search path issue went away when I removed the sed
part of line 123.
Anyway, we need to do a patch to filter out builtin extensions (like hash in your case).
Yep. I wouldn't mind taking a crack at it over the weekend with some bash-fu as well.
Could you try deleting entirely the dist/ (or starting with a fresh install) with PHP_EXTENSIONS and NO_COMPRESS explicitly set?
Same as issue 3 before - still goes all the way to ./frankenphp.h:4:10: fatal error: 'Zend/zend_types.h' file not found
on the go build
command. The zend_types.h
file is definitely there though 🤔 If the problem is related to my aforementioned sed
change then it's going to be a bit of a catch-22 to build.
@nikspyratos
Issue 1: static-php-cli can consider these builtin extensions (always enabled) as redundant input, and put them as warning messages if needed. (next version of spc)
Issue 2:
Undefined symbols for architecture arm64:
"_BZ2_bzCompress", referenced from:
_process in libzip.a[114](zip_algorithm_bzip2.c.o)
It seems it's compiling zip extension with bzip2 support, and compile again without bzip2 problem. Just make sure every different combination of extensions has a clean buildroot (rm -rf buildroot source
before different build). And also duplicates search paths for the linker will not affect anything.
If you still get the same error when compiling, you can turn on full output logging and find all the arguments to the bin/spc build command line and print them out.
It seems it's compiling zip extension with bzip2 support, and compile again without bzip2 problem. Just make sure every different combination of extensions has a clean buildroot (
rm -rf buildroot source
before different build). And also duplicates search paths for the linker will not affect anything.
🤷♂️ That error only happens when those linker warnings are also present, and again removing sed s#-I/#-I"${PWD}"/buildroot/#g)
from CGO_CFLAGS
in the build script gets rid of both issues. If that doesn't make sense, I've got no idea, that's just what I'm experiencing.
here's the full output that I have, starting from a clean buildroot.
If you still get the same error when compiling, you can turn on full output logging and find all the arguments to the bin/spc build command line and print them out.
--debug
is already an enabled option on the spc
commands. Is there another arg for fuller logging?
@nikspyratos Could you provide this line of log (argv: ****
)? This will show what arguments are passed to static-php-cli.
$ bin/spc build $PHP_EXTENSIONS --build-cli --build-micro --debug --with-libs=$PHP_EXTENSION_LIBS
_ _ _ _
___| |_ __ _| |_(_) ___ _ __ | |__ _ __
/ __| __/ _` | __| |/ __|____| '_ \| '_ \| '_ \
\__ \ || (_| | |_| | (_|_____| |_) | | | | |_) |
|___/\__\__,_|\__|_|\___| | .__/|_| |_| .__/ v2.2.3
|_| |_|
[14:56:56] [DEBU] argv: bin/spc build hash,opcache,mbstring,zip --build-cli --build-micro --debug --with-libs=bzip2,freetype,libavif,libjpeg,liblz4,libwebp,libzip
EDIT: Issue 1 Extension [hash] not exist !
bug has been fixed via https://github.com/crazywhalecc/static-php-cli/pull/473 .
Nice!
Here's the log:
[15:27:41] [DEBU] argv: ./bin/spc build --debug --enable-zts --build-embed ctype,curl,dom,fileinfo,filter,iconv,intl,libxml,mbstring,openssl,session,tokenizer,xmlreader,zip --with-libs=bzip2,freetype,libavif,libjpeg,liblz4,libwebp,libzip,brotli
I just figured out what was causing the bzip2 link error.
zip,xxxx
extension (not include bz2
and zlib
extension), with additional libs bzip2,yyy
, if you build --build-cli
, the libzip requires bzip2, and zip does not require it for now.configure
check item zip_compression_method_supported
-> no
, and zip
extension will not support any additional algorithm.--build-embed
, same as --build-cli
, but this error only occurs when linking.bz2,zlib,zip
extensions at the same time. But I'll also adjust spc's deps config to prevent it.That worked! Thanks!
For this specific issue, I think it can be closed now, but I believe there are some lingering issues about how extensions are pulled/listed from the embedded application (at least on the local app)
The build was successful, but since it was completely relying on the output of composer check-platform-reqs
, it was missing extensions that should have been listed but weren't - for example PDO, as any artisan
command I ran first had issues of not finding the PDO
class.
So perhaps trying to auto-parse the extensions from a project isn't going to be as accurate as originally hoped, since many project dependencies don't include accurate extension requirements.
That's a good opportunity to fix the composer.json
of these projects to add the missing requirements 😃
It's always possible to use the environnement variable for specific needs.
100%. Will keep playing around with this, thanks for all the help!
What happened?
Heyo. Been playing around with static builds. Got the Linux one with Docker working fine - though haven't yet tested the binary, and the build was suuuuper slow (#835). Next I wanted to try out the macOS build. Been fighting through a few issues and I'm at the point where this stuff is above my head. If nothing else I'd like to report this I'm also using Laravel Herd, which AFAICT is a normal build of PHP.
Issue 1:
composer check-platform-reqs
(added in 404086d) has a chance to put builtin PHP extensions in thePHP_EXTENSIONS
var, and./bin/spc
seems to not be happy with that (on macOS at least). Stripping out the builtins from the extensions list seems to solve the problem.Issue 2: Once the extensions thing was fixed, the go build failed because something about how the
CGO_FLAGS
variable is built duplicates search paths for the linker. After some consultation with Claude AI, it suggested removing thesed
part, which worked for me. The error was:Issue 3: Lastly, I'm getting the same
./frankenphp.h:4:10: fatal error: 'Zend/zend_types.h' file not found
error as in #825. At this point I gave up. From that issue and the compile docs linked, it suggests that the static builds are an alternative to compiling from sources, so my understanding is that I shouldn't need to go as deep as downloading the PHP source for this?Build Type
Custom (tell us more in the description)
Worker Mode
No
Operating System
macOS
CPU Architecture
Apple Silicon
PHP configuration
Relevant log output