Bug 62409 - The cross build in rpm 4.0.4 is wrong
The cross build in rpm 4.0.4 is wrong
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: rpm-build (Show other bugs)
7.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-31 04:14 EST by hjl
Modified: 2007-04-18 12:41 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-10 10:24:05 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)
A patch (525 bytes, patch)
2002-03-31 04:15 EST, hjl
no flags Details | Diff
A new patch. (1.69 KB, patch)
2002-05-20 11:17 EDT, hjl
no flags Details | Diff
A patch to get rid of ldd. (2.54 KB, patch)
2002-05-20 11:19 EDT, hjl
no flags Details | Diff

  None (edit)
Description hjl 2002-03-31 04:14:08 EST
4.0.4 uses --host=%{_host} --target=%{_target_platform}
for %configure. It doesn't work with

# rpm --target=mipsel -ba ...

on Linux/x86. When I use "--target=mipsel", I want to
build a binary for mipsel, which means it runs on mipsel.
In that sense, the host is mipsel.
Comment 1 hjl 2002-03-31 04:15:06 EST
Created attachment 51544 [details]
A patch
Comment 2 Jens Petersen 2002-04-09 23:22:16 EDT
Would "--host=%{_host} --build=%{_build}" be sufficient for you?
Is --target needed in general?  (cf bug 58468.)
Comment 3 Jens Petersen 2002-04-09 23:25:23 EDT
Btw when cross-building from linux are the macros in
/usr/lib/rpm/macros?  (For native building the macros are in
/usr/lib/rpm/*-linux/macros.)
Comment 4 hjl 2002-04-10 17:40:03 EDT
For most parts,  "--host=%{_target_platform} --build=%{_build}"
should work. Except for toolchain, --target is not used at all or it
should be the same as --host.
Comment 5 Jens Petersen 2002-04-12 03:14:13 EDT
What is wrong with "--host=%{_host}"?
Comment 6 Jens Petersen 2002-04-12 03:25:07 EDT
%{_target} and %{_host} are defined to be the same in "macros",
but %{_target_platform} is slightly different: it contains %{_vendor}
instead of %{_target_vendor}.  (ie redhat instead of pc ;-)
Comment 7 hjl 2002-04-12 12:17:03 EDT
When you do

# rpm --target=mipsel ...

%{_target} and %{_host}  will be different.
Comment 8 Jens Petersen 2002-04-15 03:55:41 EDT
In fact %{_target} and %{_host} seem to be different often by
default too. At least on my box, they expand to i386-pc-linux-gnu
and i686-pc-linux-gnu respectively, when building an i386 rpm.

While this doesn't seem too bad, it can confuse
some scripts into thinking it is a cross-build: eg
the Glasgow Haskell Compiler's (http://haskell.org/ghc/)
configure script does a check to make sure that host and target are
equal.
Comment 9 Jens Petersen 2002-04-15 04:08:51 EDT
hjl, do you have any particular package in mind?

It seems to me there are two possibilities:
1) just have "--build=%{_build} --host=%{_host}" in %configure
and then use:

  %configure --target=%{_target}

when building a cross toolchain package

2) have "--build=%{_build} --host=%{_host} --target=%{_target}",
though this may break some packages.
Comment 10 Jeff Johnson 2002-04-15 09:35:08 EDT
Designing %configure to be able to pass arguments
to "the Glasgow Haskell Compiler" correctly is silly,
there's no reason in the world why that package *has*
to use %configure.

Ditto any other package that thinks it's cross compiling
because of "pc" or "i386" != "i686" madnesss.

I see little reason for adding --build explicitly.
AFAIK, only a Candian cross compile, i.e. --build
is neither of --host or --target, needs/uses that
distinction. Yes, there are myriad and deeply twisted
pathways through configure that might make use of --build
if set.
Comment 11 Jens Petersen 2002-04-15 21:33:44 EDT
GHC was just an example of a package that breaks when both --host
and --target are specified.  A mass rebuild of the distribution
needs to be done to confirm that having both --host and --target
doesn't cause any problems for packages in the distribution.

The pc vs redhat vendor "madness" is nothing package specific, it is
common to all autoconf generated config script sets.

As was already discussed in bug 58468, if --host is specified,
then --build should be too, to avoid an annoying warning message
from configure.

Oh, yes, there is another possibility, which I'm perfectly fine
with: not specifying --build, --host, and --target at all.  That
would work just fine for everything except cross-compiling. ;-)

But let's do a mass rebuild of the distro with --build --host and
--target and if there are no problems, then I think it will make
everyone happy.
Comment 12 Jeff Johnson 2002-04-16 09:22:02 EDT
I'm perfectly happy invoking configure with
no arguments almost everywhere. However, that
does not plant the all-important ...-redhat-...
brand on the file system. <shrug>
Comment 13 Jens Petersen 2002-05-20 04:19:35 EDT
As I finally reported now under bug 58468, the --target configure
option causes target_alias to get prefixed to bindir filenames
during "make install".  However this can be solved by adding
--program-prefix=%{?_program_prefix:%{_program_prefix}}
to %configure too.

Ie I believe the following form is acceptable for both native and
cross packaging.

  CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
  CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
  FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
  ./configure --host=%{_host} --build=%{_build} \\\
	--target=%{_target_platform} \\\
	--program-prefix=%{?_program_prefix:%{_program_prefix}} \\\
 	--prefix=%{_prefix} \\\
	--exec-prefix=%{_exec_prefix} \\\
	--bindir=%{_bindir} \\\
	--sbindir=%{_sbindir} \\\
	--sysconfdir=%{_sysconfdir} \\\
	--datadir=%{_datadir} \\\
	--includedir=%{_includedir} \\\
	--libdir=%{_libdir} \\\
	--libexecdir=%{_libexecdir} \\\
	--localstatedir=%{_localstatedir} \\\
	--sharedstatedir=%{_sharedstatedir} \\\
	--mandir=%{_mandir} \\\
	--infodir=%{_infodir}
Comment 14 hjl 2002-05-20 11:17:51 EDT
Created attachment 58014 [details]
A new patch.
Comment 15 hjl 2002-05-20 11:19:00 EDT
I uploaded a new patch. Also rpm uses ldd to get dependencies. It certainly
won't work with cross build. I will upload another patch.
Comment 16 hjl 2002-05-20 11:19:47 EDT
Created attachment 58015 [details]
A patch to get rid of ldd.
Comment 17 Jeff Johnson 2002-05-20 11:44:12 EDT
FWIW find-requires in rpm-4.1 uses objdump, not ldd,
and skips the (unnecessary IMHO) dependencies on the
ld-linux.so.2 interpreter.
Comment 18 hjl 2002-05-20 11:49:52 EDT
I have found the interpreter dependency useful in some cases. In
theory, the name of ld.so can change in the future. Also it may be
different from cpu to cpu.
Comment 19 Jeff Johnson 2002-05-20 11:52:29 EDT
All valid points, but that still doesn't mean
that the interpreter needs to be tracked with
package dependencies explicitly.
Comment 20 Jens Petersen 2002-07-08 04:29:33 EDT
BTW /usr/lib/rpm/redhat/macros in redhat-rpm-config now defines
%configure to use --host --build --target --program-prefix options
as above.
Comment 21 Jeff Johnson 2004-10-10 10:24:05 EDT
All issues I see here are either fixed, or problems
with other tools like automake.

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