Red Hat Bugzilla – Bug 74415
SRPM 2.1.2-7 doesn't generate libttf.so
Last modified: 2007-04-18 12:46:50 EDT
Description of Problem:
SRPM fails to generate binary RPMS from a full rebuild
complaining that libttf.so libs are not there.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rpmbuild --rebuild freetype-2.1.2-7.src.rpm
Processing files: freetype-devel-2.1.2-7
error: File not found: /var/tmp/freetype-2.1.2-root/usr/lib/libttf.so
Requires: freetype = 2.1.2-7
RPM build errors:
File not found by glob: /var/tmp/freetype-2.1.2-root/usr/lib/libttf.so.*
File not found: /var/tmp/freetype-2.1.2-root/usr/lib/libttf.so
(RPM standard successful build output)
Running RH 7.1 with RPM 4.1, gcc-3.2, libtool-1.4.2
Created attachment 76925 [details]
Full RPM build dump
Looks like something is screwy with your RPM configuration -
athlon-redhat-linux isn't a valid target, so libtool doesn't know
how to build shared libraries for it.
checking target system type... Invalid configuration `athlon-redhat-linux':
machine `athlon-redhat' not recognized
Good catch, thks for spotting it. Yes, it might be something with my RPM
config. During compile, this happens earlier:
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.55945
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd freetype-2.1.2
+ export 'CFLAGS=-O2 -march=athlon-xp' 'CXXFLAGS=-O2 -march=athlon-xp'
+ CFLAGS=-O2 -march=athlon-xp
+ CXXFLAGS=-O2 -march=athlon-xp
+ make setup CFG=--prefix=/usr
cd builds/unix; ./configure --prefix=/usr
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
and it seems to correspond to this on the spec file:
# Build Freetype 2
export CFLAGS="$RPM_OPT_FLAGS" CXXFLAGS="$RPM_OPT_FLAGS"
make setup CFG="--prefix=/usr"
However, this snippet of the spec file is the one causing trouble:
# Build Freetype 1.4
%configure --disable-debug \
--enable-static --enable-shared \
it results in these being executed:
+ cd freetype-pre1.4
+ CFLAGS=-O2 -march=athlon-xp
+ export CFLAGS
+ CXXFLAGS=-O2 -march=athlon-xp
+ export CXXFLAGS
+ FFLAGS=-O2 -march=athlon-xp
+ export FFLAGS
+ ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--target=athlon-redhat-linux --program-prefix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --disable-debug
--enable-static --enable-shared --with-locale-dir=/usr/share/locale
So, it looks like %configure is translated into *a lot* of things... looks
like the offending parameter is '--target=athlon-redhat-linux'.
Any idea on where I can find how %configure is defined? I recently upgraded
to RPM 4.1, from www.rpm.org. Maybe something is wrong with it.
Your config.sub is simply old and doesn't understand athlon-* system. Example:
[misiek@arm misiek]$ /home/users/misiek/.CVS-OTHER/ntop/ntop/config.sub
Invalid configuration `athlon-pld-linux': machine `athlon-pld' not recognized
[misiek@arm misiek]$ /usr/share/automake/config.sub athlon-pld-linux
Add install /usr/share/automake/config.* . before %configure and if you have
quite new automake then everything will be fine.
You're right, the config.sub file that comes with freetype-pre1.4 is the
one to blame. I have automake-1.5-1 installed, and
/usr/share/automake/config.sub runs just fine on my machine, which means
that your suggestion should work.
However, it looks like this is not enough: pre1.4's old 'configure' calls
the new 'config.sub' with extra parameters and make it choke (shell verbose
mode enabled to see output below):
+ /bin/sh /usr/src/redhat/BUILD/freetype-2.1.2/freetype-pre1.4/config.sub
+ echo 'configure: error: can not run
configure: error: can not run
+ exit 1
It seems freetype-pre1.4 old code is incompatible with current
automake/autoconf setups. This brings the question: is anybody actually
able to create binary RPMS from RawHide SRPM on Athlon machines? Do I
really need the pre-1.4 version?
Are config.* with proper permissions? (755)
install -m755 /usr/share/automake/config.* .
AAMOF they were, but I believe this is not the issue (the error msg is
misleading). What happens is that freetype-pre1.4 'configure' script tries to
pass a parameter ('sun4', see my previous msg) to the new config.sub, which is
not supposed to accept such parameter, causing it choke and generate the error.
This is why I am skeptical about freetype-pre1.4 being able to be generated on
Athlon machines -- it relies on an outdated version of automake/autoconf which
is incompatible with athlon arch. IMHO freetype-2.1.2 might need some
repackaging to avoid this bug and allow athlon RPMs to be built.
I'm having the same problem building Freetype (2.1.2-7) from the SRPM on an
Athlon, so I installed RH8.0 on a P4 machine and found that I couldn't build
there either. Next I'll dig out an old Celeron and see if I can build it there.
I tried a quick hack on config.sub to recognize *athlon* as the same as a P2
and didn't have any luck.
I wonder how this was built in the first place; surely Red Hat does their x86
builds on modern fast P4 or Athlon machines.
I tried to build on a PIII machine and it didn't build there either. I now
believe that this package simply cannot be built on a Red Hat 8 system. It
builds under 7.2 and 7.3 (7.1 is too old), even on Athlons, but of course I'm
concerned about compiler differences and such. Nothing left but to try it.
*** Bug 76766 has been marked as a duplicate of this bug. ***
I've built the package many times on a PIII system; don't know why
it isn't working for you there.
On PIII it should compile just fine. In fact, even on my machine, if I use
'--target i386' it compiles ok. It fails only if I try to use these settings
on my /etc/rpmrc:
buildarchtranslate: athlon: athlon
buildarchtranslate: i686: athlon
optflags: athlon -O2 -march=athlon-xp
(which BTW work just fine for almost all compilations I make, except for a few
other cases that show similar behavor -- one of them is fftw-2.1.3.src.rpm,
which also fails for similar reasons)
*** Bug 79211 has been marked as a duplicate of this bug. ***
Basically, the problem is that the freetype-1.4 code uses a really
old version of libtool that doesn't handle --target properly. There
was a patch in the RPM to hack around the problem, but part of it
had been lost. I've fixed it for 2.1.3-3