Re: InitializeMagick() causes GraphicsMagick to not find its config files

Bob Friesenhahn <[email protected]> Fri, 19 Feb 2010 10:25:56 -0600 (CST)
Newsgroups gmane.comp.video.graphicsmagick.bugs
Message-ID <[email protected]>
On Fri, 19 Feb 2010, Graham Leggett wrote:

>>
>> Normally this code path would only be used if the --disable-
>> installed option is provided to configure.  Is that option being used?
>
> The RPM spec file passes the following parameters to ./configure:
>
> ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-
> gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --
> exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/
> etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/
> com --mandir=/usr/share/man --infodir=/usr/share/info --enable-libtool-
> verbose --with-included-ltdl --enable-shared --disable-static --with-
> modules --with-frozenpaths --with-perl --with-perl-options= --with-
> magick-plus-plus --with-quantum-depth=8
>
> Does the --with-frozenpaths option do anything that might affect this?

The frozenpaths option should only influence if full paths are 
substituted in delegates.mgk, or if bare program names are inserted 
instead.  It is used by the configure script only.

Please check magick/magick_config.h in the build directory to see if 
this text is present:

/* GraphicsMagick is formally installed under prefix */
#define UseInstalledMagick 1

Also, please do 'make check' in the build directory and see if the 
test suite works.

In magick/magick.c InitializeMagickClientPathAndName() I see the code 
which would be invoked if UseInstalledMagick is not defined.

> We're seeing some very odd behaviour that seems inconsistent on our
> side.
>
> We have an int, test and stage environment, with GraphcisMagick
> v1.3.10 installed as an RPM, our library that calls GraphicsMagick
> installed as an RPM, and the Apache httpd module that calls the
> library that calls GraphicsMagick installed as an RPM, and
> GraphcisMagick works fine on int and test, but not on stage, where it
> does the following:
>
> MagickReadImageBlob: No decode delegate for this image format (JPEG)
> MagickSetSize/MagickReadImage: Unable to open file (#FFFFFF)
> Is it correct to say that the above two errors are likely to appear if
> InitiliazeMagick() didn't succeed? Or could the error be something

A number of the configuration files (.mgk files) have become severely 
abbreviated as of the 1.3.8 release so that they are only used for 
user-extension, and the part which was always constant is embedded in 
the library.  However, these files are normally installed into 
versioned directories so I don't see how the wrong ones could be used.

> else entirely? In all three cases, we are passing a path that the
> library that calls GraphicsMagick has access to (it has loadable
> modules), which has a value of "/usr/lib64/<foo>/".
>
> Is GraphicsMagick able to find itself (in /usr/lib64/
> GraphicsMagick-1.3.10/) based on this path?

In the default case, the paths are substituted into 
magick/magick_config.h, and these paths become hard-coded into the 
binaries.  If your build was configured for a particular directory 
footprint, but the install was into a different footprint, then there 
would be a problem.  Perhaps there is a bug in the configure script 
which effectively causes this.  Please do something like:

   grep Path magick/magick_config.h

in the build directory and verify that the paths match what you are 
expecting based on your configure requests.

Lastly, the full details of how GraphicsMagick is searching for 
configuration files may be revealed like

   env MAGICK_DEBUG=configure gm convert ...

Bob
--
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev