Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The official ImageMagick site only keeps the latest versions. Even in
the legacy/ directory, they only keep the last version of each
'branch'. Therefore, to avoid problems, we use an alternate download
site.
Fixes
http://autobuild.buildroot.org/results/2269aa42a0a21730ff0ec28af89cd4973ec28751/build-end.log.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The recent zlib bump broke imagemagick. This has been fixed upstream
in 6.7.5, but the xml2-config fix is still not upstream and 6.7.5
needs autoconf 2.67 to autoreconf (and we have 2.65), so we cannot
easily use that.
Instead move to the most recent version using autoconf 2.64 and
backport the fix from imagemagick svn. At the same time also
ensure zlib+bzip2 support is picked up if enabled.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thanks to the pkgparentdir and pkgname functions, we can rewrite the
AUTOTARGETS macro in a way that avoids the need for each package to
repeat its name and the directory in which it is present.
[Peter: pkgdir->pkgparentdir]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The patch imagemagick-6.6.4-add-errno-h-if-argz-h-does-not-exist.patch
was not applied anymore due to a difference in the version number, and
it didn't prevent imagemagick to be built. It was introduced several
years ago together with the ImageMagick package itself, so presumably
it is no longer needed.
The new patch allows ImageMagick to use the correct xml2-config script
to get the proper location for XML2 headers and libraries. Otherwise,
-I/usr/include/libxml2 is found in the compile flags.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
program-transform-name='s,,,' is needed, otherwise configure defines it
as $(platform)-$(cpu)-. During install, all executables are prepended
with this variable.
[Peter: disable libtool patch, remove unneeded/wrong staging install cmd]
Signed-off-by: Martin Banky <Martin.Banky@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For some reason, the imagemagick Buildroot .mk file creates a
"datefile" file in the Buildroot source directory, probably an ancient
debugging thing that has been left here for no reason. Let's get rid
of it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For some reason, our imagemagick.mk file calls libtool, but assumes
that libtool is available on the host, which may not be
true. Therefore, we use ImageMagick's internal libtool, which has been
used for compiling/linking all the rest of ImageMagic anyway.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
imagemagick configure script wants to run programs to detect the
file_offset_bits, but fails since it is running cross-compile
mode. Therefore, we help the configure script by passing the
appropriate ac_cv variable.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Closes#657
imagemagick-clean target currently tries to remove $(TARGET_DIR) as
there is no IMAGEMAGICK_BINARY anymore.
Signed-off-by: Simon Pasch <fpasch@googlemail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Fix various breakage in the imagemagick build:
- libWand.* is now called libMagickWand.*
- libMagic.* is now called libMagickCore.*
- References to wrong version numbers in directories
- Libraries missing from clean target
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We have been passing -q to ./configure when using 'make -s' for
packages using Makefile.autotools.in for some time. Do the same
for packages using autotools, but not using the
Makefile.autotools.in infrastructure, taking care to not do it
for packages with hand written configure scripts.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
A C library will have been built by the toolchain makefiles, so there is no
need for packages to explicitly depend on uclibc.
Signed-off-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
