autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cross compiling when in fact we aren't


From: Guido Draheim
Subject: Re: Cross compiling when in fact we aren't
Date: Mon, 25 Aug 2003 20:21:39 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313



Balint Joo wrote:

Dear All,
    I have a question which is almost 'theological'.

Consider a case, where your --host system (on which the code will run)
and the --build system (where you compile) have the same canonical
name, but yet you still don't want AC_PROG_CC to produce a test
executable and run it. How do you stop AC_PROC_CC from
attempting to run the test executable?

"Why would you want to do this?" you may ask. "It is after all a native
build."

In my case the answer is that I am trying to compile a parallel
program, which needs a special compiler (mpcc). However in order
to run the output of mpcc, I need to be in a batch queue. Outwith
the batch queue I cannot run executables compiled with the parallel environment.

so
CC=mpcc ./configure
breaks.

If I configure with:

CC=mpcc ./configure --host=powerpc-ibm-aix5.1.0.0

the configuration enters cross compilation mode. However this
is flagged as an obsolete feature in the autoconf documentation:

In section 15.6.3:

"To ease the transition between 2.13 and its successors, a more complicated scheme is implemented. Do not rely on the following, as it will be removed in the near future.

If you specify `--host', but not `--build', when configure performs the first compiler test it will try to run an executable produced by the compiler. If the execution fails, it will enter cross-compilation mode. This is fragile. Moreover, by the time the compiler test is performed, it may be too late to modify the build-system type: other tests may have already been performed. Therefore, whenever you specify --host, be sure to specify --build too."

Hence I am not supposed to rely on this.
However when I do specify build as in:

CC=mpcc ./configure --host=powerpc-ibm-aix5.1.0.0 --build=powerpc-ibm-aix5.1.0.0

the configuration breaks (because host and build are the same):

bash-2.05a$ CC=mpcc ./configure --host=powerpc-ibm-aix5.1.0.0 --build=powerpc-ib
m-aix5.1.0.0
checking build system type... powerpc-ibm-aix5.1.0.0
checking host system type... powerpc-ibm-aix5.1.0.0
checking for a BSD-compatible install... ./config/install-sh -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking whether make sets $(MAKE)... (cached) yes
checking for powerpc-ibm-aix5.1.0.0-gcc... mpcc
checking for C compiler default output... a.out
checking whether the C compiler works... configure: error: cannot run C compiled
 programs.


While the now obsoleted method of specifying --host but no --build
works now, it is likely to go away in the future. How else can
I stop the test from trying to execute the executable but not use
an obsolete constructs?

    Your thoughts would be much appreciated,


Personally I tend to hand over slightly different platforms names.
As long as cpu and os look fine it happens that most configure
testseries run fine as many tests do not care for slight variations
in the platform name (simply because they have changed over time anyway).
You can test for that with the help of "config.sub" which will try
to return a canonic name of whatever platform name you give it as an
argument, e.g.
$ sh config.sub powerpc-ibm-aix5.1.0.0
powerpc-ibm-aix5.1.0.0
$ sh config.sub powerpc-ibm-aix5.1.0
powerpc-ibm-aix5.1.0
Now what, these two are "literally" different platforms,
ye know... :-)=)

have fun,
-- guido                                  http://AC-Archive.sf.net
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X-






reply via email to

[Prev in Thread] Current Thread [Next in Thread]