> I installed the ImageMagick package found here:
>
> http://www.entropy.ch/software/macosx/welcome.html#imagemagick
>
> and it says it installed OK, although I can't do "mogrify -args
> file" I have to do "/usr/local/bin/mogrify -args file"
That's your first clue - the package you installed has (correctly,
IMNSHO) been configured to use the default prefix of /usr/local. That
means that its command-line tools are in /usr/local/bin, libraries
in /usr/local/lib, header files in /usr/local/include, etc.
That's a *good* thing, because those locations are safe from future
updates to the Apple-managed directories /usr/bin, /usr/lib, and /usr/
include.
The reason you need to spell out the full path to /usr/local/bin/
mogrify is simply that /usr/local/bin is not in your $PATH. This is
very basic Unix 101 - just edit ~/.bashrc and add a line like this:
PATH=$PATH:/usr/local/bin
> Then I go to install the perl Image::Magick module from CPAN, which
> fails with hundreds of lines of errors which look like they relate
[quoted text clipped - 3 lines]
> Magick.xs:181: warning: data definition has no type or storage class
> Magick.xs:182: error: parse error before '}' token
Errors can have a "cascade" effect, where an earlier error can
trigger later ones. So, when troubleshooting, always look at the
*first* error, not the last one. At the beginning of these hundreds
of lines, you'll find the root cause, an error that looks like this:
Magick.xs:63:32: error: magick/ImageMagick.h: No such file or
directory
So, why can't it find ImageMagick.h, and how do you tell it where to
find that file? When all else fails, read the instructions. ;-)
In the CPAN shell, use "look Image::Magick" to download and unpack
the module, and open up a subshell in the build directory. Use "less
README.txt" to read the instructions. Immediately after the line that
reads "cd PerlMagick", we find:
Next, edit Makefile.PL and change LIBS and INC to include the
appropriate path information
> and I notice that I'm installing not actually Image::Magick but
> something called PerlMagick, although I have installed a module
[quoted text clipped - 4 lines]
>
> it returns the error "can't open file `'".
PerlMagick is the name of the package. Image::Magick is one of
several modules included in the PerlMagick package.
BTW, if you've already installed it, why are you installing it again???
> One further mystery is that the Image::Magick module doesn't seem
> to work like a regular Perl module at all. I'm told, on this page:
[quoted text clipped - 5 lines]
> $x = $image->Crop(geometry=>'100x100"+100"+100');
> warn "$x" if "$x";
Looks like perfectly legal Perl to me.
> rather than what I expect:
>
> $image->Crop(geometry=>'100x100"+100"+100') or die "$!";
I'm confused. Why would you expect a module to work in a manner
that's contrary to what its documentation clearly states?
> so, what's the point of a Perl module which doesn't work like Perl?
Every heard the expression "There's More Than One Way to Do It"?
A couple of possible reasons come to mind for writing the Crop()
method that way. My immediate suspicion is that the Perl module
simply provides a thin "wrapper" around the C functions, and the C
functions were written that way. Or it may have been the module
author's preference.
Whatever the reason, it's just a trivial stylistic issue - hardly
something worth getting all bent out of shape over.
> And what is PerlMagick? Is it a binary containing the same code as
> ImageMagick or just an interface to it?
ImageMagick is a library. PerlMagick provides Perl-language access to
the C functions in that library.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
John Horner - 30 Oct 2005 05:28 GMT
> the package you installed has (correctly, IMNSHO) been configured to
> use the default prefix of /usr/local. [...] edit ~/.bashrc
OK, got that part, thanks.
> when troubleshooting, always look at the *first* error, not the last
> one. At the beginning of these hundreds of lines, you'll find the root
> cause, an error that looks like this:
>
> Magick.xs:63:32: error: magick/ImageMagick.h: No such file or
> directory
Actually no. But I have got this:
cc: @CPPFLAGS@: No such file or directory
cc: @: No such file or directory
cc: @LFS_CPPFLAGS@: No such file or directory
cc: @DEFS@: No such file or directory
In file included from Magick.xs:63:
/usr/local/include/magick/ImageMagick.h:774: error: `MaxTextExtent'
undeclared here (not in a function)
> edit Makefile.PL and change LIBS and INC to include the appropriate
> path information
Since I wrote the email, I've been trying to do that (although the
errors above seem to suggest that it's already looking in usr/local/)
and I'm a bit lost.
This is what I have for LIBS:
'LIBS' => ['-L/usr/lib -lMagick -L/usr/X11R6/lib64 -L/usr/lib -ltiff
-ljpeg -lpng -ldpstk -ldps -lXext -lXt -lSM -lICE -lX11 -lbz2 -lxml2
-lpthread -lm -lpthread']
and this is INC
'INC' => '-I../ -I.. -I/usr/include/freetype2 -I/usr/X11R6/include
-I/usr/X11R6/include/X11 -I/usr/include/libxml2'
so, can I get a hint on how to change those things? Add new items,
replace some of the ones there already? Add "/usr/local/" only or
"/usr/local/lib/" or something more specific? I'm particularly
mystified by the uppercase and lowercase "L"s.
> Why would you expect a module to work in a manner that's contrary to
> what its documentation clearly states?
I don't, but I've become used to being able to look for errors in $!. I
can see that this module is pretty much a wrapper around ImageMagick
code and that "mogrify" and pals return nothing at all unless
something's gone wrong, but ... I guess I've just never come across a
module like that before. Plus, if some of its methods return values
because they need to, and some of its methods only return values if
something's gone wrong, that's confusing.
Sherm Pendley - 30 Oct 2005 08:12 GMT
> Actually no. But I have got this:
>
[quoted text clipped - 5 lines]
> /usr/local/include/magick/ImageMagick.h:774: error: `MaxTextExtent'
> undeclared here (not in a function)
Those @FOO@ strings are placeholders, they shouldn't appear in
Makefile.PL. Are you certain that you're running "perl Makefile.PL",
not "perl Makefile.PL.in"?
Also, you need to be sure you're using the same version of
ImageMagick and PerlMagick. The version of ImageMagick listed on the
page you mentioned is 6.1.7, but the version of PerlMagick that's on
CPAN is 6.2.4. So, if you insist on using such an old version of the
library, you'll need to fetch and install the Perl module by hand.
> This is what I have for LIBS:
>
[quoted text clipped - 11 lines]
> usr/local/lib/" or something more specific? I'm particularly
> mystified by the uppercase and lowercase "L"s.
They're compiler and linker flags. The upper-case letters add to the
include search path (-I) and the library search path (-L). The lower
case -l tells the linker to link against a library.
In simple terms, you can think of them as being roughly equivalent to
pushing a path onto @INC.
> I don't, but I've become used to being able to look for errors in $!.
Sure, it's odd. Every module has its quirks though. I've seen worse.
When in Rome... ;-/
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
John Horner - 30 Oct 2005 23:20 GMT
>Those @FOO@ strings are placeholders, they shouldn't appear in
>Makefile.PL. Are you certain that you're running "perl Makefile.PL",
>not "perl Makefile.PL.in"?
Absolutely sure.
>if you insist on using such an old version of the
>library, you'll need to fetch and install the Perl module by hand.
I'd love to be able to use the matching Perl module, 6.1.7 -- how
would I do that? CPAN has precisely two versions, 5.5.7 and 6.2.4. I
might be better off getting the ImageMagick library to match the
library rather than the other way around.
>They're compiler and linker flags. The upper-case letters add to the
>include search path (-I) and the library search path (-L). The lower
>case -l tells the linker to link against a library.
Could you please, in the spirit of "teach a man to fish", show me
what you would do to those LIB and INC settings in order to have the
Makefile work correctly?
jh
Sherm Pendley - 31 Oct 2005 00:28 GMT
> I'd love to be able to use the matching Perl module, 6.1.7 -- how
> would I do that?
Beats me. You might be able to find a copy in an antiques shop. ;-)
> CPAN has precisely two versions, 5.5.7 and 6.2.4. I might be better
> off getting the ImageMagick library to match the library rather
> than the other way around.
"Better off" is putting it mildly. Matching versions is a requirement
- that's why the library includes a copy of the module.
>> They're compiler and linker flags. The upper-case letters add to the
>> include search path (-I) and the library search path (-L). The lower
[quoted text clipped - 3 lines]
> what you would do to those LIB and INC settings in order to have
> the Makefile work correctly?
You're focusing on a symptom instead of the cause. The question is
why is Makefile.PL incorrect in the first place - I downloaded a copy
from CPAN and looked. Makefile.PL does *not* contain those @FOO@
placeholder strings you mentioned earlier. Makefile.PL.in *does*
contain them.
My advice - Forget about trying to fix Makefile.PL by hand, and
delete the binary package. I'm sure the author meant well, but it's
turning into more trouble than it's worth. After all, the point of
the package is supposed to be to make your life easier, not more
difficult.
First, use Fink or DarwinPorts to install the graphics libraries you
care about - libjpeg, libgif, libpng, libtiff, whatever. Then go to
the <http://www.imagemagick.org> site, download the latest source
package, unpack and configure it with the following:
./configure CPPFLAGS=-I/sw/include LDFLAGS=-L/sw/lib
If you're using DarwinPorts instead of Fink, use /opt/local instead
of /sw in the above.
Check the output of this command to make sure all went well. In
particular, check the last block of output to make sure you're
getting support for the formats you want. If everything is well,
build and install:
make
sudo make install
This will install the Perl module as part of the process, and since
it's bundled with the library they're guaranteed to match in both
version and configuration. This hassle of obtaining them separately
and getting them to work together is precisely the reason that a copy
of the Perl module is included with the library and built at the same
time.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org