autoconf
[Top][All Lists]
Advanced

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

Re: cross compiling -- building programs to run on build system


From: Eric Siegerman
Subject: Re: cross compiling -- building programs to run on build system
Date: Tue, 8 Oct 2002 13:21:41 -0400
User-agent: Mutt/1.2.5i

On Tue, Oct 08, 2002 at 10:11:28AM +0100, Stewart Brodie wrote:
> In message <address@hidden>
>           "John W. Eaton" <address@hidden> wrote:
> > If necessary, I could put these tools in a separate directory with an
> > independent configure script, but then what is the correct way to tell
> > configure that it should ignore any setting of host and not set up for
> > cross compiling?
> 
> This is the approach that I have taken:
> 
> AC_MSG_NOTICE([configuring the tools for *native* builds])
> cd tools && \
> ./configure --build=$build_alias --host=$build_alias --target=$host_alias

Here's how I did it.  Still a kludge, but it might offer a bit
more control.  It takes advantage of the fact that
AC_CONFIG_SUBDIRS will run "configure.gnu" in preference to
"configure", if both are present.

  - In the main configure.ac, call AC_CONFIG_SUBDIRS(tools).

  - In the tools subdirectory, write a wrapper script called
    configure.gnu, which takes the arguments passed in from the
    top-level configure script and massages them however you
    need, then calls:
        $CONFIG_SHELL ./configure ...
    to do the work.

  - Write a tools/configure.ac and do the usual stuff with it.
    In my case, I don't think I had to do anything special to
    make it work with this scheme.

Specifying "$CONFIG_SHELL" in the wrapper can be important; don't
just say:
        ./configure ...
I found that the latter made the sub-configure script run verrrry
slooowwwwly on Solaris -- much more slowly than the top-level
one.

I was trying to solve a different ultimate problem, so I can't
speak to the cross-vs.-native issue itself.

(Re. slow subconfigures:
  - The slowness came from the fact that if configure decides it
    has to do $LINENO substitution, it then "."s the resulting
    configure.lineno instead of execing it, and "."ing a huge
    shell script turns out to be painfully slow in Solaris ksh.

  - Of course, ksh understands $LINENO, so configure.lineno
    substitution shouldn't have been done in the first place.
    That it was, was due to a weird interaction (whose details I
    forget) between the two shells' $LINENO decision-making, and
    some information being lost somewhere along the way.
    Explicitly running the subconfigure script in $CONFIG_SHELL
    solved it, whatever it was.)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
The acronym for "the powers that be" differs by only one letter
from that for "the pointy-haired boss".




reply via email to

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