adwaita-icon-theme @3.22.0 fails building on 10.5.8 PPC

[udbraumann]

While upgrading adwaita-icon-theme from 3.20_0 to 3.22.0_0 on 10.5.8 PPC staging into destroot fails with this trouble:

...
:info:destroot for file in `cd ../../Adwaita/scalable; find . -name "*.svg"`; do \
:info:destroot          context="`dirname $file`"; \
:info:destroot          /opt/local/bin/gmkdir -p /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_adwaita-icon-theme/adwaita-icon-theme/work/destroot/opt/local/share/icons/Adwaita/scalable/$context; \
:info:destroot          /bin/sh /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_adwaita-icon-theme/adwaita-icon-theme/work/adwaita-icon-theme-3.22.0/install-sh -c -m 644 ../../Adwaita/scalable/$file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_adwaita-icon-theme/adwaita-icon-theme/work/destroot/opt/local/share/icons/Adwaita/scalable/$file; \
:info:destroot          for size in 16x16 24x24 32x32 48x48 64x64 96x96; do \
:info:destroot                  /opt/local/bin/gmkdir -p /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_adwaita-icon-theme/adwaita-icon-theme/work/destroot/opt/local/share/icons/Adwaita/$size/$context; \
:info:destroot                  /opt/local/bin/gtk-encode-symbolic-svg ../../Adwaita/scalable/$file $size -o /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_adwaita-icon-theme/adwaita-icon-theme/work/destroot/opt/local/share/icons/Adwaita/$size/$context; \
:info:destroot          done \
:info:destroot  done
:info:destroot Can't load file: Unrecognized image file format
...
:info:destroot Can't load file: Unrecognized image file format
:info:destroot make[3]: *** [install-data-local] Error 1
:info:destroot make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_adwaita-icon-theme/adwaita-icon-theme/work/adwaita-icon-theme-3.22.0/src/symbolic'
:info:destroot make[2]: *** [install-am] Error 2
...

Any ideas what kind of SVG incompatibility causes the problem?

[dbevans (David B. Evans)]

No, but I'll check now that I have access to an appropriate machine to test. The port builds fine on all other ports so it's almost certainly a 10.5 ppc specific issue.

[dbevans (David B. Evans)]

Well it built fine for me. So something different on your end. Are you using a standard build environment, compilers, etc or are you doing something different? Which version of Xcode is installed? and finally which version of gtk3. It's a utility provided by gtk3 that is processing svg files into icons that's running when you fail.

I did a test build using

MacOS 10.5.8 PPC
Xcode 3.1.4
Component versions: DevToolsCore-1204.0; DevToolsSupport-1186.0
BuildVersion: 9M2809
gtk3 @3.20.9

Using gtk3 3.20.9 because gtk3 3.22.0+ doesn't build on this machine.

Maybe you should try making a clean build of adwaita-icon-theme in case something got damaged in your distfile

sudo port clean --all adwaita-icon-theme
sudo port -d build adwaita-icon-theme

[udbraumann]

Thanks. have the same configuration (but for some reason I actually have gtk3 @3.22.1_0 on PPC, should I better reactivate 3.20.9_0?), have issued sudo port -f clean --all installed, the build command for adwaita-icon-theme works, but this was not the issue, it previously failed while staging into destroot. Presently I wait what comes out after issuing sudo port upgrade adwaita-icon-theme, I will let you know.

[udbraumann]

Unfortunately, neither extensive cleaning nor reactivating gtk3 @3.20.9_0 helped, the problem still persists as described above.

[dbevans (David B. Evans)]

I don't know what to tell you. The only reason I am using gtk3 @3.20.9_0 is because it won't build for me or Ken Cunningham either. So if you can build gtk @3.22.1 then go ahead and use it. But adwaita-icon-theme builds fine for me. Wish I could find out why this builds for some and not others.

For details on the gtk3 @3.22.1 build problem see #52468.

[udbraumann]

Replying to devans@…:

I don't know what to tell you. ...

For the moment I see that gtk-encode-symbolic-svg is broken:

$ /opt/local/bin/gtk-encode-symbolic-svg /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_adwaita-icon-theme/adwaita-icon-theme/work/destroot/opt/local/share/icons/Adwaita/scalable/actions/zoom-out-symbolic.svg 96x96 -o /tmp
Can't load file: Unrecognized image file format

Even previously installed SVG files cannot be handeled:

$ /opt/local/bin/gtk-encode-symbolic-svg /opt/local/share/icons/Adwaita/scalable/actions/zoom-out-symbolic.svg 96x96 -o /tmp/
Can't load file: Unrecognized image file format

So my guess is that something is wrong with librsvg:

$ sudo port installed librsvg
The following ports are currently installed:
  librsvg @2.40.16_0+viewer (active)

Under ​https://forums.gentoo.org/viewtopic-t-1007626-start-0.html someone was pretty much facing the same problem with adwaita-icon-theme like me. The solution apparently was to add some tools flag when building librsvg. I would be happy if you could have a look at this.

[dbevans (David B. Evans)]

Replying to braumann@…:

Replying to devans@…:

I don't know what to tell you. ...

For the moment I see that gtk-encode-symbolic-svg is broken:

$ /opt/local/bin/gtk-encode-symbolic-svg /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_adwaita-icon-theme/adwaita-icon-theme/work/destroot/opt/local/share/icons/Adwaita/scalable/actions/zoom-out-symbolic.svg 96x96 -o /tmp
Can't load file: Unrecognized image file format

Even previously installed SVG files cannot be handeled:

Good indication that there is nothing wrong with the svg files but with the processing.

$ /opt/local/bin/gtk-encode-symbolic-svg /opt/local/share/icons/Adwaita/scalable/actions/zoom-out-symbolic.svg 96x96 -o /tmp/
Can't load file: Unrecognized image file format

So my guess is that something is wrong with librsvg:

$ sudo port installed librsvg
The following ports are currently installed:
  librsvg @2.40.16_0+viewer (active)

I note that +viewer is not the default build so this could be an issue. Not sure why, but it is a difference from a "default" build.

Try

sudo port install librsvg

to install a default build. This should build without any variants.

Under ​https://forums.gentoo.org/viewtopic-t-1007626-start-0.html someone was pretty much facing the same problem with adwaita-icon-theme like me. The solution apparently was to add some tools flag when building librsvg. I would be happy if you could have a look at this.

Glad to do it. Reading now.

Dave

[udbraumann]

Thanks, have now a librsvg version without +viewer, but got no functional gtk-encode-symbolic-svg:

$ sudo port -s install librsvg
...
--->  No broken files found.
$ sudo port installed librsvg
The following ports are currently installed:
  librsvg @2.40.16_0 (active)
  librsvg @2.40.16_0+viewer
$ gtk-encode-symbolic-svg /opt/local/share/icons/Adwaita/scalable/actions/zoom-out-symbolic.svg 96x96 -o /tmp
Can't load file: Unrecognized image file format

Perhaps you have got some idea what's with the tools flag for librsvg?

[dbevans (David B. Evans)]

Ok, here's my progress report.

First let me say I've never used gentoo and I'm not familiar with their build system but the following is what I think that post is about.

The "tools flag" that they are talking about is an attibute of their build system, flag being roughly equivalent to variant in MacPorts. So it appears that the gentoo default build includes the flag -tools, that is, with out the tools. Rebuilding with +tools fixed their problem.

With respect to librsvg, there is a configuration flag:

--disable-tools         do not build miscellaneous tools [default=no]

that is, the default for librsvg is to build the tools. In our port, we don't assert --disable-tools and so the tools are built and installed by default. You can check with

port contents librsvg | grep bin

The tools are two small utility programs rsvg-convert and svg2pdf, which, as far as I can tell are not used by gtk-encode-symbolic-svg.

However, the other thing they talk about is the svg gdk-pixbuf loader provided by librsvg. This is, specifically,

${prefix}/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so

which is provided by librsvg and provides support for loading svg images as GdkPixbufs. This is getting closer to something that sounds like our failure message.

So again check and make sure it is installed as part of the contents of librsvg.

port contents librsvg | grep loaders

I'm looking into this further on this end.

[dbevans (David B. Evans)]

What does

port installed gdk-pixbuf2

return?

[udbraumann]

Thanks, I did the checks:

$ sudo port contents librsvg | grep bin
  /opt/local/bin/rsvg-convert
  /opt/local/bin/svg2pdf

So the two utilities are present.

$ sudo  port contents librsvg | grep loaders
  /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.la
  /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so

So two library variants for the loader are present.

$ sudo port installed gdk-pixbuf2
The following ports are currently installed:
  gdk-pixbuf2 @2.36.0_0+x11 (active)

This indicates the newest version of gdk-pixbuf2 is available.

[dbevans (David B. Evans)]

Replying to braumann@…:

$ sudo  port contents librsvg | grep loaders
  /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.la
  /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so

So two library variants for the loader are present.

This doesn't look right. If I remember correctly the current version of base automatically removes .la files from destroot if installed there. I don't see it in my installation just the .so file.

Questions:

• if you forceably deactivate librsvg is the .la file still there?

  sudo port -f deactivate librsvg
  

• if so you can remove it

  sudo rm /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.la
  

• now activate librsvg again. Is the .la file there again or not?

  sudo port activate librsvg
  

• if it is, remove it again anyway and see if the problem is fixed
• if it isn't, it was left over from something in the past, see if the problem is fixed

[dbevans (David B. Evans)]

Replying to braumann@…:

Thanks. have the same configuration (but for some reason I actually have gtk3 @3.22.1_0 on PPC

Was this a standard default build or did you use a non-standard compiler (like gcc6) to build gtk3?

[udbraumann]

Replying to devans@…:

Replying to braumann@…:

Thanks. have the same configuration (but for some reason I actually have gtk3 @3.22.1_0 on PPC

Was this a standard default build or did you use a non-standard compiler (like gcc6) to build gtk3?

To be honest, I cannot remember. Maybe I took gcc5, which usually is my first option once some c++ trouble is visible in the log file. Is there a way to check afterwards what compiler has been used?

[udbraumann]

Replying to devans@…:

...

Thanks, my impression is that the libpixbufloader-svg.la library is not a leftover. After deactivation of librsvg it disappeared (the .so as well), and both came back when I activated librsvg again. BTW, all such libpixbufloader* libraries have these double variants:

$ ll /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-<TAB>
libpixbufloader-ani.la     libpixbufloader-png.so
libpixbufloader-ani.so     libpixbufloader-pnm.la
libpixbufloader-bmp.la     libpixbufloader-pnm.so
libpixbufloader-bmp.so     libpixbufloader-qtif.la
libpixbufloader-gif.la     libpixbufloader-qtif.so
libpixbufloader-gif.so     libpixbufloader-svg.la
libpixbufloader-icns.la    libpixbufloader-svg.so
libpixbufloader-icns.so    libpixbufloader-tga.la
libpixbufloader-ico.la     libpixbufloader-tga.so
libpixbufloader-ico.so     libpixbufloader-tiff.la
libpixbufloader-jasper.la  libpixbufloader-tiff.so
libpixbufloader-jasper.so  libpixbufloader-xbm.la
libpixbufloader-jpeg.la    libpixbufloader-xbm.so
libpixbufloader-jpeg.so    libpixbufloader-xpm.la
libpixbufloader-png.la     libpixbufloader-xpm.so

All have almost identical time stamps.

Manually removing libpixbufloader-svg.la did not fix the problem :-(

[dbevans (David B. Evans)]

Replying to braumann@…:

Replying to devans@…:

Replying to braumann@…:

Thanks. have the same configuration (but for some reason I actually have gtk3 @3.22.1_0 on PPC

Was this a standard default build or did you use a non-standard compiler (like gcc6) to build gtk3?

To be honest, I cannot remember. Maybe I took gcc5, which usually is my first option once some c++ trouble is visible in the log file. Is there a way to check afterwards what compiler has been used?

You may be able to get a hint by using otool and looking to see which run time is used. Or you can just try rebuilding using the standard compiler selection. I'd recommend the latter.

Note that once you use something other the default compiler, you're on your own. At any rate, please report any information you have about building gtk3 to #52468 where the issue of building a default build on leopard ppc is being discussed.

[dbevans (David B. Evans)]

All have almost identical time stamps.

Manually removing libpixbufloader-svg.la did not fix the problem :-(

Good news, I guess: not the problem, although, the installation of the .la files is different from what I see on my system.

[dbevans (David B. Evans)]

While you were testing, I looked into the gtk-encode-symbolic-svg code. This utility converts svg icon files to specially encoded png files that have many of the same properties (color substitution, for example) as svg but with much less processing overhead.

gtk-encode-symbolic-svg uses the following code to read the svg into an in-memory GdkPixbuf:

      loaded = load_symbolic_svg (file_data, file_len, width, height,
                                  &g,
                                  plane == 0 ? &r : &g,
                                  plane == 1 ? &r : &g,
                                  plane == 2 ? &r : &g,
                                  error);
      if (loaded == NULL)
        return NULL;

and load_symbolic_svg uses the following code to do the work

  stream = g_memory_input_stream_new_from_data (data, -1, g_free);
  pixbuf = gdk_pixbuf_new_from_stream_at_scale (stream,
                                                width,
                                                height,
                                                TRUE,
                                                NULL,
                                                error);

Error handling here is what I would call "minimum magnificent"! If gdk_pixbuf_new_from_stream_at_scale returns an error it is propagated upstream without checks to the main caller which then prints the message we're seeing without checking which error it is. Possible errors are those in the GDK_PIXBUF_ERROR domain

GDK_PIXBUF_ERROR_CORRUPT_IMAGE         An image file was broken somehow.
GDK_PIXBUF_ERROR_INSUFFICIENT_MEMORY   Not enough memory.
GDK_PIXBUF_ERROR_BAD_OPTION            A bad option was passed to a pixbuf save module.
GDK_PIXBUF_ERROR_UNKNOWN_TYPE          Unknown image type.
GDK_PIXBUF_ERROR_UNSUPPORTED_OPERATION Don't know how to perform the given operation on the type of image at hand.
GDK_PIXBUF_ERROR_FAILED                Generic failure code, something went wrong.
GDK_PIXBUF_ERROR_INCOMPLETE_ANIMATION  Only part of the animation was loaded.

and in the G_IO_ERROR domain (too many to list here) but some sort of GIO stream error is a possibility.

Lots and lots of possibilities!

Can you run gtk-encode-symbolic-svg under gdb with a breakpoint at load_symbolic_svg and step from there to see what error is really being returned?

To do this sensibly, one would need to build at least gtk3 and gdk-pixbuf2 with debugging symbols enabled and without cleaning after the build so that the source code is still available for reference. You can do this using the following commands:

sudo port -nsk upgrade --force gdk-pixbuf2 'configure.optflags='-g -O0'
sudo port -nsk upgrade --force gtk3 'configure.optflags='-g -O0'

So the question is: what error is being returned by load_symbolic_svg?

[udbraumann]

Thanks a lot for your research, I have also thought about looking into the sources of this funny program. Well, I need to postpone my "homework", as I need to travel for a few days, unfortunately without my beloved PowerBook G4. Also, it was decades ago that I was using gdb. BTW, I guess load_symbolic_svg is returning NULL in case of any error? Also, as I will need to rebuild gtk3 I expect to face trouble. Oh, don't you think I better should use install for the two commands recommended above?

[dbevans (David B. Evans)]

Replying to braumann@…:

Thanks a lot for your research, I have also thought about looking into the sources of this funny program. Well, I need to postpone my "homework", as I need to travel for a few days, unfortunately without my beloved PowerBook G4. Also, it was decades ago that I was using gdb.

BTW, I guess load_symbolic_svg is returning NULL in case of any error?

Yes, and that's all they pay attention to. A better approach at this point would be to inspect the error structure to see what the error is before proceeding.

Also, as I will need to rebuild gtk3 I expect to face trouble. Oh, don't you think I better should use install for the two commands recommended above?

I was assuming that you already had a copy of the current version of gtk3 installed without the debugging symbols. In that case, install will build but not install because it thinks, it's already installed. So upgrade works in that case. If old version or nothing installed you should use install.

The flags are as follows:

-n upgrade just this port and not its dependencies
-s force a build from source; don't use archived binary if available
-k don't clean after install/update if finished; this leaves the source in place for reference from gdb
--force update and replace the currently installed version even if it's the same version as what I'm building

Of course, -g turns on debug symbols, -O0 disables all optimizations which can get in your way while debugging. You don't want anything optimized out of existence!

See you when you get back.

Dave

[khepler]

Cc Me!

[udbraumann]

Here is what I have found out so far:

Breakpoint 1, load_symbolic_svg (file_data=0x100f600 "<?xml version='1.0' encoding='UTF-8'?>\n<!-- Created with Inkscape (http://www.inkscape.org/) -->\n\n<svg xmlns:dc='http://purl.org/dc/elements/1.1/' sodipodi:docname='zoom-out-symbolic.svg' width='15.98"..., file_len=3552, width=128, height=128, fg=0xbffff428, success_color=0xbffff408, warning_color=0xbffff428, error_color=0xbffff428, error=0xbffff4d8) at encodesymbolic.c:62
62	  css_fg = gdk_rgba_to_string (fg);
(gdb) print *error
$1 = (GError *) 0x0
(gdb) n
64	  css_success = css_warning = css_error = NULL;
(gdb) n
66	  css_warning = gdk_rgba_to_string (warning_color);
(gdb) n
67	  css_error = gdk_rgba_to_string (error_color);
(gdb) n
68	  css_success = gdk_rgba_to_string (success_color);
(gdb) n
71	  stream = g_memory_input_stream_new_from_data (file_data, file_len, NULL);
(gdb) n
72	  pixbuf = gdk_pixbuf_new_from_stream (stream, NULL, error);
(gdb) n
73	  g_object_unref (stream);
(gdb) n
75	  if (!pixbuf)
(gdb) n
76	    return NULL;
(gdb) n
125	}
(gdb) n
make_symbolic_pixbuf (file=0xbffff62b "/opt/local/share/icons/Adwaita/scalable/actions/zoom-out-symbolic.svg", width=128, height=128, error=0xbffff4d8) at encodesymbolic.c:204
204	      if (loaded == NULL)
(gdb) n
205	        return NULL;
(gdb) n
218	}
(gdb) n
main (argc=3, argv=0xbffff550) at encodesymbolic.c:277
277	  if (symbolic == NULL)
(gdb) n
279	      g_printerr (_("Can't load file: %s\n"), error->message);
(gdb) n
Can't load file: Unrecognized image file format
280	      return 1;
(gdb) bt
#0  main (argc=3, argv=0xbffff550) at encodesymbolic.c:280

So, for some unknown reason the function gdk_pixbuf_new inside make_symbolic_pixbuf returns 0x0 (the variable symbolic is assigned the return value of make_symbolic_pixbuf). So my impression is that gdk_pixbuf_new is doing wrong.

[dbevans (David B. Evans)]

Yes, it looks like gdk_pixbuf_new_from_stream returned the error but there's a lot of possibilities. After the function returns NULL, it's parameter error should contain the detailed error report. Hopefully, this will shed more light on why it failed.

See ​https://developer.gnome.org/glib/stable/glib-Error-Reporting.html for documentation on how it works. I think something like

print **error

will print the fields of the relevant GError structure and their values.

[udbraumann]

Thanks, I was checking at what step the error occurred, this is what I found:

...
Breakpoint 1, load_symbolic_svg (file_data=0x100f600 "<?xml version='1.0' encoding='UTF-8'?>\n<!-- Created with Inkscape (http://www.inkscape.org/) -->\n\n<svg xmlns:dc='http://purl.org/dc/elements/1.1/' sodipodi:docname='zoom-out-symbolic.svg' width='15.98"..., file_len=3552, width=128, height=128, fg=0xbffff428, success_color=0xbffff408, warning_color=0xbffff428, error_color=0xbffff428, error=0xbffff4d8) at encodesymbolic.c:62
62	  css_fg = gdk_rgba_to_string (fg);
(gdb) n
64	  css_success = css_warning = css_error = NULL;
(gdb) n
66	  css_warning = gdk_rgba_to_string (warning_color);
(gdb) print **error
Cannot access memory at address 0x0
(gdb) n
67	  css_error = gdk_rgba_to_string (error_color);
(gdb) print **error
Cannot access memory at address 0x0
(gdb) n
68	  css_success = gdk_rgba_to_string (success_color);
(gdb) print **error
Cannot access memory at address 0x0
(gdb) n
71	  stream = g_memory_input_stream_new_from_data (file_data, file_len, NULL);
(gdb) print **error
Cannot access memory at address 0x0
(gdb) n
72	  pixbuf = gdk_pixbuf_new_from_stream (stream, NULL, error);
(gdb) print **error
Cannot access memory at address 0x0
(gdb) n
73	  g_object_unref (stream);
(gdb) print **error
$1 = {
  domain = 84,
  code = 3,
  message = 0xe0d170 "Unrecognized image file format"
}
(gdb) print stream
$2 = (GInputStream *) 0xdc5028
(gdb) print pixbuf
$3 = (GdkPixbuf *) 0x0
(gdb)
...

What do domain = 84 and code = 3 mean?

[dbevans (David B. Evans)]

Replying to udbraumann:

Thanks, I was checking at what step the error occurred, this is what I found:

...
B> $1 = {
  domain = 84,
  code = 3,
  message = 0xe0d170 "Unrecognized image file format"
}
(gdb) print stream
$2 = (GInputStream *) 0xdc5028
(gdb) print pixbuf
$3 = (GdkPixbuf *) 0x0
(gdb)
...

What do domain = 84 and code = 3 mean?

domain is the error domain or named group of error codes. These are normally used symbolically but in this case I'm guessing its GDK_PIXBUF_ERROR. The code is the error code specified from an enum of error codes for the domain. The message is the string equivalent to the error code and is really the relevant information.

This is implying that, as we might have guessed, gdk_pixbuf_new_from_stream isn't recognizing svg files in general. Probably due to the fact the binary module that librsvg installs to deal with this file type isn't working or can't be loaded by gdk_pixbuf.

I guess next step is to go one level deeper and step into (command s) rather than over the call to gdk_pixbuf_new_from_string and then step to see what's going on with that code that causes this error to be thrown.

[dbevans (David B. Evans)]

It just occurred to me that if librsvg is not installed and active or its svg loader module is not installed, you would possibly get a very similar error.

So, to double check:

• make sure librsvg is installed and active as well as gtk3 and gdk-pixbuf2

$ port installed gtk3 gdk-pixbuf2 librsfvg
  gdk-pixbuf2 @2.36.0_0+x11 (active)
  gtk3 @3.22.2_0+x11 (active)
  librsvg @2.40.16_0 (active)

• make sure the SVG loader module is installed

$ ls -l ${prefix}/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so
-rwxr-xr-x  1 root  admin  25960 Jun 27 14:32 /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so

• run the following command to register the module (normally done during activation of librsvg)

$ sudo gdk-pixbuf-query-loaders --update-cache

If you run this same command without the --update-cache, it will write information about the currently available loaders to stdout. In there somewhere you should see an entry like this:

"/opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so"
"svg" 6 "gdk-pixbuf" "Scalable Vector Graphics" "LGPL"
"image/svg+xml" "image/svg" "image/svg-xml" "image/vnd.adobe.svg+xml" "text/xml-svg" "image/svg+xml-compressed" ""
"svg" "svgz" "svg.gz" ""
" <svg" "*    " 100
" <!DOCTYPE svg" "*             " 10

[udbraumann]

What I obtain is this:

$ sudo port installed gtk3 gdk-pixbuf2 librsvg
The following ports are currently installed:
  gdk-pixbuf2 @2.36.0_0+x11 (active)
  gtk3 @3.22.1_0+x11 (active)
  librsvg @2.40.16_0 (active)

And

$ ls -l /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so
-rwxr-xr-x  1 root  admin  29820 Oct 15 20:06 /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so

The following, however, might give us a sign what is wrong:

$ sudo gdk-pixbuf-query-loaders --update-cacheg_module_open() failed for /opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: dlopen(/opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so, 10): Symbol not found: _CFStringGetLongCharacterForSurrogatePair
  Referenced from: /opt/local/lib/libpangocairo-1.0.0.dylib
  Expected in: dynamic lookup

So, due to this trouble, I do not receive such entry on "Scalable Vector Graphics" as you were pasting above. The central question now appears to be why this symbol _CFStringGetLongCharacterForSurrogatePair is missing in loaders/libpixbufloader-svg.so? But I receive something like

"/opt/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-xpm.so"
"xpm" 4 "gdk-pixbuf" "XPM" "LGPL"
"image/x-xpixmap" ""
"xpm" ""
"/* XPM */" "" 100

What do you think is best now to do? I again will travel a few days before I can get back to my beloved PowerBook G4 ...

[dbevans (David B. Evans)]

You can look at the code and see where this is called but it does appear to be the problem. CFStringGetLongCharacterForSurrogatePair is part of Apple's CoreFoundation API and this particular function is only available on 10.6+. I think this module was probably linked with the reference missing on the assumption it would be found when loading at run time.

See ​https://developer.apple.com/reference/corefoundation/1541965-cfstringgetlongcharacterforsurro?language=objc

Actually this may be a variant problem with librsvg. Try installing librsvg with the +x11 variant to match the other two and see if that helps. Maybe that will keep it from using this function.

[khepler]

My PowerMac G5 successfully installed adwaita-icon-theme @3.22.0_0 with librsvg @2.40.16_0+x11.

[udbraumann]

Replying to khepler:

My PowerMac G5 successfully installed adwaita-icon-theme @3.22.0_0 with librsvg @2.40.16_0+x11.

Unfortunately, this variant change for librsvg @2.40.16_0 did not solve the problem for me. I actually would have wondered if adding x11 would not still require SVG icons.

[udbraumann]

Replying to dbevans:

You can look at the code and see where this is called but it does appear to be the problem.

Thanks, to be honest, I presently have no idea in which code this CFStringGetLongCharacterForSurrogatePair is being called. Somewhere in gdk-pixbuf2? Also, I tried to find some C code for an "on foot" solution of the 32bit UTF encoding of a surrogate pair of two 16bit parts, but did not easily found one.

Just saw this page with a C example to decode such surrogate pair: ​http://unicodebook.readthedocs.io/unicode_encodings.html

[dbevans (David B. Evans)]

Ok, I found it. It's in pango, specifically in pango/pangocoretext-shape.c.

This file contains code which should provide a valid definition for this function on systems earlier than 10.6 as follows:

#if defined(MAC_OS_X_VERSION_MAX_ALLOWED) && MAC_OS_X_VERSION_MAX_ALLOWED < 1060
CF_INLINE Boolean CFStringIsSurrogateHighCharacter(UniChar character) {
    return ((character >= 0xD800UL) && (character <= 0xDBFFUL) ? true : false);
}

CF_INLINE Boolean CFStringIsSurrogateLowCharacter(UniChar character) {
    return ((character >= 0xDC00UL) && (character <= 0xDFFFUL) ? true : false);
}

CF_INLINE UTF32Char CFStringGetLongCharacterForSurrogatePair(UniChar surrogateHigh, UniChar surrogateLow) {
    return ((surrogateHigh - 0xD800UL) << 10) + (surrogateLow - 0xDC00UL) + 0x0010000UL;
}
#endif

And, in fact, I can compile adwaita-icon-theme with out problems on a borrowed Leopard PPC machine.

So I think, there's something specifically wrong on your system.

Suggest you try rebuilding pango and see if that has any effect on things.

[dbevans (David B. Evans)]

adwaita-icon-theme builds for me on Tiger PPC as well.

[udbraumann]

Replying to dbevans:

... And, in fact, I can compile adwaita-icon-theme with out problems on a borrowed Leopard PPC machine.

So I think, there's something specifically wrong on your system.

Suggest you try rebuilding pango and see if that has any effect on things.

Well, I suddenly noticed during an upgrade to pango @1.40.3_1 that this was not built from sources, but unpacked from a buildbot installation file pango-1.40.3_1+quartz+x11.darwin_9.ppc.tbz2. So I have forced a build from sources calling

$ sudo port -nsk upgrade --force pango

Afterwards, I issued

$ sudo gdk-pixbuf-query-loaders --update-cache

and this time I was pleased to see no error as reported above. So I got curious if adwaita-icon-themes installs now:

$ sudo port -nskd upgrade adwaita-icon-theme

And voilà, it installs!

So what I suspect is that the buildbot is not correctly handling the version number checks in pango/pangocoretext-shape.c? So in the following the CFStringGetLongCharacterForSurrogatePair has no definition inside pango on systems below 10.6.

Anyway, adwaita-icon-themes is now upgraded on my PPC 10.5.8 PowerBook G4, thanks a lot for your help.

[dbevans (David B. Evans)]

Replying to udbraumann:

So what I suspect is that the buildbot is not correctly handling the version number checks in pango/pangocoretext-shape.c? So in the following the CFStringGetLongCharacterForSurrogatePair has no definition inside pango on systems below 10.6.

Actually the code in pango providing a substitute for CFStringGetLongCharacterForSurrogatePair and friends is a recent patch so that may have something to do with it.

See ​2a29cd0/macports-ports

Closing as works for me.