libpixbufloader

David Evans devans at macports.org
Fri Mar 6 15:41:50 PST 2009


Andy Schmitt wrote:
>
>
> So wait, are you saying that /opt/local/lib/gtk-2.0/2.10.0/loaders 
> *should* be present after gtk2 is installed?
No, I'm saying this is where it looks for loaders that are installed by 
other ports.  This path is hard coded into
the library (determined at configure). For instance on my system

# GdkPixbuf Image Loader Modules file
# Automatically generated file, do not edit
# Created by gdk-pixbuf-query-loaders from gtk+-2.14.7
#
# LoaderDir = /opt/local/lib/gtk-2.0/2.10.0/loaders
#
"/opt/local/lib/gtk-2.0/2.10.0/loaders/libopenraw_pixbuf.so"
"Digital camera RAW" 0 "gtk20" "Digital camera RAW images loader." "LGPL"
"image/x-adobe-dng" "image/x-canon-cr2" "image/x-canon-crw" 
"image/x-nikon-nef" "image/x-olympus-orf" "image/x-pentax-pef" 
"image/x-sony-arw" "image/x-epson-erf" "image/x-minolta-mrw" ""
"dng" "cr2" "crw" "nef" "orf" "pef" "arw" "erf" "mrw" ""
"MM *" "  z " 80
"II* \020   CR\002 " "   z zzz   z" 100
"II* " "   z" 80
"IIRO" "    " 100
" MRM" "z   " 100
"II\032   HEAPCCDR" "   zzz        " 100

"/opt/local/lib/gtk-2.0/2.10.0/loaders/svg_loader.so"
"svg" 2 "gtk20" "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" "*             " 100

libopenraw_pixbuf.so is installed by port libopenraw to allow loading of 
raw digital camera images
svg_loader.so is installed by port librsvg to allow loading of svg images

nothing installed by gtk2 because the loaders for the formats I 
mentioned in the last email are not loadable modules
but are built into the gdk_pixbuf library directly.
>
> No it's gtk2. The application in question is NetRadiant- an attempt at 
> maintaining a reliable stabilized distribution of gtkRadiant 1.5, 
> since no others are being maintained. Rudolf Polzer has 
> single-handedly taken this on, but I don't think he has the resources 
> to be testing OS X builds. Historically most OS X Radiant SRC and 
> binaries needed/were built with the Fink tools and libraries. Long 
> story short: the current post-make scripts packs up the executables 
> and dynamic libraries into an .app, but they assumed Fink, and in 
> particular /sw/lib/gtk-2.0/*/loaders/libpixbufloader-bmp.so.
>
If the app is built against the current gtk2 port, 
libpixbufloader-bmp.so is unnecessary and will never be called by the 
program because
the built in loader code will be used instead for loading a bmp.  So I 
think you can modify the post-make script to skip this and it should
work.
> Doing:
> port contents gtk2
> shows no sign of any of the libpixbufloader-xxx.so files
Right, shouldn't be any unless some other port puts one here to extend 
the range of files that can be loaded beyond what's built in.
>
> BTW does "port contents <name>" return what *was installed* with that 
> port or what *was supposed to have been installed*?
>
It shows what was actually installed -- there's no way in MacPorts to 
find out what *would* be installed without actually doing it.
> So, I don't know where that leaves me. Thanks for the informative 
> reply Dave.
Well, I hope this helps.  To summarize, I don't think you need the 
external bmp loader module at all.  It should work without it (assuming
everything built properly).

This is a common misunderstanding partly because gkdpixbuf's name 
doesn't make it clear this is a gtk1 version.  It will probably go
away one of these days (along with gtk1 and glib1) but for now there are 
a few gtk1 ports left that depend upon it.

Dave


More information about the macports-users mailing list