crosstool_ng configure bug

crosstool_ng configure bug

[Linas Vepstas]

Hi,

Just downloaded crosstool_ng, and hit a trite bug:

tar -jxvf crosstool-ng-1.13.0.tar.bz2
cd crosstool-ng-1.13.0
mkdir build
cd build
../configure --prefix=/my/path

and I get:

... etc
Checking for 'libncursesw.a'... no
Checking for 'libncurses.so'... yes

Computing version string...
Building up Makefile... /bin/sed: can't read Makefile.in: No such file
or directory
done


I habitually use a build dir distinct from the source dir to avoid
polluting the source tree with .o files; handy when disk-space is low,
when preparing patches for people, when using git, when copying files
around, and other reasons too. And disk space is always low ... so I
was slightly disappointed when configure broke by not finding
Makefile.in

Another minor remark: If/when I have to hack on a tool, such as
crosstool_ng, I use quilt, with automaticallly uses a directory called
"patches". So it was a surprise to see that such a directory already
exists in crosstool_ng. Hmmm.

--linas

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: crosstool_ng configure bug

[Yann E. MORIN]

Linas, All,

(Sorry if this is a dup, I got a non-delivery reply from the list?!?)

On Friday 11 November 2011 23:04:48 Linas Vepstas wrote:
> Just downloaded crosstool_ng, and hit a trite bug:
> 
> tar -jxvf crosstool-ng-1.13.0.tar.bz2
> cd crosstool-ng-1.13.0
> mkdir build
> cd build
> ../configure --prefix=/my/path

Out-of-tree build is currently not supported.

I'm currently reqriting the ./configure to use autoconf, and see if it is
a viable solution long-term, rather than keep our hand-crafted ./configure.
For now, I have a working configure.ac that is a drop-in replacement for
the current ./configure, but I need to do some more testing.

BTW, autostuff is completely bullshit. It definitely does not understand
cross-compilation at all. It is uterly broken. For example, crosstool-NG
requires bison at runtime, but there is no way to tell autoconf to test
for bison on the host system, not on the build system. All the tests for
executables are done for the build system. Sigh...

> Another minor remark: If/when I have to hack on a tool, such as
> crosstool_ng, I use quilt, with automaticallly uses a directory called
> "patches".

Crosstool-NG uses the Mercurial DVCS, so the usual way of tweaking
crosstool-NG is to use Mercurial commands. If you are used to using Quilt,
then using the Mercurial Queues (MQ) will be almost seemless for you, as
its idiosyncracy is very close to Quilt's (as it was insipired by it):

  hg qnew patch-name
  hg qrefresh
  hg qpush
  hg qpop

And so on... Look, in the source tree, at:
  docs/7 - Contributing to crosstool-NG.txt
  docs/C - Misc. tutorials.txt    (third chapter)

> So it was a surprise to see that such a directory already
> exists in crosstool_ng. Hmmm.

Crosstool-NG bundles patches to apply to the components (gcc, glibc, uClibc,
binutils...) used to build  toolchain, hence the patches/ sub-dir.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq