GNU bug report logs -
#13472
Execution mode can hang pc when parameter refers to big file
Previous Next
Reported by: Pavel Raiskup <praiskup <at> redhat.com>
Date: Thu, 17 Jan 2013 11:11:02 UTC
Severity: normal
Done: Peter Rosin <peda <at> lysator.liu.se>
Bug is archived. No further changes may be made.
Full log
Message #23 received at 13472 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 11 years and 23 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.