This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 173298 - ImageMagick won't rebuild against current xorg setup
ImageMagick won't rebuild against current xorg setup
Product: Fedora
Classification: Fedora
Component: ImageMagick (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2005-11-15 20:16 EST by Rodd Clarkson
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-19 12:01:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description Rodd Clarkson 2005-11-15 20:16:37 EST
Description of problem:

I think Mike Harris ( asked for these bugs to be reported.

It appears that ImageMagick has hard coded links to /usr/X11R6/lib that need to
be addressed, and as such it won't build at the moment.

While trying to build against a current rawhide I get the following error message:

cpio: ImageMagick-6.2.5/<built-in>: No such file or directory
cpio: ImageMagick-6.2.5/PerlMagick/Magick.c: No such file or directory
20934 blocks
+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
* WARNING: 'check-rpaths' detected a broken RPATH and will cause 'rpmbuild'
*          to fail. To ignore these errors, you can set the '$QA_RPATHS'
*          environment variable which is a bitmask allowing the values
*          below. The current value of QA_RPATHS is 0x0000.
*    0x0001 ... standard RPATHs (e.g. /usr/lib); such RPATHs are a minor
*               issue but are introducing redundant searchpaths without
*               providing a benefit. They can also cause errors in multilib
*               environments.
*    0x0002 ... invalid RPATHs; these are RPATHs which are neither absolute
*               nor relative filenames and can therefore be a SECURITY risk
*    0x0004 ... insecure RPATHs; these are relative RPATHs which are a
*               SECURITY risk
*    0x0008 ... the special '$ORIGIN' RPATHs are appearing after other
*               RPATHs; this is just a minor issue but usually unwanted
*    0x0010 ... the RPATH is empty; there is no reason for such RPATHs
*               and they cause unneeded work while loading libraries
*    0x0020 ... an RPATH references '..' of an absolute path; this will break
*               the functionality when the path before '..' is a symlink
* Examples:
* - to ignore standard and empty RPATHs, execute 'rpmbuild' like
*   $ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild my-package.src.rpm
* - to check existing files, set $RPM_BUILD_ROOT and execute check-rpaths like
*   $ RPM_BUILD_ROOT=<top-dir> /usr/lib/rpm/check-rpaths
* 'check-rpaths' is part of 'fedora-rpmdevtools'.
ERROR   0001: file '/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/aut
o/Image/Magick/' contains a standard rpath '/usr/lib' in [/usr/lib:/usr
ERROR   0001: file '/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/aut
o/Image/Magick/' contains a standard rpath '/usr/X11R6/lib' in [/usr/li
error: Bad exit status from /var/tmp/rpm-tmp.95033 (%install)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.95033 (%install)
[rodd@localhost ~]$

Version-Release number of selected component (if applicable):

[rodd@localhost ~]$ rpm -qa ImageMagick\*

How reproducible:

Very, each time you try to build it.

Steps to Reproduce:
1.  I've install fedora-rpmdevtools-1.3-1.fc5 so I do a local build as a user
and then install as sudo.  Install fedora-rpmdevtools (sudo yum install
2.  Download ImageMagick- from the development SRPMS folder.
3.  Install the source as user (rpm -ivh ImageMagick-
4.  build ImageMagick using the following:
        rpmbuild -ba rpmbuild/SPECS/ImageMagick.spec --target $(uname -m)
Actual results:

Build fails with message above.

Expected results:

Build succeeds and solves problems with bug #172754 ;-]
Comment 1 Rodd Clarkson 2005-12-07 17:59:19 EST
I'm not seeing a lot of change with this.

Is this now building on FC5t1 (which I'm having troubles installing)?

Or is it still broken?
Comment 2 Mike A. Harris 2005-12-14 16:45:37 EST
I'd assume the bug is still present, at least until the package owner closes
it as "fixed in rawhide". ;)

If there are any problems with getting it to rebuild with modular X, please
let me know and I'll advise as needed.

Take care,
Comment 3 Matthias Clasen 2005-12-19 12:01:58 EST
The gcc 4.1 mass rebuild seems to have succeeded in rebuilding this...

Note You need to log in before you can comment on or make changes to this bug.