[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

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.


reply via email to

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