Bug 234784 - graphics/gdk-pixbuf2: Fails to build with PNG option disabled
Summary: graphics/gdk-pixbuf2: Fails to build with PNG option disabled
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-gnome mailing list
URL:
Keywords: needs-patch
: 231969 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-01-09 14:08 UTC by Thomas Zander
Modified: 2020-04-04 14:49 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (gnome)


Attachments
Build error log from poudriere (125.31 KB, text/plain)
2019-01-10 11:57 UTC, Thomas Zander
no flags Details
build failure with PNG disabled (108.70 KB, text/plain)
2019-05-23 13:00 UTC, Kubilay Kocak
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Zander freebsd_committer 2019-01-09 14:08:56 UTC
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.
Comment 1 John Hein 2019-01-09 14:59:37 UTC
Can you attach a full build log showing the failure?
Comment 2 Thomas Zander freebsd_committer 2019-01-10 11:57:19 UTC
Created attachment 200984 [details]
Build error log from poudriere
Comment 3 Thomas Zander freebsd_committer 2019-01-10 11:57:58 UTC
(In reply to John Hein from comment #1)

Sure, no problem. See attachment 200984 [details]
Comment 4 John Hein 2019-01-11 14:48:26 UTC
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.
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-23 13:00:11 UTC
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.
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-23 13:03:38 UTC
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
Comment 7 Antoine Jacoutot 2019-05-23 13:11:58 UTC
(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
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-23 13:22:13 UTC
(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
Comment 9 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-23 13:22:46 UTC
@Antoine And thank you for following-up to my tweet on the issue, much appreciated
Comment 10 Walter Schwarzenfeld freebsd_triage 2019-08-18 14:54:24 UTC
*** Bug 231969 has been marked as a duplicate of this bug. ***
Comment 11 Mikhail Teterin freebsd_committer 2020-03-29 14:22:30 UTC
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?
Comment 12 John Hein 2020-04-01 18:16:19 UTC
(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
Comment 13 John Hein 2020-04-01 18:32:58 UTC
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?
Comment 14 Mikhail Teterin freebsd_committer 2020-04-01 18:41:54 UTC
(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.
Comment 15 John Hein 2020-04-04 04:29:26 UTC
(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
Comment 16 Mikhail Teterin freebsd_committer 2020-04-04 14:49:03 UTC
(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?