FreeBSD Support Not Working - "Current OS is not supported"

[arcanumbridge]

I'm trying to build this on FreeBSD 14.0 and it is failing with an unsupported OS message.

> git clone https://github.com/crazywhalecc/static-php-cli.git
Cloning into 'static-php-cli'...
remote: Enumerating objects: 7446, done.
remote: Counting objects: 100% (952/952), done.
remote: Compressing objects: 100% (395/395), done.
remote: Total 7446 (delta 723), reused 630 (delta 557), pack-reused 6494
Receiving objects: 100% (7446/7446), 7.51 MiB | 6.87 MiB/s, done.
Resolving deltas: 100% (4670/4670), done.
> cd static-php-cli
> ls
bin/              captainhook.json  composer.lock     ext-support.md    phpstan.neon      README-zh.md*     src/              
box.json          composer.json     config/           LICENSE           README-en.md*     README.md*        tests/            
> chmod +x bin/setup-runtime
> bin/setup-runtime
Current OS is not supported
> uname -v
FreeBSD 14.0-RELEASE-p4 #13 4edf3b807: Thu Dec 28 22:04:05 EST 2023

If you know who worked on the FreeBSD support so I can reach out to them directly.

[crazywhalecc]

bin/setup-runtime is not supported on FreeBSD. Because currently I haven't built and hosted any FreeBSD static php binaries, auto-setup-runtime should not work. For FreeBSD, the best method currently is to use static-php-cli after installing PHP through the pkg package manager.

[arcanumbridge]

If the message could be updated to say use the builtin pkg / ports that would be helpful. I'll try to get this packaged up as a proper FreeBSD port so people can just pkg install static-php-cli on their systems.

I'm getting an error on build ./bin/spc build "openssl,phar,curl" --build-cli --enable-zts --debug:

--- libglib_2_0_la-gbookmarkfile.lo ---
  CC       libglib_2_0_la-gbookmarkfile.lo
--- libglib_2_0_la-gbytes.lo ---
  CC       libglib_2_0_la-gbytes.lo
--- libglib_2_0_la-gcharset.lo ---
  CC       libglib_2_0_la-gcharset.lo
--- libglib_2_0_la-gatomic.lo ---
gatomic.c:392:10: error: incompatible integer to pointer conversion passing 'gssize' (aka 'long') to parameter of type 'gpointer' (aka 'void *') [-Wint-conversion]
  return g_atomic_pointer_add ((volatile gpointer *) atomic, val);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./gatomic.h:170:46: note: expanded from macro 'g_atomic_pointer_add'
    (gssize) __sync_fetch_and_add ((atomic), (val));                         \
                                             ^~~~~
gatomic.c:416:10: error: incompatible integer to pointer conversion passing 'gsize' (aka 'unsigned long') to parameter of type 'gpointer' (aka 'void *') [-Wint-conversion]
  return g_atomic_pointer_and ((volatile gpointer *) atomic, val);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./gatomic.h:177:45: note: expanded from macro 'g_atomic_pointer_and'
    (gsize) __sync_fetch_and_and ((atomic), (val));                          \
                                            ^~~~~
gatomic.c:440:10: error: incompatible integer to pointer conversion passing 'gsize' (aka 'unsigned long') to parameter of type 'gpointer' (aka 'void *') [-Wint-conversion]
  return g_atomic_pointer_or ((volatile gpointer *) atomic, val);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./gatomic.h:184:44: note: expanded from macro 'g_atomic_pointer_or'
    (gsize) __sync_fetch_and_or ((atomic), (val));                           \
                                           ^~~~~
gatomic.c:464:10: error: incompatible integer to pointer conversion passing 'gsize' (aka 'unsigned long') to parameter of type 'gpointer' (aka 'void *') [-Wint-conversion]
  return g_atomic_pointer_xor ((volatile gpointer *) atomic, val);
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./gatomic.h:191:45: note: expanded from macro 'g_atomic_pointer_xor'
    (gsize) __sync_fetch_and_xor ((atomic), (val));                          \
                                            ^~~~~
4 errors generated.
*** [libglib_2_0_la-gatomic.lo] Error code 1

make[6]: stopped in /usr/home/amistry/devel/php-executable/static-php-cli/source/pkg-config/glib/glib
1 error

make[6]: stopped in /usr/home/amistry/devel/php-executable/static-php-cli/source/pkg-config/glib/glib

make[5]: stopped in /usr/home/amistry/devel/php-executable/static-php-cli/source/pkg-config/glib/glib

make[4]: stopped in /usr/home/amistry/devel/php-executable/static-php-cli/source/pkg-config/glib/glib

make[3]: stopped in /usr/home/amistry/devel/php-executable/static-php-cli/source/pkg-config/glib

make[2]: stopped in /usr/home/amistry/devel/php-executable/static-php-cli/source/pkg-config/glib

make[1]: stopped in /usr/home/amistry/devel/php-executable/static-php-cli/source/pkg-config

make: stopped in /usr/home/amistry/devel/php-executable/static-php-cli/source/pkg-config

[crazywhalecc]

Seems related to #380 (comment) .

Few people are currently using static-php on FreeBSD, many problems may not have been solved (those that have been solved on Linux or macOS). If you work on and use FreeBSD, I hope you can create a new issue or modify this issue to a Bug & TODO list to track FreeBSD related issues. FreeBSD lacks CI and I can only use local testing, updates may be slower than on other systems.

[arcanumbridge]

I think I'm going to try a different path and see if I can get the existing ports system to statically build everything. Looking at the SPC code it appears that most of the build infrastructure for SPC appears to be toggling configure and build flags, which the native ports system is already built to do. We'd just need to add STATIC=YES support to those dependent packages that don't support it. If that works, I'll then try to hook SPC into that.

[crazywhalecc]

@arcanumbridge I don't know much about FreeBSD's compilation environment, but many libraries on Linux don't like to be compiled statically. It would be best if most libraries supported static compilation on FreeBSD with a simple --enable-static=yes.

[arcanumbridge]

Yeah, pretty much, with a few small tweaks. I've just done a couple ports skeleton Makefile modifications (iconv, libxml2, pkg-config), but so far it's just adding the STATIC knob to push --enable-static=yes to configure.

[crazywhalecc]

I tried building static-php again on my local FreeBSD virtual machine today. There are still many link errors. The only thing I can confirm now is that the build issue with pkg config can be fixed: #426

I'm thinking it's time to refactor BSDBuilder.

Also, I don't actually know if I should link them completely statically (statically link all, including system libc, libm, libutil) or just dynamically link system libs.

[arcanumbridge]

I'd recommend leaving the system libs as dynamically linked (for now). FreeBSB does a pretty good job with backwards compatibility when you upgrade the OS, and there are always the compat packages to deliver older system libs to new systems. Even for the embedded/NanoBSD system, we can ensure the proper system libs are included. Getting the system libs correctly statically linked is possible (all systems have /rescue that is fully statically linked), but again leveraging the FreeBSD source build system would be the way to do this without having to create a bunch of duplicated code you'd then have to maintain. I'm slowly working on putting the pieces together. The goal is to get a statically linked php + frankenphp + crunchgen to create a single binary I can deliver.

[arcanumbridge]

php82-static.diff.gz

I've attached a diff for the php82 port skeleton. This will just get you a basic static PHP binary and embed lib with the default modules (for the FreeBSD port) compiled in. You'll need rebuild libxml2 with the STATIC option. cd /usr/ports/textproc/libxml2 && make config && make deinstall clean && make install clean and then select the STATIC option for the php82 port cd /usr/ports/lang/php82 && make config && make deinstall clean && make install clean. I'm still thinking about how to build the pecl modules statically within the context of the ports system.

[arcanumbridge]

Just an update. I'm currently working with the FreeBSD php ports maintainer to develop a skeleton similar to the above attachment for official inclusion in the tree. We're hoping to complete this sometime during the summer. eg. php83-static Once that is done, I'll see how best to clean-up BSDBuilder to hook into the ports system.

[crazywhalecc]

@arcanumbridge Do you know of any way to support Actions or hook into other CIs for testing FreeBSD builds?

[arcanumbridge]

@crazywhalecc Does github support hosted third-party runners? We use gitea internally via act-runner for GitHub/Gitea Actions support with our internal gitea instance. I'm good to have it connect directly to github for actions support if there is compatibility. We have some spare resources at our datacenter we can allocate to this effort. If that doesn't work, we could also setup a mirrored git repo to our gitea instance and connect the act-runner to that to process the workflows.

[crazywhalecc]

Oh, cool! I wasn't aware that gitea Actions had support for FreeBSD. GitHub Actions is not currently supported yet. But I think the best way is to have a way to connect directly to the GitHub workflow, because then you can see the success and failure of the PR.

[crazywhalecc]

See #152 FreeBSD section. And sorry for suspending FreeBSD maintenance. One of the main reasons is that very few people use it.

I will start working on this once there is a CI workflow or someone can provide an answer to the static compilation issue for FreeBSD. I will open this issue again when I start working on this.

Also I don't know the stability of running Linux binaries directly on FreeBSD, maybe that's a possible solution?