Now here's an interesting one.
I can reproduce the build error quoted by firstname.lastname@example.org in bug #231969 under the following circumstances:
Host: 12.0 amd64
Build jail: 12.0 i386
gdk-pixbuf2 reproducibly fails to build with
generated_.._resources.c.o' -MF 'tests/tests@@cve-2015-4491@exe/meson-generated_.._resources.c.o.d' -o 'tests/tests@@cve-2015-4491@exe/meson-generated_.._resources.c.o' -c tests/resources.c
cc: error: no such file or directory: 'tests/resources.c'
cc: error: no input files
ninja: build stopped: subcommand failed.
*** Error code 1
if it is restricted to a single make job.
I *have* to set ALLOW_MAKE_JOBS_PACKAGES="gdk-pixbuf2" in poudriere.conf to obtain a successful bulk build.
To confirm, "poudriere testport" builds fail reproducibly if adding MAKE_JOBS_UNSAFE=yes in gdk-pixbuf2's port Makefile.
Can you attach a full build log showing the failure?
Created attachment 200984 [details]
Build error log from poudriere
(In reply to John Hein from comment #1)
Sure, no problem. See attachment 200984 [details]
If you look up a little bit from the end of your build log you'll see:
failed to load "/wrkdirs/usr/ports/graphics/gdk-pixbuf2/work/gdk-pixbuf-2.36.12/tests/icc-profile.png": Couldn't recognize the image file format for file '/wrkdirs/usr/ports/graphics/gdk-pixbuf2/work/gdk-pixbuf-2.36.12/tests/icc-profile.png'
It's funny that someone else is seeing this error - I hit this last month locally. In my case, it was a failure of devel/glib20's glib-compile-resources program (it is called by the gdk-pixbuf2 build - specifically gen-resources.py) to find the mime data to identify a file as a png file - it didn't know how to look in share/ and find mime/image/png.xml because of a local problem. I'd be surprised that a build in a stock poudriere tree would have this issue. I wound up poking into the source for glib-compile-resources to find the issue.
Hmm... even further up in your log is:
g_module_open() failed for /wrkdirs/usr/ports/graphics/gdk-pixbuf2/work/gdk-pixbuf-2.36.12/_build/gdk-pixbuf/libpixbufloader-png.so: Cannot open "/wrkdirs/usr/ports/graphics/gdk-pixbuf2/work/gdk-pixbuf-2.36.12/_build/gdk-pixbuf/libpixbufloader-png.so"
-g_module_open() failed for /wrkdirs/usr/ports/graphics/gdk-pixbuf2/work/gdk-pixbuf-2.36.12/_build/gdk-pixbuf/libpixbufloader-bmp.so: Cannot open "/wrkdirs/usr/ports/graphics/gdk-pixbuf2/work/gdk-pixbuf-2.36.12/_build/gdk-pixbuf/libpixbufloader-bmp.so"
I didn't see that problem. Do those .so files exist in your build tree? If so, then it does look like it could be a build jobs ordering issue where it tries to link with those .so's before they are built - it's somewhat unexpected to see an ordering build failure when you have explicitly disabled parallel building. Whether that is directly related to the glib-compile-resources (gen-resources.py) failure to identify the .png file or not is not clear - at least I don't understand the connection yet.
Created attachment 204566 [details]
build failure with PNG disabled
Just hit this build error on 12amd64 poudriere jail.
However, conveniently, I have ALLOW_MAKE_JOBS=yes (overriding the default of not enabled).
Testing further and using the breadcrumb spotted by John in comment #4, I tested with the PNG option enabled (I had all options disabled to reduce dependencies), and the build succeeds.
Might be https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/106 but there isn't a full log to determine whether or not this is PNG related
(In reply to Kubilay Kocak from comment #6)
It is with PNG support enabled.
It's due to a missing dependency in the build order of ninja created by meson.
For the time being, we use -Dinstalled_tests=false and this patch as a workaround:
@@ -398,7 +398,9 @@ endif
if not meson.is_cross_build()
+ if get_option('installed_tests')
(In reply to Antoine Jacoutot from comment #7)
Just to clarify, so is my failure (attachment 204566 [details]) not related to PNG and I just got lucky, or are there two issues:
1) one png related, without support it cant detect/parse the .png, so it fails
2) build order re dependencies
@Antoine And thank you for following-up to my tweet on the issue, much appreciated