imlib2 did not build for pre-extras x86_64. The attached patch fixes this. Tested build on x86_64 and i386.
Created attachment 109173 [details] Patch for imlib2.spec that fixes build on x86_64
For the record, I was able to build imlib2 on fc2/x86_64 without this patch.
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
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.
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
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
> 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.
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.
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...
Why did you move the filter and loader libraries into the -devel sub-package? Seems like a wrong thing to do.
>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
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.
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.
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.
updated in cvs. Thanks. I suppose cvs resolution is considered as rawhide..
* 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.
It appears the update also includes /usr/lib/libImlib2.la which *is* safe to delete and IMO should not be included.
Re: comment #2, my success was only with the older imlib2-1.1.2, so not relavent here.