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
*** Bug 231969 has been marked as a duplicate of this bug. ***
I just hit this problem too (my WRKDIR is /home/usr/ports/graphics/gdk-pixbuf2/work/).
Unfortunately, Antoine's fix didn't help -- so I simply removed the subdir('tests') line completely, which allowed the port to build...
Maybe, that's the solution for the time being? It does not seem like the port has a meaningful test-target anyway, does it?
(In reply to Mikhail Teterin from comment #11)
In your build log, do you see evidence that the build could not find a .so file? See comment 4
Note that koobs changed this title to add that if fails with PNG disabled. Thomas (OP) had PNG enabled. Perhaps the title change should be reverted?
(In reply to John Hein from comment #12)
> In your build log, do you see evidence that the build could not find a .so file?
Not explicitly... But what helped me was to create the following symlink:
/usr/local -> ../opt
PREFIX is set to /opt on my systems, but, evidently, something was looking explicitly in /usr/local :-( After I created the symlink -- which I already have on my other machines -- the port built and installed successfully.
This should make it easy for you to reproduce the problem.
(In reply to Mikhail Teterin from comment #14)
I built with PREFIX=/opt . No failure after one attempt.
I guess we'd have to see your full build log. If you didn't see anything about a missing .so, then your build is different than Thomas' build - maybe you have a different problem. In any case, so far I haven't seen a foolproof way to reproduce a build error. Mikhail, is it always reproducible for you (with / without DISABLE_MAKE_JOBS=1 set)?
 make showconfig check-sanity stage stage-qa check-plist package PREFIX=/opt
(In reply to John Hein from comment #15)
> I built with PREFIX=/opt . No failure after one attempt.
Any chance, you still had your regular install in /usr/local, while rebuilding?