[Top][All Lists]

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

Re: Building prog first

From: Russell Shaw
Subject: Re: Building prog first
Date: Tue, 23 Mar 2010 21:33:18 +1100
User-agent: Mozilla-Thunderbird (X11/20091109)

Steffen Dettmer wrote:
On Mon, Mar 22, 2010 at 4:44 PM, Reuben Thomas <address@hidden> wrote:
Not true. automake does not have explicit support for building
programs with the host compiler when cross-compiling, but I
have done this successfully in the past when I needed precisely
to build a program on the host when cross compiling, using
binutils's BFD_CC_FOR_BUILD macro. It's a pity some version of
this macro isn't in autoconf, or even autoconf-archive; I shall
do the latter.

I guess this is a hack and a burden to maintain.

When cross-compiling, why compiling a local tool?
Isn't the correct way to natively compile the local tool,
then use it to cross-compile the package?

This illustrates a weirdness of autotools: poor support for
installing interpreted languages, and also conversely for
build-time compiled programs.

Yes, also for coffee-cooking there is poor support only. :-)

I don't think build-time compiled C programs shall be suppored
while cross compiling. I think it already is complex enough.
Otherwise you had to do all checks twice and end up in many
variables with confusing names, and those who are not
cross-compiling probably accidently will mix them.

I though of perl, but (A), i don't like slow tools,

(I think Perl is fast)

(C), i find making build-programs
in C much more concise than scripting and i can debug it in ddd/gdb.

You can debug Perl in DDD.

This is interesting, as it doesn't match mine or
commonly-reported experience (translating my build-time
programs from C to Perl made them shorter, easier to read and
fix, and no slower to run, although I wasn't doing more than
grepping 15k lines of C and writing some of it back out again).

$ time perl -e \
  'for($n=0;$n<450000;$n++) { printf "%08d %60s EOL\n", $n, ""; }' > x

real    0m0.713s

$ cat x.c
#include <stdio.h>
int main(void)
   int n;
   for(n=0; n<450000;n++) {
      printf("%08d %60s EOL\n", n, "");
   return 0;

$ time make x
gcc -Wall -Wmissing-prototypes -fstrict-aliasing -D_GNU_SOURCE -ansi
-ggdb      -ggdb      x.c   -o x
real    0m0.076s

$ time ./x>x2
real    0m0.301s

so 713ms vs. 377 ms.

Interesting that up to around 100k Perl is even faster:

$ time perl \
  -e 'for($n=0;$n<100000;$n++) { printf "%08d %60s EOL\n", $n, ""; }' > x
real    0m0.167s

$ time make x
real    0m0.081s
$ time ./x>x2
real    0m0.079s

(of course those figures are far away from being exact; they just prove
how fast perl is: same magnitude as C)

I'd think that printf() in perl would be mapped to the same printf()
in C lib stdio, and because this is the dominant code, the times are

What i had in mind is the efficiency of regular expression execution
in perl, compared to hard-coded parsing in C.

I will try perl in ddd/gdb some time.

reply via email to

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