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

On 17 Feb 2010, at 7:58 PM, Bob Friesenhahn wrote:

>> While attempting to hunt down a leak of threads on RHEL5 (installed
>> from RPM), first port of call was to upgrade GraphicsMagick from
>> v1.3.7 to v1.3.10.
>>
>> The release notes tell us that the InitializeMagick() call is now
>> mandatory, so we added the call on startup, passing NULL as a
>> parameter. We are now getting the following error:
>>
>> Unable to access configuration file (delegates.mgk)
>
> Not good.
>
>> Picking apart the InitializeMagick() call, it leads me to
>> GetExecutionPath(), which makes various attempts on various OS'es to
>> find the executable name.
>
> 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?

> For the "uninstalled" case, GraphicsMagick does not use fixed paths  
> to find its components and so it needs to figure this out based on  
> where the executable (argv[0]) resides.  Usually this works fine,  
> but it depends on a particular install tree footprint.  Under Unix  
> it expects a 'bin' 'lib' 'share' type install tree so the program is  
> expected to live in 'bin', from which it can find its files in the  
> adjoining directories.

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

Regards,
Graham
--


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