Bug 173298 - ImageMagick won't rebuild against current xorg setup
Summary: ImageMagick won't rebuild against current xorg setup
Alias: None
Product: Fedora
Classification: Fedora
Component: ImageMagick
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-16 01:16 UTC by Rodd Clarkson
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2005-12-19 17:01:58 UTC

Attachments (Terms of Use)

Description Rodd Clarkson 2005-11-16 01:16:37 UTC
Description of problem:

I think Mike Harris (mharris@redhat.com) 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/Magick.so' 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/Magick.so' 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 22:59:19 UTC
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 21:45:37 UTC
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 17:01:58 UTC
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.