Homebrew-core: GTK+ 2.x v2.24.32 Fails to Build and Install Under OS X v10.11.6 'El Capitan'

[RandomDSdevel]

Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.

Please always follow these steps:

• [x] Confirmed this is a problem with brew installing one specific Homebrew/homebrew-core formula (not cask or tap) and not every time you run brew? If it's a general brew problem, please file this issue at https://github.com/Homebrew/brew/issues/new. If it's a brew cask problem, please file this issue at https://github.com/caskroom/homebrew-cask/issues/new. If it's a tap (e.g. Homebrew/homebrew-php) problem, please file this issue at the tap.
• [x] Ran brew update and retried your prior step?
• [x] Ran brew doctor, fixed all issues, and retried your prior step?
• [ ] Ran brew gist-logs <formula> (where <formula> is the name of the formula that failed) and included the output link? (N/A)
• [x] If brew gist-logs didn't work: ran brew config and brew doctor and included their output with your issue?

To help us debug your issue please explain:

• What you were trying to do (and why:)

Upgrade my local, built-from-source copy of GTK+ 2.x from v2.24.31, Homebrew formula revision 1, to v2.24.32 as part of my normal routine of keeping all of my software tools up to date.

• What happened (include command output:)

  Homebrew failed to successfully build GTK+ 2.x v2.24.32 from source and install it in place of v2.24.31, Homebrew formula revision 1. My logs are:

  • here (from when I _did_ set HOMEBREW_BUILD_FROM_SOURCE=1.)
  • here (from when I _didn't._)

  In both cases, the exact point of failure appeared as follows:

  ⋮
  Making install in demos
  /usr/local/opt/gdk-pixbuf/bin/gdk-pixbuf-csource --raw --build-list      \
          apple_red  ./apple-red.png  \
                 gnome_foot ./gnome-foot.png  \
         > test-inline-pixbufs.h              \
  || (rm -f test-inline-pixbufs.h && false)
  
  (process:$WHICHEVER): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/local/opt/gdk-pixbuf/bin/../lib/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
  
  This likely means that your installation is broken.
  Try running the command
   gdk-pixbuf-query-loaders > /usr/local/opt/gdk-pixbuf/bin/../lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
  to make things work again for the time being.
  failed to load "./apple-red.png": Couldn't recognize the image file format for file './apple-red.png'
  make[1]: *** [test-inline-pixbufs.h] Error 1
  make: *** [install-recursive] Error 1
  ⋮
  

  (where the '$WHICHEVER' in the line starting with '(process:$WHICHEVER): …' is — hopefully obviously — the result of a manual replacement to abstract away variability in process numbers likely across different runs of the same command invocation.)

• What you expected to happen:

  For Homebrew to successfully build the new version of GTK+ 2.x from source and install it in the old version's place.

• Step-by-step reproduction instructions (by running brew commands:)

  • _With_ HOMEBREW_BUILD_FROM_SOURCE=1 (not supported with issue resolution:)

    HOMEBREW_BUILD_FROM_SOURCE=1 brew upgrade -vd --build-from-source gtk+ --with-jasper --with-quartz-relocation
    

    Note that setting that environment variable as shown above _probably_ doesn't make _any_ difference in this case, as upgrading GTK+ 2.x doesn't depend on upgrading any of its dependencies given the states my Homebrew installation and the packages it manages are currently in, but I usually set it _any_ time I run brew upgrade, just to be consistent.

  • _Without_ HOMEBREW_BUILD_FROM_SOURCE=1 (given to show that this issue _also_ occurs under a _supported_ configuration:)

    brew upgrade -vd --build-from-source gtk+ --with-jasper --with-quartz-relocation
    

[yetisyny]

I have had the same exact issue myself on numerous occasions.

Did you run the command it suggests you run, “gdk-pixbuf-query-loaders > /usr/local/opt/gdk-pixbuf/bin/../lib/gdk-pixbuf-2.0/2.10.0/loaders.cache”? If not, you should do that, then try again. If that fixes it, I think your problem is solved, if not, read on. Sometimes it fixes things, sometimes it doesn’t, but it is definitely the first thing to do.

If it still does not work after running that command, well, then, things are more complicated, and I have some knowledge about this particular error. gdk-pixbuf relies upon gobject-introspection by default unless you disable it, and also if shared-mime-info is installed at the time gdk-pixbuf is installed, it uses it for mime-type detection, but if shared-mime-info is not installed at the time you install gdk-pixbuf, gdk-pixbuf uses some other method for mime-type detection. When installing gtk+ 2.x from source, gdk-pixbuf mime-type detection is actually tested to see if it works or not, which does not happen when installing gdk-pixbuf itself. So this is not actually an error in gtk+ but instead in gdk-pixbuf, the error is just revealed by tests that gtk+ does on this dependency of its.

Also there are a number of problems with gobject-introspection that may occur, it can actually become broken and then make everything that uses gobject-introspection as a dependency stop working, but luckily it can be turned off in gdk-pixbuf as a dependency if you use the right option, if this happens to you. It has happened to me, multiple times.

I would suggest looking at #5482, an issue about gdk-pixbuf failing its own tests, it has a bit of relevant information about this kind of thing if you read the comments.

Anyway, if you still have problems after running the suggested command “gdk-pixbuf-query-loaders > /usr/local/opt/gdk-pixbuf/bin/../lib/gdk-pixbuf-2.0/2.10.0/loaders.cache”, try installing shared-mime-info and reinstalling gdk-pixbuf afterwards to see if that fixes it. Or try the --without-gobject-introspection option of gdk-pixbuf to see if that fixes it, if that does not work either. And if gdk-pixbuf does not work in the gtk+ 2.x tests when compiled from source, try installing gdk-pixbuf from a bottle with no options and THEN installing gtk+ 2.x. Remember that you will get different results depending on whether or not shared-mime-info is installed at the time of installing gdk-pixbuf, along with the fact that this is NOT really an error in gtk+ 2.x but instead an error in gdk-pixbuf that only becomes apparent when gtk+ 2.x does its install-time tests.

Please tell us what works for you if you can get it working. On my computer, I have to install both gdk-pixbuf and gtk+ 2.x from bottles with no options to get them to work unfortunately, as I have the same type of error as you, plus another different error involving gobject-introspection being completely broken and not working at all in ANYTHING that uses it as a dependency (a problem I keep having that can temporarily be fixed by completely uninstalling and reinstalling homebrew, but which eventually comes back again for some unknown reason). If you are lucky, the suggested command it tells you to run ought to fix things, if not, you have a more complicated problem like I do.

[RandomDSdevel]

@yetisyny: No, I haven't tried running that command yet; I thought I'd first ask to see if brew ever ran it itself, perhaps as part of a build or in a postinstall step for GTK+ 2.x or GDK Pixbuf. I suppose I could have looked that up _myself_, though…:man_facepalming:.

[yetisyny]

brew runs a slightly different command, it runs “/usr/local/Cellar/gdk-pixbuf/2.36.11/bin/gdk-pixbuf-query-loaders --update-cache” when installing gdk-pixbuf 2.36.11, at least if done from a bottle, done in the post-install step. You can verify this by running the install or looking at the code at https://github.com/Homebrew/homebrew-core/blob/master/Formula/gdk-pixbuf.rb.

Anyway, the difference is, this command leaves off the important part piping the output to a specific file at the end, the “> /usr/local/opt/gdk-pixbuf/bin/../lib/gdk-pixbuf-2.0/2.10.0/loaders.cache” part, which is in the command that homebrew tells the user to run if the gtk+ 2.x installation fails with this specific error.

And also the command homebrew tells the user to run if the gtk+ 2.x installation fails leaves off the directory that the program gdk-pixbuf-query-loaders is installed in, since that program is symlinked into the homebrew prefix which is typically part of the PATH (typically /usr/local/bin).

So, I think it is rather odd that in the post-install step, it does not pipe the output to the file /usr/local/opt/gdk-pixbuf/bin/../lib/gdk-pixbuf-2.0/2.10.0/loaders.cache (or, to make it shorter since the “/..” cancels out the “/bin”, /usr/local/opt/gdk-pixbuf/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache). Yet in the instructions on how to fix this install error, it tells the user to include piping the output to that file. It would seem to me that in the post-install step, the output ought to also be piped to that file, too. That would probably prevent this particular error message from occurring in the first place (although it would not stop other gdk-pixbuf-related errors, just this one).

I have noticed that, if you run that command which you are told to run, “gdk-pixbuf-query-loaders > /usr/local/opt/gdk-pixbuf/bin/../lib/gdk-pixbuf-2.0/2.10.0/loaders.cache”, after running it you can check whether it worked or not by typing “wc -c /usr/local/opt/gdk-pixbuf/bin/../lib/gdk-pixbuf-2.0/2.10.0/loaders.cache”, namely “wc -c” followed the path to loaders.cache. This will tell you the file size of loaders.cache in bytes. If the file size is some positive number, probably in the thousands, for instance, I got 3206 bytes after uninstalling and reinstalling homebrew and having everything working so far, your gdk-pixbuf installation is probably working properly, but if the file size is 0 bytes, like it was for me before I uninstalled and reinstalled homebrew and everything was broken, your gdk-pixbuf installation is probably broken. Regardless of whether it works or not, your command shell will create the loaders.cache file in that directory, but whether or not the file size is zero depends on whether the command successfully completes or not.

So, I would say, the post-install for gdk-pixbuf ought to pipe the output to this file as recommended in the error message for gdk+ 2.x, and furthermore, check to see if the file size of the file is zero in order to determine whether or not the post-install for gdk-pixbuf completed successfully or not. That is what I propose as a solution. It would probably prevent this specific error message from ever happening, at least if all existing gdk-pixbuf installations had to go through being reinstalled. I don’t think anything at all needs to change in the gtk+ formula for this specific error.

I don’t know anything at all about how to post a pull request to GitHub or anything like that though, I am still kinda new to GitHub and still learning how to use Git, and for now just commenting on bug reports at this stage in my learning process, I am sure I will get to the stage of doing pull requests eventually but for now I am in the process of reinstalling all my homebrew formulae as my top priority so, after that is done, maybe. But I did figure out more about this bug during the process of uninstalling and reinstalling all my homebrew formulae, which is still not done yet, since prior to uninstalling my gdk-pixbuf was broken and now it is working correctly.

Oh, right, and I forgot to mention this earlier, but I installed shared-mime-info prior to gdk-pixbuf this time around, it seems gdk-pixbuf is working so far. Someone really needs to look into how exactly the presence or absence of shared-mime-info affects gdk-pixbuf. I don’t know exactly how to do that. It is not listed as a dependency but according to #5482 there is a connection, there is also some stuff about this over at MacPorts at https://trac.macports.org/ticket/45354 where they document how it exists as an undocumented, hidden, optional dependency. As far as what to do about that, I do not know, I have not been able to verify that gdk-pixbuf actually requires shared-mime-info, but it certainly does do its checking of loaders to see if it has loaders for various image file formats using different methods depending on whether shared-mime-info is there or not. It seems possible for gdk-pixbuf to function without that optional dependency, but that optional dependency also does seem to help. Maybe. I don’t know enough yet. And also given the way homebrew handles dependencies, that complicates things, since it makes it hard for homebrew to keep track of whether you installed gdk-pixbuf at a time when you had shared-mime-info installed or not.

Oh right, and since shared-mime-info functions as a hidden optional dependency of gdk-pixbuf, then if you install shared-mime-info, then install gdk-pixbuf from source, then UNINSTALL shared-mime-info, gdk-pixbuf will be broken without shared-mime-info unless you reinstall it, but homebrew will have no idea it is broken and have no idea about this dependency. Anyway, the solution is probably to list shared-mime-info as a REQUIRED dependency of gdk-pixbuf since that would prevent such a situation from ever occurring, in fact that is what MacPorts chose to do as a solution if you look at that link in the last paragraph and you can read how the people there researched this problem. But then again, gdk-pixbuf also works perfectly fine if you NEVER install shared-mime-info, but if you have ever installed shared-mime-info and not cleaned it up properly after uninstalling, that breaks gdk-pixbuf apparently.

So yes, a complicated situation we have here with gdk-pixbuf, probably someone who knows more about this than me should solve it. I only know what I know from either reading it online or doing experiments to see what works and what doesn’t, what causes errors and what compiles correctly and works without errors, a mix of secondhand information and trial-and-error results, not exactly perfect information but I do my best with the info I have.

But yeah at this point I think there are probably THREE separate issues regarding gdk-pixbuf, rather than just one: the missing loaders cache issue (what THIS bug report is PROBABLY about), the shared-mime-info optional dependency issue (another POSSIBLE cause for the error message in this bug report), and the gobject-introspection sometimes being broken issue (an issue with gobject-introspection, not gdk-pixbuf, but one that affects gdk-pixbuf among a bunch of other formulae unless its optional dependency on gobject-introspection is disabled). If someone’s gdk-pixbuf installation does not work, it is probably one of those 3 errors/bugs.

The easiest one to fix would be the hidden optional dependency on shared-mime-info, by turning it into an explicit required dependency. Either that or, if someone is uninstalling shared-mime-info and already has gdk-pixbuf installed, the shared-mime-info uninstallation could stop with a warning that gdk-pixbuf uses it as an optional dependency, and then tell the user, hey, if you really want to uninstall shared-mime-info, you can go right ahead, but you will have to uninstall and reinstall gdk-pixbuf after doing that since uninstalling shared-mime-info breaks gdk-pixbuf until the next time it is uninstalled and reinstalled. Then again, if someone never has shared-mime-info installed in the first place, gdk-pixbuf will probably work fine without it.

And as far as the loaders cache thing goes, the necessary file is not actually created in the post-install step for gdk-pixbuf, since the necessary piping to a loaders.cache file in the right directory is not done unless you follow the instructions you get from an error message when gtk+ 2.x installation fails and tells you what to do. Following the instructions there DOES solve this particular problem in a high percentage of cases, but it should not have to be necessary.

And the gobject-introspection thing I mentioned, that is probably not what is going on here, it is a different problem I have encountered, if it happens again I will see if I can file a bug report about it, I think that is a different issue from this, but it is one potential way gdk-pixbuf can stop working and have errors, that is the only reason I mentioned it. And yeah, the errors would most likely show up when installing things that depend on gdk-pixbuf such as gtk+ 2.x. It does not seem like gtk+3 runs the same tests though, gtk+3 is totally different from gtk+ 2.x in how it behaves on this in my experience. gtk+3 does not ever seem to display this sort of error since it does not seem to ever run this sort of test to see if its dependency gdk-pixbuf is working.

Anyway, the most important thing about this error is, it is an error in gdk-pixbuf that is detected by a test that gtk+ 2.x does at install-time, and only happens if something is wrong with gdk-pixbuf, and if that dependency is working properly, gtk+ 2.x does NOT have this error. It is also a very common error, too, but the exact reasons for the failure are not always the same, although they might USUALLY be the same, enough so that the instructions on how to fix it USUALLY work, just not all the time, as in cases where shared-mime-info used to be there but is now missing.

[RandomDSdevel]

@yetisyny: Thanks, that's actually very helpful! It gives me some leads I can investigate tomorrow; with any luck, I can do something with the recommendations you've made and actually _fix_ this. It doesn't sound _too_ hard, anyway… (I've made contributions here before.)

[RandomDSdevel]

In lieu of knowing who to ask about this and due to '@Homebrew/maintainers' not working for me anymore as far as I can tell, @ilovezfs since he's lead maintainer here:

     OK, I've started trying to fix this, but I need a bit of help with my almost nonexistent Ruby-fu. The first problem is one I ran into while attempting to take @yetisyny's comments here concerning the issues he pointed out with respect to how Homebrew handles regenerating GDK Pixbuf's loader cache in a post_install step in the gdk-pixbuf formula into account: system doesn't appear to support redirection using bash's syntax (unless I pass it everything as one string literal, perhaps?) Does anybody have any idea what I could use instead (if that last idea for using system() doesn't pan out and/or isn't OK?) popen()? popen_write()? Open3.popen3()? I don't see any recommendations on what to do in this sort of situation anywhere blindingly obvious, just reams of documentation about what each thing does. I'll handle adding a check of the the GDK Pixbuf loader cache's file size to the gdk-pixbuf formula's test do block later, then deal with said formula's hidden dependency on shared-mime-info (_possibly_ by adding it and making it :recommended, I think…?) after that.

[RandomDSdevel]

@ilovezfs: Just in case GitHub didn't ping you about it, I edited my previous addition to this thread to mention you in a note at its beginning a few moments ago. (Non-sequitur: _Does_ GitHub ping users when they're mentioned in post edits other than the ones that _create_ those posts…? :man_shrugging:)

[ilovezfs]

Utils.popen_read

[RandomDSdevel]

@ilovezfs: So I'd put something in the block passed to that function to achieve the redirection needed?

[ilovezfs]

irb(main):001:0> foo = system "echo", "hello"
hello
=> true
irb(main):002:0> foo
=> true
irb(main):003:0> foo = Utils.popen_read "echo", "hello"
=> "hello\n"
irb(main):004:0> foo
=> "hello\n"
irb(main):005:0> 

[RandomDSdevel]

@ilovezfs: I'm putting the loader cache file size check in as another step in gdk-pixbuf's post_install stage like @yetisyny suggested instead of adding it to its test do block like I thought I might. Is that OK?

[RandomDSdevel]

@ilovezfs: Testing my PR staging branch locally before submitting it as part of a PR.

P. S.: I left off dealing with the shared_mime_info madness @yetisyny mentioned in his last comment on this thread because I'm not entirely sure what to do about it and/or if it's really big enough of a deal to mess with. Should I worry about this?

[RandomDSdevel]

@ilovezfs: PR submitted. One caveat, though, is still my postscript above.

[vinyldarkscratch]

This happens under High Sierra (10.13.2) as well. While attempting to upgrade GTK+ to 2.24.32, I get the same errors. Looking in the folder, the file it's trying to open does not, in fact, exist.

Running that command it suggested fixed it, but I'm looking forward to your PR, @RandomDSdevel, to provide an official fix!

[RandomDSdevel]

Sorry it's taking so long to get #22955 finalized and merged, @vinyldarkscratch. I wonder if GitHub's been dropping my ping notifications to @ilovezfs on said PR's discussion thread on the floor…? (Or they could just be buried in his Notifications page, LOL.) 🤔:man_shrugging:

[RandomDSdevel]

For anyone still watching this issue thread, don't worry: I'm still working on my PR to close this.

[ilovezfs]

See comment here: https://github.com/Homebrew/homebrew-core/pull/22955#issuecomment-365550285

[ilovezfs]

gdk-pixbuf relies upon gobject-introspection by default unless you disable it, and also if shared-mime-info is installed at the time gdk-pixbuf is installed, it uses it for mime-type detection, but if shared-mime-info is not installed at the time you install gdk-pixbuf, gdk-pixbuf uses some other method for mime-type detection.

Please see
https://github.com/Homebrew/homebrew-core/pull/5582
https://github.com/Homebrew/homebrew-core/pull/16999
https://github.com/Homebrew/homebrew-core/issues/18353#issuecomment-332791393

So while it used to be true that there was a relationship between gdk-pixbuf and shared-mime-info, at least as of https://github.com/Homebrew/homebrew-core/issues/18353#issuecomment-332791393 we no longer believe that to be the case.

[RandomDSdevel]

@ilovezfs: I have seen the discussion you referenced, but an issue MacPorts encountered a little while ago still made me wonder whether that decision was correct. That being said, I'll let you deal with figuring that out; I've worked long enough on this issue as it is, so the last thing I'm going to do is follow through on your resolution of PR and submit another one to remove the options that likely got me into this mess in the first place.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[RandomDSdevel]

@stale-bot, meet R. O. B.. I invoke his Final Smash!

[fxcoudert]

--with-quartz-relocation has been removed.