Bug 74415 - SRPM 2.1.2-7 doesn't generate libttf.so
SRPM 2.1.2-7 doesn't generate libttf.so
Product: Red Hat Raw Hide
Classification: Retired
Component: freetype (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
Brock Organ
: 76766 79211 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-09-23 17:55 EDT by Andre
Modified: 2007-04-18 12:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-03 16:16:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Full RPM build dump (7.96 KB, application/x-bzip2)
2002-09-23 17:57 EDT, Andre
no flags Details

  None (edit)
Description Andre 2002-09-23 17:55:47 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):

How Reproducible:

Steps to Reproduce:
1. rpmbuild --rebuild freetype-2.1.2-7.src.rpm

Actual Results:
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

Expected Results:
(RPM standard successful build output)

Additional Information:
Running RH 7.1 with RPM 4.1, gcc-3.2, libtool-1.4.2
Comment 1 Andre 2002-09-23 17:57:35 EDT
Created attachment 76925 [details]
Full RPM build dump
Comment 2 Owen Taylor 2002-09-23 18:28:24 EDT
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
Comment 3 Andre 2002-09-23 20:02:38 EDT
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
make setup CFG="--prefix=/usr"

However, this snippet of the spec file is the one causing trouble:

# Build Freetype 1.4
cd %{ft1}
%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.


Comment 4 Arkadiusz Miskiewicz 2002-09-27 07:08:59 EDT
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.
Comment 5 Andre 2002-09-27 10:53:07 EDT
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):

+ enable_fast_install=yes
+ /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?



Comment 6 Arkadiusz Miskiewicz 2002-09-27 12:49:37 EDT
Are config.* with proper permissions? (755)

install -m755 /usr/share/automake/config.* .
Comment 7 Andre 2002-09-27 17:37:09 EDT
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.
Comment 8 Jason Tibbitts 2002-10-21 16:50:59 EDT
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.
Comment 9 Jason Tibbitts 2002-10-22 18:10:15 EDT
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.
Comment 10 Owen Taylor 2002-10-31 15:32:52 EST
*** Bug 76766 has been marked as a duplicate of this bug. ***
Comment 11 Owen Taylor 2002-10-31 21:38:42 EST
I've built the package many times on a PIII system; don't know why
it isn't working for you there.
Comment 12 Andre 2002-11-01 06:40:59 EST
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)
Comment 13 Owen Taylor 2003-01-03 15:31:28 EST
*** Bug 79211 has been marked as a duplicate of this bug. ***
Comment 14 Owen Taylor 2003-01-03 16:16:59 EST
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

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