mlocati / docker-php-extension-installer

Easily install PHP extensions in Docker containers
MIT License
4.33k stars 388 forks source link

Can't install gd extension #896

Open sluther opened 8 months ago

sluther commented 8 months ago

Version of install-php-extensions

v2.2.2

Error description

I get the following error when trying to build:

#9 30.32 libtool: link: `libgd/gd_pixelate.lo' is not a valid libtool object
#9 30.32 make: *** [Makefile:338: gd.la] Error 1
#9 ERROR: process "/bin/sh -c chmod +x /usr/local/bin/install-php-extensions &&     install-php-extensions gd exif intl" did not complete successfully: exit code: 2

This only seems to happen when I build for the linux/amd64 platform (which I need to do, as I'm running docker on an ARM Mac):

docker buildx build --progress=plain --no-cache --platform=linux/amd64 .

Docker image

php:8.2-fpm-alpine

Minimal Dockerfile

FROM php:8.2-fpm-alpine

ADD --chmod=0755 https://github.com/mlocati/docker-php-extension-installer/releases/latest/download/install-php-extensions /usr/local/bin/

RUN chmod +x /usr/local/bin/install-php-extensions && \
    install-php-extensions gd exif intl
mlocati commented 8 months ago

I can't replicate this issue

sluther commented 8 months ago

I just tried again and now I am getting this error:

fontl.lo  -MMD -MF libgd/gdfontl.dep -MT libgd/gdfontl.lo
32.39 cc: warning: : linker input file unused because linking not done
32.39 cc: error: : linker input file not found: No such file or directory
32.40 make: *** [Makefile:240: libgd/gd_webp.lo] Error 1
32.40 make: *** Waiting for unfinished jobs....

Is this caused by some sort of issue with my environment? I am on the latest version of Docker as well (Docker Desktop v4.28.0)

hcpss-banderson commented 8 months ago

I can reproduce. Started getting something similar with bcmath when i switched from an intel mac to my new M3. Tried your Dockerfile and I get your same error. Maybe and issue in the extensions themselves.

pionl commented 8 months ago

Hi there, same, im stuck too. It was working some time ago.

I managed to find out why, it was due the php8.1.27 version, when reverting back to php8.1.26 it started working again


I've got the same issue on Apple silicon and using linux/amd64 with gd extension.

install-php-extensions ctype intl redis pdo pdo_mysql gd imagick exif mbstring json xml tokenizer xdebug opcache zip

Tried to lower the version of install-php-extension and no help :)

Version v2.1.84

60.84 cc: warning: : linker input file unused because linking not done
60.84 cc: error: : linker input file not found: No such file or directory
60.84 make: *** [Makefile:215: intl_convert.lo] Error 1
60.84 make: *** Waiting for unfinished jobs....

Version v2.2.3 different error

55.83 mkdir collator/.libs
55.83 mkdir collator/.libs
55.83 mkdir collator/.libs
55.83 mkdir collator/.libs
55.84 mkdir collator/.libs
55.84 mkdir: can't create directory 'collator/.libs': File exists
55.84 mkdir: can't create directory 'collator/.libs': File exists
55.84 mkdir: can't create directory 'collator/.libs': File exists
55.84 mkdir: can't create directory 'collator/.libs': File exists
55.87 cc: warning: : linker input file unused because linking not done
55.87 cc: error: : linker input file not found: No such file or directory
55.88 make: *** [Makefile:236: collator/collator_attr.lo] Error 1

If i removed gd, not success ;) Using php-8.1.27-cli-alpine image

If I remove intl, it crashes on redis... :)

cyppe commented 8 months ago

Same error here.

As soon as I add 'gd' some other extension fails.

A part of my Dockerfile as example where you can (hopefully) reproduce it too.

It worked fine last week so something must have broken latest days.

FROM dunglas/frankenphp:latest

RUN apt-get update && apt-get install -y --no-install-recommends \
    acl \
    file \
    gettext \
    git \
    procps \
    htop \
    && rm -rf /var/lib/apt/lists/*

RUN set -eux; \
    install-php-extensions \
        @composer \
        opcache \
        zip \
        pcntl \
        redis \
        igbinary \
        mysqli \
        pdo_mysql \
        exif \
        bcmath \
                 sockets \
                 gd \
    ;

# https://getcomposer.org/doc/03-cli.md#composer-allow-superuser
ENV COMPOSER_ALLOW_SUPERUSER=1

Removing 'gd' makes everything work again.

Error is usually something like this:

78.62 cc: warning: : linker input file unused because linking not done
78.62 cc: error: : linker input file not found: No such file or directory
78.62 make: *** [Makefile:235: zend_accelerator_blacklist.lo] Error 1
78.62 make: *** Waiting for unfinished jobs....
cyppe commented 8 months ago

Update: Probably same as previous mentions, there has been a new php 8.3 release since my last successful build. Will try to lock it to 8.3.3 instead of 8.3.4.

Update 2:

Yes, pinning it to 8.3.3 makes GD work fine to install again. So we'll have to wait for a fix in either php or gd before updating php version.

sluther commented 8 months ago

Unfortunately, I need to use php 8.2 for now, otherwise I'd have tried 8.3+. Also worth noting, but this works for me just fine with php:8.2-fpm-bookworm, though it also fails with php:8.2-fpm, php:8.2-fpm-bullseye, php:8.2-fpm-alpine3.18 and php:8.2-fpm-alpine3.19. I'm trying to use the alpine image as it's much smaller than the others.

hcpss-banderson commented 8 months ago

I've been trying to cross compile php images with extensions without the use of this project to wildly inconsistent results. Different extensions giving different errors. I think we may just not be understanding how multiplatform building works.

Here is a workaround from this post:

FROM --platform=$BUILDPLATFORM php:8.2-fpm-alpine

ADD --chmod=0755 https://github.com/mlocati/docker-php-extension-installer/releases/latest/download/install-php-extensions /usr/local/bin/

RUN chmod +x /usr/local/bin/install-php-extensions && \
    install-php-extensions gd exif intl

It seems strange to have to explicitly tell docker that I want to use the base image for my target architecture, but i guess we do.

EDIT: I think this is less a workaround and more just how we are supposed to do multiplatform builds.

marcispauls commented 8 months ago

the issue seems only on arm64 on x64 all seems fine

mlocati commented 8 months ago

So, the issue is not related to install-php-extensions and can be fixed by using

FROM --platform=$BUILDPLATFORM php:whatever

right? If so, I'd close this issue...

sluther commented 8 months ago

I will test that when I get home and report back, though I don't believe that will fix the issue (I had tried specifying the --platform already and it was failing then, too).

pionl commented 8 months ago

It works, but I'm unable to build amd64 flavor now and I was unable to seutp buildx that uses the $BUILDPLATFORM

sluther commented 8 months ago

I have confirmed that while setting --platform=$BUILDPLATFORM prevents the error during build, I am unable to actually run the docker image on my server, so unfortunately, this is not a fix. Setting --platform=linux/amd64 unfortunately does not work, and that's the architecture I need (building on an M2 mac but running on a linux/amd64 server).

mlocati commented 8 months ago

I am unable to actually run the docker image on my server

What's the error?

sluther commented 8 months ago

The error I'm getting is:

php-fpm-1  | exec /usr/local/bin/docker-php-entrypoint: exec format error
php-fpm-1 exited with code 1
hcpss-banderson commented 8 months ago

Yeah i get that too. I was definitely wrong about BUILDPLATFORM. It might be TARGETPLATFORM, but i am not convinced of that now either.

If we want to demonstrate that this is an issue with install-php-extensions, we need to show:

  1. We can build a php image with gd on apple silicone that targets amd64 without install-php-extensions
  2. We cannot build a similar php image with install-php-extensions

I can't get 1 working.

I think this is a minimal dockerfile:

FROM php:8.2-fpm-alpine

RUN apk add --no-cache --virtual \
    build-essentials \
    zlib-dev \
    g++ \
    make \
    automake \
    autoconf \
    libpng-dev \
    libjpeg-turbo-dev
RUN docker-php-ext-configure gd --enable-gd --with-jpeg
RUN docker-php-ext-install gd

@sluther can you build that for amd64?

hcpss-banderson commented 8 months ago

Thanks to this comment on a similar issue, I think I have this fixed.

It seems that while Rosetta allows us to run amd64 images on our arm64 macs, it is messing up multiplatform building. So turn it off:

Dashboard > Settings > General

Uncheck Use Rosetta for x86_64/amd64 emulation on Apple Silicon

I can now consistently build the amd64 image and run it on my x86 server.

mlocati commented 8 months ago

@sluther @pionl @cyppe can you confirm this is working for you too?

sluther commented 8 months ago

@mlocati yep. I can confirm the above fix worked for me. I was able to build on my mac and deploy to my amd64 server without any issues.

@hcpss-banderson Thanks a ton. Great find!

pionl commented 8 months ago

@hcpss-banderson wow, I did not expect this, the description makes me think it will work thanks to the option. Thanks for finding this!

@mlocati I will test it on Monday, I did not have the time to make it this week.

Thanks all!

pionl commented 8 months ago

Hey all. If I disable the Use Rosetta for x86_64/amd64 emulation on Apple Silicon I'm unable to run correctly any images with --platform=linux/amd64 -> I need to set amd64 for chrome.

If I uncheck roseta, build an image, then i can start the container but it crashes on launching chrome.

Then I've tried to update the PHP related images with unchecked rosetta and I did not manage to setup the docker to support buildx. I'll try next time then.

❯ docker buildx build --platform linux/amd64,linux/arm64 . -t pionl/docker-php-laravel-ci:8.2-node-20-test
[+] Building 0.0s (0/0)                                                                                                              docker:desktop-linux
ERROR: Multi-platform build is not supported for the docker driver.
Switch to a different driver, or turn on the containerd image store, and try again.
Learn more at https://docs.docker.com/go/build-multi-platform/
Snímek obrazovky 2024-03-26 v 23 36 02

FYI: I can build 8.1.26 without problem, 8.1.27 fails (or PHP 8.2+).

debreczeniandras commented 1 month ago

My issue is somewhat similar, but the other way around: I am using linux to build an ARM image. I was able to see what the exit code actually means:

I am getting segmentation fault during the installation of libaom.

#23 255.6 FAILED: CMakeFiles/aom_av1_encoder_neon_intrinsics.dir/av1/encoder/arm/neon/av1_fwd_txfm2d_neon.c.o 
#23 255.6 /usr/bin/cc  -I../ -I. -I../apps -I../common -I../examples -I../stats -I../third_party/libyuv/include -O3 -DNDEBUG -std=c99 -Wall -Wdisabled-optimization -Wextra -Wfloat-conversion -Wformat=2 -Wimplicit-function-declaration -Wlogical-op -Wpointer-arith -Wshadow -Wsign-compare -Wtype-limits -Wuninitialized -Wunused -Wvla -Wstack-usage=100000 -Wundef -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -MD -MT CMakeFiles/aom_av1_encoder_neon_intrinsics.dir/av1/encoder/arm/neon/av1_fwd_txfm2d_neon.c.o -MF CMakeFiles/aom_av1_encoder_neon_intrinsics.dir/av1/encoder/arm/neon/av1_fwd_txfm2d_neon.c.o.d -o CMakeFiles/aom_av1_encoder_neon_intrinsics.dir/av1/encoder/arm/neon/av1_fwd_txfm2d_neon.c.o -c ../av1/encoder/arm/neon/av1_fwd_txfm2d_neon.c
#23 255.6 cc: internal compiler error: Segmentation fault signal terminated program cc1

The issue is also reproducible locally:

Dockerfile:

ARG PHP_EXTENSION_INSTALLER=2.5.2
FROM mlocati/php-extension-installer:${PHP_EXTENSION_INSTALLER} AS php-extensions-installer
FROM php:8.2-apache-bookworm
COPY --from=php-extensions-installer /usr/bin/install-php-extensions /usr/bin/
RUN set -eux; install-php-extensions gd

Then build for ARM:

docker buildx create --driver=docker-container --name=emu --platform linux/arm64
docker buildx use emu
docker buildx build --pull --platform linux/arm64  .

I also tried temporarily updating libaom to version 3.10.0 (also for the ARM environment), as the mentioned bug has already been fixed. That hasn't helped either.

mlocati commented 1 month ago

@debreczeniandras could you check if the changes made by #996 fix your problem?

debreczeniandras commented 1 week ago

@mlocati No, unfortunately the issue still persists in a multi-arch build (with QEMU). I am still investigating and will report back once I found a solution.