Bug 58468 - rpm's %configure often makes configure think it's cross-compiling
rpm's %configure often makes configure think it's cross-compiling
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: redhat-rpm-config (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-17 10:24 EST by Bernhard Rosenkraenzer
Modified: 2007-04-18 12:39 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-06-28 02:05:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to fix %configure (491 bytes, patch)
2002-04-02 01:22 EST, Jens Petersen
no flags Details | Diff
this seems necessary too for libtool linux target platform detection (427 bytes, patch)
2002-04-05 02:15 EST, Jens Petersen
no flags Details | Diff
patch to use just --build and --host (545 bytes, patch)
2002-04-09 23:40 EDT, Jens Petersen
no flags Details | Diff

  None (edit)
Description Bernhard Rosenkraenzer 2002-01-17 10:24:09 EST
Description of Problem:
automake occasionally renames binaries to "ARCH-redhat-linux-binary" when they
should be called "binary".

Apparently it thinks we're crosscompiling because i386-redhat-linux !=
i386-pc-linux-gnu or the likes.

Version-Release number of selected component (if applicable):
1.5-6

How Reproducible:
100%

Steps to Reproduce:
1. Try building e.g. kontrol-panel in the kdeadmin SRPM

Actual Results:
make install produces i386-redhat-linux-kontrol-panel

Expected Results:
make install produces kontrol-panel
Comment 1 Enrico Scholz 2002-01-17 21:54:11 EST
It's a feature, not a bug ;)

Look into autoconf.info, "Transforming Names"

| - Macro: AC_ARG_PROGRAM
| ...
| Otherwise, if `AC_CANONICAL_TARGET' has been called and a `--target' value is
| given that differs from the host type (specified with `--host'), the target 
| type followed by a dash is used as a prefix.

To prevent this, just call %configure with the '--program-prefix=' option.
Perhaps, this bug should be assigned to rpm with the request to change the
%configure macro to something like 

| '...<old-stuff>... --program-prefix=%{?_program_prefix:%{_program_prefix}}'

Comment 2 Jens Petersen 2002-03-27 02:21:16 EST
moved to autoconf component
Comment 3 Jens Petersen 2002-03-27 02:22:57 EST
Could you take a look at this please, Jeff?
Comment 4 Jeff Johnson 2002-03-27 07:25:57 EST
Check the setting of the %{_gnu} macro.

Or, alternatively, just invoke ./configure
however you wish, as there's no way that rpm
can get %configure Right for all possible
mixtures of packages and autoconf.
Comment 5 Jens Petersen 2002-03-27 09:13:45 EST
I will try to investigate further at some point, but it still seems to me that
this is a rpm problem not an autoconf bug.  I would estimate that the majority
of the spec files in the distribution probably make use of %configure.

Why does %configure always pass arch-os to configure anyway, when it's not
cross-compiling?  Presumably because we build for our default IA32 target i386
on i686, right?
Comment 6 Jeff Johnson 2002-03-27 09:28:30 EST
The answer to most Why ...? is Because wrto rpm.

Look, %configure is just a string substitution,
see /var/lib/rpm/<platform>/macros
.
What do you *want* rpm to expand %configure to?

What are the issues wrto various versions of
libtool and autocrap?

I'll be happy to put whatever in %configure,
but I'd like it to be dependable and unchanging
over time. From my rpm POV, I can't even begin
to guess what libtool/autocrap packages are
gonna be installed in all possible build system(s).
Comment 7 Enrico Scholz 2002-03-27 15:12:42 EST
Adding

| --program-prefix=%{_program_prefix}' 

at the end of %configure is ok with all autoconf>=2.13 (and probably below). You
can test it with the minimal configure.in

| AC_INIT()
| AC_OUTPUT()


The current %configure uses deprecated features and produces warnings:

| ./configure i386-redhat-linux
| configure: WARNING: you should use --build, --host, --target

with recent autoconf. Why not define %configure as

| ... ./configure --build=%{_build_cpu}-%{_build_vendor}-%{_build_os} \
|                 --target=%{_target_platform} ...

It works with autoconf>=2.13, removes the warning and makes cross-compilation easy.
Comment 8 Jens Petersen 2002-04-02 00:34:36 EST
About the %{_gnu} macro: it only seems to affect %configure in
/usr/lib/rpm/macros, but on Linux this is presumably
overridden by /usr/lib/*-linux/macros.
Comment 9 Jens Petersen 2002-04-02 00:35:29 EST
/usr/lib/rpm/*-linux/macros
Comment 10 Jens Petersen 2002-04-02 01:19:50 EST
I agree that 
...
./configure --target=%{_target_platform} \
   --build=%{_build_cpu}-%{_build_vendor}-%{_build_os}
...

is the right thing to do.  I tested our pango package with both
autoconf-2.53 and autoconf-2.13.

Attaching a patch for /usr/lib/rpm/*-linux/macros.
Comment 11 Jens Petersen 2002-04-02 01:22:30 EST
Created attachment 51764 [details]
patch to fix %configure
Comment 12 Jens Petersen 2002-04-02 01:31:54 EST
A note for the record: this problem occurs when using autoconf-2.5x
./configure scripts with rpmbuild.  The problem doesn't occur with
autoconf-2.13, but as noted earlier the above fix, works with both
the new and the old autoconf.  (automake and libtool shouldn't be
affected.)
Comment 13 Jeff Johnson 2002-04-02 09:27:30 EST
Yup, Red Hat is configured differently than the default
in rpm.

This is a distro build system, not an rpm, call.
Bring up the issue there.
Comment 14 Jens Petersen 2002-04-02 22:02:54 EST
Btw, the default macros file "/usr/lib/rpm/macros" should be fixed
in the same too, I would say.

Is this bug shouldn't go under an rpm component, which component
should it go under? ;-)
Comment 15 Jens Petersen 2002-04-02 22:03:38 EST
s/Is/If/
Comment 16 Jens Petersen 2002-04-05 02:15:41 EST
Created attachment 52307 [details]
this seems necessary too for libtool linux target platform detection
Comment 17 Jens Petersen 2002-04-05 02:17:06 EST
Funny platform.in is starting to look more like macros with these
patches. :-)
Comment 18 Jeff Johnson 2002-04-05 10:45:01 EST
Nod :-). Now if I can just figger what to do
with that pesky but PC "-gnu" ...

BTW: Should I add the --build as suggested by
hjl in another recent rpm RFE? I have conflicting
inputs on the Right Thing To Do to support
cross-packaging ATM.
Comment 19 Jens Petersen 2002-04-05 13:39:21 EST
Being doing quite a lot of testing on various packages, and I'm thinking now

that just --host=%{_host} is sufficient: at least for native building.

According to the autoconf manual it should be sufficient for most cross-

compiling too, and should be used in preference to --target.
Comment 20 Jens Petersen 2002-04-08 02:49:15 EDT
A mass rebuild was run with rpm's %configure patched to expand to

   ....
   ./configure --host=%{_host} --prefix=%prefix ....

and there were no build regressions relative to a mass rebuild of
public ftp2 (except of course for failures for packages that have
bandaids like "mv /builtroot/usr/bin/i386-redhat-linux-<program> <program>"
in them :-)

Although the native build results were perfect, cross
packaging case may well need the full "build, host, target" trio
to work optimally?
Comment 21 Enrico Scholz 2002-04-08 04:29:35 EDT
I think, '--host' is enough and the right way for cross-compiling. '--target' is
needed for building cross-compilers (which is uninteresting for the most
packages) and is implicitly assigned to the '--host' value if not specified.


The only drawback of specifying '--host' only is an ugly warning:

| configure: WARNING: If you wanted to set the --build type, don't use --host.
|     If a cross compiler is detected then cross compile mode will be used.

Setting '--build=%{_build_cpu}-%{_build_vendor}-%{_build_os}' prevents this.
Comment 22 Jens Petersen 2002-04-09 23:40:23 EDT
Created attachment 53024 [details]
patch to use just --build and --host
Comment 23 Jens Petersen 2002-04-09 23:47:07 EDT
I think just using --build with --host is fine.  Probably adding
also --target with a gnu suffix won't do any harm though, and might
help with some cross-building?
Comment 24 Jens Petersen 2002-04-10 03:11:29 EDT
Hmmm, on second thoughts I realise that including --target can
actually cause problems.
Well at least in the configure file of ghc, the Glasgow Haskell
Compiler (http://haskell.org/ghc/) there is a specific test to check
that host and target are equal since ghc doesn't build to a cross
compiler I guess.  With --host=%{_host} and
--target=%{_target_cpu}-%{_vendor}-%{_target_os}%{?_gnu}
at least, it expanded to --host=i686-pc-linux-gnu
--target=i386-redhat-linux-gnu, and configure stops with an error
message saying that building a cross compiler is not supported.
So it's probably safer to leave out --target from %configure after
all.
Comment 25 Jens Petersen 2002-05-19 23:40:58 EDT
An incomplete ([A-m]*) mass rebuild of 7.3 (Valhalla) with %configure including
--host, --build and --target gave poor results.

Nearly all the build failures were due to one of the following
libtool problems:

checking if libtool supports shared libraries... no
*am-utils-6.0.7-4
*control-center-1.4.0.1-31
*expat-1.95.2-2
*freetype-2.0.9-2
*gal-0.19.1-2
^[OA*glib-1.2.10-5
*gtk+-1.2.10-15
*libghttp-1.0.9-2
*libmng-1.0.3-2
*libtool-libs13-1.3.5-2

install -c binfile builtroot/usr/bin/i386-linux-binfile
*ImageMagick-5.4.3.11-1
*dvdrtools-0.1.2-1
*firewall-config-0.97-2
*gnome-libs-1.4.1.2.90-14
*gnome-pilot-0.1.64-3
*gnome-spell-0.4.1-0.7x
*libgtop-1.0.12-8

Also gmp failed with
* gmp-4.0.1-3: configure: error: --target is not appropriate for GMP
Comment 26 Jens Petersen 2002-05-20 03:45:14 EDT
I should state that the above results are for
--host=%{_host} --build=%{_build} --target=%{_target}.

The former of the two common problems is caused by configure
with --target sending a host option of i386-linux to ltconfig,
which then doesn't recognise it as a linux system when checking the
"dynamic linker characteristics".

This can be fixed by using --target=%{_target_platform} (ie
%{_target_cpu}-%{_vendor}-%{_target_os}%{?_gnu}).

The latter problem (actually with autoconf-2.13 there is double prefixing of
"i386-linux-"!) is because configure sets transform to prefix target_alias when
it differs from host.

Therefore for the time being excluding "--target" from %configure
seems like the best idea.
Comment 27 Jens Petersen 2002-05-20 04:14:33 EDT
But as Enrico noted at the beginning: the latter problem can be
avoided with --program-prefix=%{?_program_prefix:%{_program_prefix}}.
So with this and the above change to the --target argument I
think it is fine to include --target in configure after all. :-)
Comment 28 Jens Petersen 2002-06-24 01:25:51 EDT
moved to redhat-rpm-config
Comment 29 Jens Petersen 2002-06-28 02:05:45 EDT
The above fix, replacing "%{_target_platform}" with

--host=%{_host} --build=%{_build} --target=%{_target_platform} \
--program-prefix=%{?_program_prefix:%{_program_prefix}}

in the definition of %configure, is in redhat-rpm-config-7.3.92-4.

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