Commit Graph

35 Commits

Author SHA1 Message Date
Tianon Gravi
74175669f4 Adjust "docker-php-ext-enable" to use "grep -Fx"
Also, test both versions (with `.so` and without).

This helps avoid false positives due to lines like `extension=apc` matching `extension=apcu`.
2021-01-20 10:44:08 -08:00
Docker Library Bot
a310c86d0b Update 7.3 to 7.3.26 2021-01-07 13:46:27 +00:00
Tianon Gravi
73ccb45f47 Add "--enable-embed" to Debian-based CLI variants
This is used for things like NGINX Unit to embed PHP (similar to `mod_php` in Apache, but a more general interface).
2020-12-17 14:32:31 -08:00
Docker Library Bot
26e65d3c2a Update 7.3 to 7.3.25 2020-11-26 13:46:21 +00:00
Tianon Gravi
3dc9a6988d Add "--with-pic" to configure flags (specifically to fix i386)
After looking/comparing at the output of `./configure` for our i386 and amd64 builds against that of Debian's i386 build, our i386 build was the only one of the three to include `checking whether to force non-PIC code in shared modules... yes` (the other two were `no`).

Debian includes `--with-pic`, and we do not.

Looking at the upstream PHP code for this configure check (313a56add0/configure.ac (L241-L256)), this makes total sense, and explains why i386 is the only architecture we see this issue on:

```m4
dnl Disable PIC mode by default where it is known to be safe to do so, to avoid
dnl the performance hit from the lost register.
AC_MSG_CHECKING([whether to force non-PIC code in shared modules])
case $host_alias in
  i?86-*-linux*|i?86-*-freebsd*)
    if test "${with_pic+set}" != "set" || test "$with_pic" = "no"; then
      with_pic=no
      AC_MSG_RESULT(yes)
    else
      AC_MSG_RESULT(no)
    fi
    ;;
  *)
    AC_MSG_RESULT(no)
    ;;
esac
```

This was probably already implied by our `CFLAGS` (and the compiler) on Alpine, but I figured it doesn't hurt to be explicit / consistent.
2020-11-04 17:22:43 -08:00
Joe Ferguson
e12d4c5d46 Drop md5 checksums 2020-10-29 13:51:51 -07:00
Docker Library Bot
4c5cb612e6 Update 7.3 to 7.3.24 2020-10-29 12:46:23 +00:00
Joe Ferguson
a940d67380 Drop .so from "extension=" in docker-php-ext-enable generated ini files 2020-10-23 12:34:00 -07:00
Docker Library Bot
4c91c82a42 Update 7.3 to 7.3.23 2020-10-01 15:33:48 +00:00
Docker Library Bot
d6838d8e45 Update 7.3 to 7.3.22 2020-09-03 12:46:17 +00:00
Tianon Gravi
165f8ca09c Add initial jq-based templating engine 2020-08-28 15:17:53 -07:00
Docker Library Bot
098e442542 Update to 7.3.21 2020-08-06 12:46:15 +00:00
Docker Library Bot
a7a32c7483 Update to 7.3.20 2020-07-09 17:52:38 +00:00
Docker Library Bot
424dbd51d6 Update to 7.3.19 2020-06-11 12:46:12 +00:00
Joe Ferguson
a041c4250b Add ini-name to ext-install to pass along to ext-enable
Support an absolute path for --ini-name
2020-06-02 10:41:14 -07:00
Docker Library Bot
a3cf31c902 Update to 7.3.18 2020-05-14 12:46:13 +00:00
Tianon Gravi
b3532e478a Update upstream download URLs
These are the URLs listed on https://www.php.net/downloads (and the URLs Homebrew is using), so they seem more appropriate/correct than these older URLs we've been using.
2020-05-05 13:28:02 -07:00
Tianon Gravi
1cc409c705 Apply typo fixes 2020-04-27 11:51:58 -07:00
Tianon Gravi
7ccfc9272c Remove "--hash-style=both"
It turns out that --hash-style=gnu is considered better than either of --hash-style=both or --hash-style=sysv, assuming your environment/platform supports it.

On amd64 with both Debian's and Alpine's linkers, --hash-style=gnu is the default.

This is especially relevant on MIPS (mips64le), where "ld: .gnu.hash is incompatible with the MIPS ABI" (so the linker sanely defaults to --hash-style=sysv there, as it should).
2020-04-16 20:49:46 -07:00
Docker Library Bot
d66997097a Update to 7.3.17 2020-04-16 12:46:13 +00:00
Docker Library Bot
33b1561787 Update to 7.3.16 2020-03-19 15:09:57 +00:00
Docker Library Bot
a80762e229 Update to 7.3.15 2020-02-20 12:18:25 +00:00
Docker Library Bot
affbdaf138 Update to 7.3.14 2020-01-23 13:46:14 +00:00
Docker Library Bot
bb80b576dd Update to 7.3.13 2019-12-18 13:46:13 +00:00
Joe Ferguson
9bcb75e9db Prevent "silent" failures by having docker-php-ext-configure error on unknown flags so users have to fix them
"configure: WARNING: unrecognized options" just gets lost in all the configure output
2019-12-03 16:32:01 -08:00
Docker Library Bot
26b872c3bc Update to 7.3.12 2019-11-21 13:46:18 +00:00
Docker Library Bot
7af4c6ecfb Update to 7.3.11 2019-10-24 12:46:17 +00:00
Tianon Gravi
88a8a1e14a Add comment to remind us why we added largefile support 2019-10-21 10:36:14 -07:00
Delfer
168caf5849 Enabled large file support (affects 32bit systems)
Build flags added: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
According to https://www.php.net/manual/en/intro.filesystem.php
2019-10-21 10:33:20 -07:00
Ivan Kurnosov
3a546766fd Always build with external sqlite 2019-10-02 16:05:35 -07:00
Tianon Gravi
29a47a90c8 Update to 7.3.10 2019-09-26 05:28:44 -07:00
Docker Library Bot
5992cb02fa Update to 7.3.9 2019-08-29 18:54:02 +00:00
Docker Library Bot
135204c0f4 Update to 7.3.8 2019-08-01 12:46:36 +00:00
Tianon Gravi
a0ce8afda4 Add temporary "freetype-config" workaround for PHP 7.3, 7.2, and 7.1 on buster
See:

- https://github.com/docker-library/php/issues/865
- https://bugs.php.net/bug.php?id=76324
- https://github.com/php/php-src/pull/3632
- 2d03197749

This is not necessary for Debian Stretch (where `freetype-config` still exists) nor PHP 7.4+ (where `pkg-config` is used instead/in addition).
2019-07-19 14:20:04 -07:00
J0WI
ccbe53516f Add Debian Buster variant 2019-07-10 17:20:35 +02:00