Subject: Re: bug#13472: Execution mode can hang pc when parameter refers to big file

From: Peter Rosin <[email-masked]>
Date: Tue, 29 Jan 2013 17:04:11 +0100

On 2013-01-29 16:30, Bob Friesenhahn wrote:
> On Tue, 29 Jan 2013, Peter Rosin wrote:
>> On 2013-01-17 16:29, Bob Friesenhahn wrote:
>>> Everything would be easier if libtool would arrange to build a small helper
>>> executable in the build tree which it can used instead of system tools.
>>> Libtool already builds a native executable in some cases.  This would
>>> diminish portability concerns and improve performance.  The main issue
>>> with this is that for cross-builds, a system native compiler needs to be
>>> used to build the helper executable.
>>
>> Forgive me for my ignorance, but when does libtool build something with
>> the $build compiler in the cross case? The only thing I can find that
>> looks like an alternative compiler is $LTCC, but that's just another
>> name for the normal $host C compiler. What am I missing?
> 
> As I recall, libtool builds an execution test wrapper for a Windows native
> build.  It would (should) not do that for a cross-build. However, the C
> test wrapper was written using portable interfaces so it could compile
> under POSIX (even if we don't currently do that).

The cwrapper compiles under POSIX because it is needed on Cygwin and
it compiles under Win32 because it is needed on MinGW. The cwrapper is
compiled with $LTCC, i.e. the standard $host C compiler.

> Autoconf/libtool in general does not seem to support the notion of
> supporting both a cross-compiler for the target and a native compiler for
> producing programs supporting the build, or remote/emulated testing of
> the "target".  If this hurdle was solved in a clean way, then many
> implementation opportunities would appear.

Agreed.

The conclusion is that there is no existing infrastructure for building
helper executables in libtool.

BTW, here's an alternative to "dd if="$1" bs=16K count=1"

	od -bvN 16K "$1" |
	sed 's/^[^ ]*//;/^ *$/d;s/  */\\\\/g' |
	while read l; do printf $l; done

Sadly "od -bvN" isn't portable, an alternative seems to be "hexdump -bvn".

Cheers,
Peter