[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another snag.. extension detection
From: |
Ralf Wildenhues |
Subject: |
Re: Another snag.. extension detection |
Date: |
Mon, 19 Nov 2007 08:38:18 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
* Benoit Sigoure wrote on Mon, Nov 19, 2007 at 12:30:12AM CET:
>
> Typically, I *guess* (untested) adding this before all your
> AC_PROG_CC/CXX/LIBTOOL and everything will trick configure:
But it does not work. Just for example set
ac_cv_prog_ac_ct_CC=blabla
to see why it won't work. I said AC_PROG_CC was special
for a reason: it's not easily overridable with cache variables.
More specifically, the first of AC_PROG_{CC,CXX,F77,FC} is,
as it computes object and executable extensions. That it does
not respect the cache variable for executable extension is due
to some backward compatibility issue.
> ac_cv_c_compiler_gnu=yes
> ac_cv_cxx_compiler_gnu=yes
> ac_cv_objext=o
> ac_cv_prog_ac_ct_CC=gcc
> ac_cv_prog_ac_ct_CXX=g++
> ac_cv_prog_cc_c89=
> ac_cv_prog_cc_g=yes
> ac_cv_prog_cxx_g=yes
[...]
* Harlan Stenn wrote on Mon, Nov 19, 2007 at 02:02:38AM CET:
>
> I thought that the cross-compile setup built and linked a test
> executable and scanned for known filenames. It does not try and run the
> generated file.
>
> This should work on a cross-compile build just the way it is.
I think you are confused. NightStrike's problem is not a cross
compiler, it's a cross compiler that cannot link yet (because (s)he is
configuring the package that will create the stuff that is needed for
linking, or so). Also, the problem above is not running the created
executable, it is running the compiler/linker in the first place.
Cheers,
Ralf