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® 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