Bug 143863

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.