giflib5 @5.2.1: clang: error: no such file or directory: 'dgif_lib.o'

[ryandesign (Ryan Carsten Schmidt)]

​https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/48376/steps/install-port/logs/stdio

giflib5 is not UsingTheRightCompiler or -arch flags nor does it have a universal variant:

cc -std=gnu99 -fPIC -Wall -Wno-format-truncation -O2   -c -o dgif_lib.o dgif_lib.c

It also doesn't build:

clang: error: no such file or directory: 'dgif_lib.o'
make: *** [libutil.dylib] Error 1
make: *** Waiting for unfinished jobs....

Maybe a parallel build issue?

[Schamschula (Marius Schamschula)]

Unfortunately, there is only a Makefile that has mot be manually patched.

Dealing with the compiler shouldn't be a problem.

Adding an universal variant, is another matter.

[Schamschula (Marius Schamschula)]

However, adding the makefile PortGroup should fix the former problem, perhaps the second as well.

[Schamschula (Marius Schamschula)]

In 6ae29df99dcca7f84cd33cb573d2fa4988382553/macports-ports (master):

giflib5: add makefile PG

See: #62534

[ryandesign (Ryan Carsten Schmidt)]

Adding the makefile portgroup has made it use the right compiler, yes, but it's still not using -arch flags, and the build still fails on some builders possibly because of parallel build issues:

​https://build.macports.org/builders/ports-10.8_x86_64-builder/builds/41388/steps/install-port/logs/stdio

Just adding the makefile portgroup is often not enough. Because each project's makefile is different, you have to compare the makefile to the way the portgroup works and maybe change some of the options the portgroup exposes or maybe even patch the makefile before it will behave correctly.

Fortunately the build fails when using the newly-added universal variant, so fixing it doesn't require increasing the revision.

You could disable parallel building or try to figure out in what way the makefile's dependency declarations are wrong and try to fix them.