"no encode delegate for this image format" on Linux?

[andraspap]

I get the following exception while trying to write tif files on Linux Red Hat 3 with the MagickWriteImage API:

Exception while writing TIF file:

no encode delegate for this image format
'./test.tif'

(On Red Hat 4 the animated GIF export also gives the same error with the MagickWriteImages API, on windows the code works fine.)

Can someone direct me to a possible resolution to this problem?
Thank you in advance!

[anthony]

You IM was not built with, or can not find the libtiff library.

[andraspap]

Thank you very much for your reply. Yes, I am discovering the problems with the way I build ImageMagcik, and now I build with the --disable-installed option to avoid hard coded paths to system libraries. This way I can make a small test program work.

The additional problem is that even with the --disable-installed option the /usr/lib/libMagick-5.5.6-Q16.so.0 is linked into my version 6.3.4 build. I wonder if I can build that too with my own ImageMagick build?


pc1-andras :/mnt/users/apap/dev3rd/ImageMagick/ExportTest>ldd /mnt/users/apap/RH3_1/lib/libWand.so.10
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x400c4000)
libz.so.1 => /usr/lib/libz.so.1 (0x40114000)
libMagick-5.5.6-Q16.so.0 => /usr/lib/libMagick-5.5.6-Q16.so.0 (0x40122000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40372000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x4037a000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40392000)
libm.so.6 => /lib/tls/libm.so.6 (0x40471000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40493000)
libc.so.6 => /lib/tls/libc.so.6 (0x404a3000)
libtiff.so.3 => /usr/lib/libtiff.so.3 (0x405db000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4061c000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4063b000)
libdpstk.so.1 => /mnt/users/apap/dev/MEMU/trunkA/lib/linux_debug/missing/libdpstk.so.1 (0x4065e000)
libdps.so.1 => /mnt/users/apap/dev/MEMU/trunkA/lib/linux_debug/missing/libdps.so.1 (0x40666000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x406ad000)
libbz2.so.1 => /usr/lib/libbz2.so.1 (0x406bb000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x406ca000)
libdl.so.2 => /lib/libdl.so.2 (0x407be000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x407c1000)

[anthony]

Looks like the libtool 'discovered' the old library in the build process.

Obviously a mistake, as you should have been able to override the LD_LIBRARY_PATH for the location of libraries. You could try re-compiling with
your current library location set with LD_LIBRARY_PATH during the build process.

I have seen software installs that need two or three re-build/installs to get the libraries correct. I did not think IM was one of these as I have used the "utilities/magick" script to run just build binaries before officially installing them.

In the mean time you could make a symbolic link called libMagick-5.5.6-Q16.so.0
which pointes to your new library, in a directory on your LD_LIBRARY_PATH. Then ldd should find this 'fake link' before the system library.

[andraspap]

Thank you for your answer. My problem is that my build (version 6.3.4) does not build a dll similar to /usr/lib/libMagick-5.5.6-Q16.so.0. (Certainly none with the string Q16 in it, although the "make install" installs the lib\ImageMagick-6.3.4\modules-Q16 directory.)

My major concern is not that a 5.5.6 version .so linked in, but that any .so form the system is getting linked in. I would like to avoid linking in /usr/lib/libMagick-6.3.4-Q16.so.0 even if my build machine had it.

I am wondering if linking in /usr/lib/libMagick-5.5.6-Q16.so.0 is actually a mistake by the build command, and no functions are called from this .so ever? Would there be a way to stop ImageMagick link to that library?

[anthony]

I never said it did build such a library. I said make a 'fake' link to your NEW library of the samer name as the old, IF you don't want to rebuild!

Which .so is linked in at runtime is controlled by two things.
-R path compile/link option uses during the compile (-R is used at RunTime)
and the LD_LIBRARY_PATH.

Which library is found during the compile (and hence the name it looks for later at runtime) is controled by -L path and -l library_file options and, again the LD_LIBRARY_PATH setting at compile time.

I suggested linking your new library to the old library name so if it finds that old library in YOUR direct on the LD_LIBRARY_PATH, before the /usr/lib system path
then it still uses the pointed to new library. It is a hack but it works.

Better to set LD_LIBRARY_PATH and/or appropriate -L path and -R paths in during the build.

[andraspap]

Thank you for giving your time to this issue, I would like to ask you for one final qualification for the sake of the peace of our minds.

Currently our 6.3.4 ImageMagick build links in /usr/lib/libMagick-5.5.6-Q16.so.0, (we do not have a newer version of this library at all) and our application is installed with this library from the build machine. (For example to make our Red Hat 3 build work on Red Hat 4 we need to have this library in our installation.)

I wonder why does not 6.3.4 ImageMagick builds its own "libMagick-6.3.4-Q16.so.0" and links with it? My concern is that we do not know if linking in and installing /usr/lib/libMagick-5.5.6-Q16.so.0. always will work fine (e.g. different Red Hat versions), we do not know what compiler it was built with e.t.c

If this is standard or it is not expected to cause any problems then I am relieved not to change our practice. Thank you again very much.

[anthony]

It should have built and installed the library .so file. You just need to try get the programs to find it before it finds the old one.

I believe I talked about this last week.

There is in the source is a magick.sh script that is designed to let you run a IM that have been built in the source area but has not installed. It does this by setting all the appropriate environment variables needed so the program finds the just built libraries and coder etc, and not the system version.

For example I configure and make the binaries, then in the top level of the source tree I can test it with a command like...

./magick.sh utilities/convert rose: -virtual-pixel background -background black \
-distort Perspective '0,0,0,45,69,0,69,45 0,0,0,45,60,10,60,35' x:

Which I used to check on perspective distortion changes I made but without installing it.