Bug 62409

Created attachment 51544 [details]
A patch

Would "--host=%{_host} --build=%{_build}" be sufficient for you?
Is --target needed in general?  (cf bug 58468.)

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.)

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.

What is wrong with "--host=%{_host}"?

%{_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 ;-)

When you do

# rpm --target=mipsel ...

%{_target} and %{_host}  will be different.

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.

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.

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.

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.

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>

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}

Created attachment 58014 [details]
A new patch.

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.

Created attachment 58015 [details]
A patch to get rid of ldd.

FWIW find-requires in rpm-4.1 uses objdump, not ldd,
and skips the (unnecessary IMHO) dependencies on the
ld-linux.so.2 interpreter.

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.

All valid points, but that still doesn't mean
that the interpreter needs to be tracked with
package dependencies explicitly.

BTW /usr/lib/rpm/redhat/macros in redhat-rpm-config now defines
%configure to use --host --build --target --program-prefix options
as above.

All issues I see here are either fixed, or problems
with other tools like automake.