Now here's an interesting one. I can reproduce the build error quoted by gergely.czuczy@harmless.hu 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: Index: meson.build --- meson.build.orig +++ meson.build @@ -398,7 +398,9 @@ endif subdir('po') if not meson.is_cross_build() - subdir('tests') + if get_option('installed_tests') + subdir('tests') + endif subdir('thumbnailer') endif
(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 [1]. 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)? [1] 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 [1]. No failure after one attempt. Any chance, you still had your regular install in /usr/local, while rebuilding?
(In reply to Mikhail Teterin from comment #16) A little late on this reply, but no, I did not have gdk-pixbuf2 already installed when I did the PREFIX=/opt build (comment 15). But it's possible (that was a while ago) that it was with the PNG option enabled. Certainly when I try building today (time has moved on and the version of gdk-pixbuf2 is now 2.40.0 vs 2.36.12 for the OP's reported issue), it consistently fails if PNG is off and consistently builds if PNG is on. This is with concurrent building enabled or not (on a 4 cpu system). Other things have changed since Jan 2019 (meson, ninja) as well. I think the OP's problem is a mystery and need not be pursued. Basically, he had PNG on, libpng was installed and detected, but for some silent reason, pixbufloader-png.so was just never built. That triggers the later problems in the build. Since we don't have enough information to solve the OP problem, we could just close this bug. Except that there seems to be a real problem _now_ when PNG is disabled (-Dpng=false passed to meson). I think any talk of parallel builds causing problems is just unverified guessing that _maybe_ was a possible problem in the 2019 version of everything. Let's assume it's not a problem now. The only problem that still remains as far as I can see is that the build fails with default options except PNG off. And it fails in a test because pixbufloader-png.so was never built. This seems to be an upstream issue - and the probable fix is: whatever test is failing should be modified or disabled if configured via meson with -Dpng=false. Possible courses of action: - remove PNG option and require libpng it unconditionally - submit problem upstream and see if they can reproduce/fix - - just punt and close the bug WONT
(In reply to John Hein from comment #17) Possible courses of action: - remove PNG option and require libpng it unconditionally - submit problem upstream and see if they can reproduce/fix - self diagnose the issue, and find a patch to fix the offending test (then submit upstream) - just punt and close the bug WONTFIX
Thanks John for the analysis. Submitter: if the issue still persists, please feel free to reopen. mfg Tobias
(In reply to John Hein from comment #4) > 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. Just wanted to say "thank you". In my case, the "local problem" was setting XDG_DATA_DIRS as part of testing a local toolchain build. Appending /usr/share resolves the problem while keeping my local toolchain visible. I have to say this is a pretty unfriendly failure mode; I am not sure I would have been able to figure it out without your comment on this bug report. Anyway thanks again.