No test-inline-pixbufs.h?

I recently tried to build gtk, and the attempt failed due to the lack of test-inline-pixbufs.h.

As far as I know, it’s related to Gdk-pixbuf. I tried to build two different versions of Gdk, using two different libPng, yet this file never ends being part of Gdk.

The error it is:

Making all in demos
make[2]: Entering directory /media/34GB/Arquivos-de-Programas-Linux/gtk±2.24.0/demos
no --raw --build-list
apple_red ./apple-red.png
gnome_foot ./gnome-foot.png
test-inline-pixbufs.h
|| (rm -f test-inline-pixbufs.h && false)
/bin/bash: no: command not found
make[2]: *** [test-inline-pixbufs.h] Error 1

I was able to circumvent the issue by finding the test-inline-pixbufs.h on an online repository and coying it to the demos dir of Gtk.

Yet, I would really try to understand why the file is not part of the Gdk that I built and hence why the building processs was failing.

The test-inline-pixbufs.h header is generated at build time, so it’s not present in the repository or the release archives.

It requires gdk-pixbuf-csource to be available in your PATH; the “no” you’re seeing in the log means that the build system could not find it.

Additionally, I’d like to stress that GTK 2.24 has been end-of-life’d in December 2020.

Gdk was passed during the configure (otherwise it wouldn’t even produced the Makefile), so there might be a bug in there.

Couldn’t find any mention to it on configure and on the Makefile. What part is responsible for generating it?

The gdk-pixbuf-csource binary is part of gdk-pixbuf, not GDK. The configure.ac file calls:

AC_PATH_PROG(GDK_PIXBUF_CSOURCE, gdk-pixbuf-csource, no)

But does not check that GDK_PIXBUF_CSOURCE isn’t found because gdk-pixbuf-2.0 is a hard dependency of GTK; if gdk-pixbuf-2.0 is found, then there must be a gdk-pixbuf-csource as well. You need to make sure the gdk-pixbuf-csource utility is in your PATH.

In any case, even if it were a bug, GTK 2.x is EOL, and won’t receive any new fixes or have new releases.

It’s in the configure.ac file, which is used to generate the configure script, which will then generate the Makefile.

The gdk-pixbuf-csource binary is part of gdk-pixbuf, not GDK. The configure.ac file calls:

Not sure what could be Gdk, besides gdk-pixbuf.

But does not check that GDK_PIXBUF_CSOURCE isn’t found because gdk-pixbuf-2.0 is a hard dependency of GTK; if gdk-pixbuf-2.0 is found, then there must be a gdk-pixbuf-csource as well. You need to make sure the gdk-pixbuf-csource utility is in your PATH.

That’s flawed, because it basically says with other words: “There’s only /usr/whatever to install Gdk-pixbuff, and if you don’t do it, you are screwed” . If AC_PATH_PROG cannot check it, this should listed somewhere . The same is true for Glib stuff, like glib-mkenuns or glib-genmarshall, but at least when they are missing, the error message allows someone to understand what is going wrong, but this error message says absolutely nothing usefull

Anyway, I created symbolic link to gdk-pixbuf-csource-2.0 on /usr/local/bin but it did not work. In fact, the configure test for it failed to detect it, and then the same error appeared during the build.

GDK perhaps?

It just needs to be in PATH. It’s not that unreasonable for a compiler to be in PATH.

It can check for it , gtk2 just doesn’t bother since it’s part of gdk-pixbuf (which it does check for)

The binary is called gdk-pixbuf-csource

GDK perhaps?

Fine, but it is not part of requirements for Gtk.

It just needs to be in PATH. It’s not that unreasonable for a compiler to be in PATH.

Perhaps not, but if the building process cannot provide any other info about the error source, besides the useless error message on the opening post, and there is also no info about it on the documentation (or pretty much anywhere else on the internet) then we have a problem.

The binary is called gdk-pixbuf-csource

Well, Gdk-pixbuf-2.21.3, the minimum required version by the Gtk that I compiled, does not generates a gdk-pixbuff-csource only a gdk-pixbuff-csource-2.0. By the way, no useful error message is registered on config.log:

configure:22126: checking for gdk-pixbuf-csource
configure:22157: result: no

As useless as possible.

And that’s just the tip of the iceberg of countless problems I had to face to finally be able to build it. Undocumented X packages (the older the version, more and more undocumented X include files, that configure fails to check for, breaks the building). Underestimated package requirements (in the Gtk that I built, it mentions pango 1.20, but using it, the building process breaks due to an undefined reference to a function that is only available from 1.22)

Not to mention that if two libraries use a different library version (like a certain glib for gtk and another for pango) great chance some problem will arise.

GDK and gdk-pixbuf are two different projects. GDK is part of GTK, gdk-pixbuf is not.

If you decide to use different names for things, we’re not going to understand each other. Please be specific about projects and references.

Of course gdk-pixbuf builds a gdk-pixbuf-csource binary: it’s been built for 20 years.

There is no gdk-pixbuf-csource-2.0 anywhere in the build. I have no idea from where gdk-pixbuf-csource-2.0 is coming from, but I’d recommend you check you build recipes for gdk-pixbuf.

You’re operating under the assumption that Pango and GTK are only ever used together, and are the same project: they are not, and they are not. Pango requires a version of GLib, and GTK requires another version of GLib because those are their respective minimum version requirements.

It is up to the integrator—in this instance, you—to figure out the minimum version for every single package in the context of the full build.

It’s telling you that it could not find the gdk-pixbuf-csource binary. The gdk-pixbuf library used to be included in the GTK source code repository, and when it got moved out, some things did not get updated because of the expectation that gdk-pixbuf would still be a strict dependency. Of course, since integrators update their PATH to ensure that every binary built by a dependency is included when building a project, this has never come out in practice.

You are trying to build a library that has been built by every Linux distribution for the past 20 years, and has been deprecated last year. If you’re finding issues it’s likely because you’re doing something nobody has done, or simply you’re trying to reverse engineer things without looking at the source.

I just don’t know how many times I’m going to have to explain to you that even if you find an issue, it is not going to be fixed.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.