This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 143863 - imlib2 build failed on x86_64
imlib2 build failed on x86_64
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: imlib2 (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-30 04:31 EST by Thorsten Leemhuis
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-17 05:55:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch for imlib2.spec that fixes build on x86_64 (1.55 KB, patch)
2004-12-30 04:31 EST, Thorsten Leemhuis
no flags Details | Diff
fix x86_64 issues, update to 1.2.0 (4.31 KB, patch)
2005-01-09 14:03 EST, Thorsten Leemhuis
no flags Details | Diff

  None (edit)
Description Thorsten Leemhuis 2004-12-30 04:31:15 EST
imlib2 did not build for pre-extras x86_64. The attached patch fixes this.
Tested build on x86_64 and i386.
Comment 1 Thorsten Leemhuis 2004-12-30 04:31:15 EST
Created attachment 109173 [details]
Patch for imlib2.spec that fixes build on x86_64
Comment 2 Rex Dieter 2005-01-04 08:48:28 EST
For the record, I was able to build imlib2 on fc2/x86_64 without this
patch.
Comment 3 Michael Schwendt 2005-01-04 10:44:22 EST
Exactly the same version as found in CVS? Because this is how it failed:
http://linux.duke.edu/~skvidal/misc/extras/x86_64/logs/imlib2.log
Comment 4 Matthias Saou 2005-01-05 13:29:53 EST
Your failure is due to the --enable-mmx, which doesn't want to work on
x86_64 unfortunately. You didn't put --with-pic either, and I think
it'll also be needed.
OTOH, those libdir being overridden in the above patch were never
needed for me. Basically, what works for me is (I don't have any ia64
to test ;-)) :

%configure \
    --with-pic \
%ifarch %{ix86}
    --enable-mmx
%else
    --disable-mmx
%endif
%{__make} %{?_smp_mflags}

This also works on ppc.
Comment 5 Thorsten Leemhuis 2005-01-09 09:50:47 EST
Re 4 From Matthias Saou  on 2005-01-05 13:29 
> Your failure is due to the --enable-mmx, which doesn't want to work on
> x86_64 unfortunately. You didn't put --with-pic either, and I think
> it'll also be needed.

??? That's all covered by the patch already ;-)

>OTOH, those libdir being overridden in the above patch were never
>needed for me.

Otherwise it tried to install to /usr/lib here; see

http://www.leemhuis.info/files/fedorarpms/misc/imlibbuild.x86_64.error
Comment 6 Thorsten Leemhuis 2005-01-09 14:03:21 EST
Created attachment 109538 [details]
fix x86_64 issues, update to 1.2.0 

Created an attachment (id=109537)
fix x86_64 issues and update to 1.2.0

Updated package:
http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/imlib2-1.2.0-1.src.rpm
  MD5:	5f664997927eb02a4b25da67ee187585

Spec:
http://www.leemhuis.info/files/fedorarpms/SPECS.fdr/imlib2.spec

Diffs:
http://www.leemhuis.info/files/fedorarpms/DIFFS.fdr/imlib2-1.1.2-1_diff_vs_imlib2-1.2.0-1.diff



Changelog:
- Ship .la files ue to a bug in kdelibs; see
https://bugzilla.fedora.us/show_bug.cgi?id=2284
http://bugzilla.redhat.com/bugzilla/142244
http://bugs.kde.org/93359
- Use make param LIBTOOL=/usr/bin/libtool - fixes hardcoded rpath on x86_64
- fix hardcoded rpath im Makefiles on x86_64 due to freetype-config --libs
returning "-L/usr/lib64 -Wl,--rpath -Wl,/usr/lib64 -lfreetype -lz"
- Update to 1.2.0 -- fixes several security issues
- remove explicit libdir=_libdir - 1.2.9 does not need it anymore
- removeddemo compile/install;
- use configure param --x-libraries={_prefix}/X11R6/{_lib} and patch to fix
"cannot find -lX11"

Notes: 
- Build tested on x86_64 and i386; did not have time for more yet
Comment 7 Michael Schwendt 2005-01-09 17:52:06 EST
>  rm -f \
> -  $RPM_BUILD_ROOT%{_libdir}/libImlib2.la \
> -  $RPM_BUILD_ROOT%{_libdir}/imlib2_loaders/*/*.*a \
>    $RPM_BUILD_ROOT%{_bindir}/{color_spaces,imlib2,*test}

This change is a bit too much, since it puts back in the static
archives in /usr/lib/imlib2/filters/ and /usr/lib/imlib2/loaders/,
which are of no use.
Comment 8 Michael Schwendt 2005-01-10 03:08:48 EST
Done a bit of Python metadata tool hacking: Matthias' giblib, libcaca
and camE packages seem to be the only imlib2 dependencies. All three
build with the 1.2.0 upgrade at least.
Comment 9 Thorsten Leemhuis 2005-01-10 12:40:58 EST
Updated package:
http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/imlib2-1.2.0-2.src.rpm
  MD5:  3eb092ad3ccd138878553501ff8c81e3

Spec:
http://www.leemhuis.info/files/fedorarpms/SPECS.fdr/imlib2.spec

Diffs:
http://www.leemhuis.info/files/fedorarpms/DIFFS.fdr/imlib2-1.2.0-1_diff_vs_imlib2-1.2.0-2.diff
http://www.leemhuis.info/files/fedorarpms/DIFFS.fdr/imlib2-1.1.2-1_diff_vs_imlib2-1.2.0-2.diff

Changelog:
- Don't ship *.?.a in {_libdir}/imlib/filters/ and loaders/

Notes:
- Checked build with ffmpeg -- works also fine
- Is there somewhere a abicheck-(for-rpmbuilders-)howto? Or can I
safely assume there are no abi/api problems with already build
packages? Probably not...
Comment 10 Matthias Saou 2005-01-14 12:45:40 EST
Why did you move the filter and loader libraries into the -devel
sub-package? Seems like a wrong thing to do.
Comment 11 Thorsten Leemhuis 2005-01-14 14:11:30 EST
>Why did you move the filter and loader libraries into the -devel
>sub-package? Seems like a wrong thing to do.

That happend accidentally... Thanks for noticing.

Updated package:
http://www.leemhuis.info/files/fedorarpms/SRPMS.fdr/imlib2-1.2.0-3.src.rpm
  MD5:  90dd359c285df40067a9210ea2ed46bd

Spec:
http://www.leemhuis.info/files/fedorarpms/SPECS.fdr/imlib2.spec

Diffs:
http://www.leemhuis.info/files/fedorarpms/DIFFS.fdr/imlib2-1.2.0-2_diff_vs_imlib2-1.2.0-3.diff
http://www.leemhuis.info/files/fedorarpms/DIFFS.fdr/imlib2-1.1.2-1_diff_vs_imlib2-1.2.0-3.diff

Changelog:
- Move filters and loaders back into main package where they belong
Comment 12 Michael Schwendt 2005-01-16 11:19:17 EST
Thorsten, as pointed out in comment 8, Matthias' packages seem to be
the only ones which depend on imlib2. I have no means of testing them.
freshrpms still uses imlib2 1.1.2.

API compatibility can be tested with rebuilds, reading changelogs and
reading imlib2-devel rpmdiff against previous release. For testing ABI
compatibility, the "abicheck" tool (in package "abicheck") is helpful,
but experimental. At fedora.us we keep it in unstable, because it is a
large Perl script which breaks easily when output of glibc-tools and
binutils changes.
Comment 13 Thorsten Leemhuis 2005-01-16 11:42:55 EST
Thanks Michael.

Just for the record; I had (and have) no intention to take over this
package ; I just wanted to fix x86_64 build issues ;-) But while at it
I thought I could do the update to 1.2.0 because of the security
issues mentioned in Bug 144596 . And also fix another fedora.us bug
(missing .la files, see http://bugzilla.fedora.us/show_bug.cgi?id=2284 ). 

So Anvil I think it's now up to you as maintainer. If you don't have
time just say and I'll try to bring the above package through
fedora.us QA.
Comment 14 Matthias Saou 2005-01-16 16:35:52 EST
Two things :
1) We are nowhere near "production" for Extras, so if things seem ok
at first sight, just update and let any bug reports of breakage come
in later on.
2) I wouldn't mind taking ownership of this package, especially as you
mentionned, I already take care of all the only current ones that
depend on it.
Comment 15 Dams 2005-01-17 05:55:42 EST
updated in cvs. Thanks.
I suppose cvs resolution is considered as rawhide..
Comment 16 Michael Schwendt 2005-01-18 15:46:55 EST
* File imlib2-1.2.0.tar.gz Size 890457 STORED OK
* Submitted 1.2.0-4 to really fix fedora.us bug #2284.
* Going to request FC3 build.
Comment 17 Rex Dieter 2005-01-19 08:20:25 EST
It appears the update also includes /usr/lib/libImlib2.la which *is*
safe to delete and IMO should not be included.
Comment 18 Rex Dieter 2005-01-19 08:21:13 EST
Re: comment #2, my success was only with the older imlib2-1.1.2, so
not relavent here.

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