Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 74415 - SRPM 2.1.2-7 doesn't generate
Summary: SRPM 2.1.2-7 doesn't generate
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: freetype
Version: 1.0
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Brock Organ
: 76766 79211 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-09-23 21:55 UTC by Andre
Modified: 2007-04-18 16:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-01-03 21:16:59 UTC

Attachments (Terms of Use)
Full RPM build dump (deleted)
2002-09-23 21:57 UTC, Andre
no flags Details

Description Andre 2002-09-23 21:55:47 UTC
Description of Problem:
SRPM fails to generate binary RPMS from a full rebuild 
complaining that 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/
Requires: freetype = 2.1.2-7

RPM build errors:
    File not found by glob: /var/tmp/freetype-2.1.2-root/usr/lib/*
    File not found: /var/tmp/freetype-2.1.2-root/usr/lib/

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 21:57:35 UTC
Created attachment 76925 [details]
Full RPM build dump

Comment 2 Owen Taylor 2002-09-23 22:28:24 UTC
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-24 00:02:38 UTC
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 Maybe something is wrong with it.



Comment 4 Arkadiusz Miskiewicz 2002-09-27 11:08:59 UTC
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 14:53:07 UTC
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 16:49:37 UTC
Are config.* with proper permissions? (755)

install -m755 /usr/share/automake/config.* .

Comment 7 Andre 2002-09-27 21:37:09 UTC
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 20:50:59 UTC
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 22:10:15 UTC
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 20:32:52 UTC
*** Bug 76766 has been marked as a duplicate of this bug. ***

Comment 11 Owen Taylor 2002-11-01 02:38:42 UTC
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 11:40:59 UTC
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 20:31:28 UTC
*** Bug 79211 has been marked as a duplicate of this bug. ***

Comment 14 Owen Taylor 2003-01-03 21:16:59 UTC
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.