[perl #41168] graceful "no compiler" error message?
Will Coleda
# Please include the string: [perl #41168]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41168 >
It would be nice if configure.pl gracefully handled the error condition of
"no compiler found".
At the moment, it seems to try to stumble through several attempts at
compilation for the various config steps, generating a lot of error
messages.
Paul Cochrane via RT
> On Wed Jan 03 07:51:56 2007, coke wrote:
>
> > It would be nice if configure.pl gracefully handled the error
> condition > of "no compiler found".
>
Patch applied in r17614. Thanks!
Paul Cochrane via RT
Even though I've applied this patch and it works, I've only been able
to test it on linux x86. Could someone on windows make sure that
Configure.pl still does the right thing?
Ta heaps
Paul
Paul Cochrane via RT
Closing the ticket.
James Keenan via RT
> I ran Makefile.PL on a random windows box which hasn't had its
> compiler
> installed correctly yet. Rather than emitting an error message about
> how it couldn't find my compiler, it apparently passed the test, and
> then crashed multiple times later on:
>
>
[snip]
> Checking
> MANIFEST.....................................................done.
> Setting up Configure's default
> values.................................done.
> Setting up installation
> paths.........................................done.
> Tweaking settings for
> miniparrot...................................skipped.
> Loading platform and local hints
> files................................done.
> Determining nongenerated header
> files.................................done.
> Determining what C compiler and linker to
> use.........................done.
Is this the test which you say "apparently passed"?
> Determining whether make is
> installed..................................yes.
> Determining whether lex is
> installed...............................skipped.
> Determining whether yacc is
> installed..............................skipped.
> Determining if your C compiler is actually gcc...
> step auto::gcc died during execution: C compiler failed (see test.cco)
> at lib/Pa
> rrot/Configure/Step.pm line 504
> Parrot::Configure::Step::cc_build() called at
> config/auto/gcc.pm line 37
>
> auto::gcc::runstep('auto::gcc=HASH(0x1e1db18)',
> 'Parrot::Configure=HASH(
> 0x1a52550)') called at lib/Parrot/Configure.pm line 267
> eval {...} called at lib/Parrot/Configure.pm line 261
> Parrot::Configure::_runstep('Parrot::Configure=HASH(0x1a52550)',
> 'Parrot
> ::Configure::Task=HASH(0x1a52ab4)', 'undef', 'undef', 'undef', 11)
> called at lib
> /Parrot/Configure.pm line 192
> Parrot::Configure::runsteps('Parrot::Configure=HASH(0x1a52550)')
> called
> at Configure.pl line 324
>
> at Configure.pl line 324
[snip]
kid51
James Keenan via RT
> On 28/04/07, James Keenan via RT <parrotbug...@parrotcode.org> wrote:
> > On Mon Apr 16 16:36:56 2007, ma...@glines.org wrote:
> > > I ran Makefile.PL on a random windows box which hasn't had its
> > > compiler
> > > installed correctly yet. Rather than emitting an error message about
> > > how it couldn't find my compiler, it apparently passed the test, and
> > > then crashed multiple times later on:
> > >
> > >
> >
> > [snip]
> >
> > > Checking
> > > MANIFEST.....................................................done.
> > > Setting up Configure's default
> > > values.................................done.
> > > Setting up installation
> > > paths.........................................done.
> > > Tweaking settings for
> > > miniparrot...................................skipped.
> > > Loading platform and local hints
> > > files................................done.
> > > Determining nongenerated header
> > > files.................................done.
> > > Determining what C compiler and linker to
> > > use.........................done.
> >
> > Is this the test which you say "apparently passed"?
>
>
And (I should have asked this earlier) in what sense was the compiler not yet installed
correctly? Was it, e.g., a standard Win32 box with no compiler at all?
Thanks.
Paul Cochrane
> > I ran Makefile.PL on a random windows box which hasn't had its
> > compiler
> > installed correctly yet. Rather than emitting an error message about
> > how it couldn't find my compiler, it apparently passed the test, and
> > then crashed multiple times later on:
> >
> >
>
> [snip]
>
> > Checking
> > MANIFEST.....................................................done.
> > Setting up Configure's default
> > values.................................done.
> > Setting up installation
> > paths.........................................done.
> > Tweaking settings for
> > miniparrot...................................skipped.
> > Loading platform and local hints
> > files................................done.
> > Determining nongenerated header
> > files.................................done.
> > Determining what C compiler and linker to
> > use.........................done.
>
> Is this the test which you say "apparently passed"?
Yes.
Mark Glines
> not yet installed correctly? Was it, e.g., a standard Win32 box with
> no compiler at all?
In my case, the compiler had not yet been added to $ENV{PATH}.
Mark
Paul Cochrane
> correctly? Was it, e.g., a standard Win32 box with no compiler at all?
I'd installed visual studio (the free compiler suite one can get from
Microsoft) but hadn't gone through all the config options recommended
by Parrot (which actually points to the Perl 5 docs...) and so haven't
actually been able to get Parrot to *start* building. Anyway,
Configure most certainly can't find a compiler. So, *essentially*
yes, a standard Win32 box with no compiler.
Hope that helps,
Paul
James Keenan via RT
"Invoking the compiler on a simple source file, then checking that the
generated code exists seems such an obvious test that there must be a
fatal flaw in it. What am I missing?"
Andrew Dougherty
Almost nothing. (Perl5's Configure has the test file generate some known
output and then checks for that output.) See the lengthy discussion in
the RT ticket #41168. In brief, the idea is sound, but the test needs to
be written with a great deal of defensive programming and error-checking.
chromatic made an excellent start, but it ran into some perl-5.6 vs.
perl-5.8 limitations. I gather he's since been sidetracked by other
issues.
It'd be an excellent task for a perl programmer to take on.
--
Andy Dougherty doug...@lafayette.edu
James E Keenan
This patch grew out of Hackathon Toronto and was posted to RT, but not
initially cc-ed to the list. Please review this patch. Thank you very
much.
kid51
The attached patch to inter/progs.pm is my attempt to improve
Configure's behaviour.
It writes an embedded minimal C program to disk. (If there's already a
file called "minimal.c" it complains and dies.) It then attempts to
call the specified compiler. If the result isn't an a.out, it dies
promptly and gracefully. (It can be fooled, if something other than a
C compiler writes an a.out; that's how I tested it, but that's really
a pathological case.)
The comments should explain what's going on.
Index: progs.pm
===================================================================
--- progs.pm (revision 18351)
+++ progs.pm (working copy)
@@ -38,14 +38,31 @@
# If none work, then set to null command.
# XXX need config support for a null command.
my $null = 'echo';
- my $first_working = sub {
+ my $output = 'a.out';
+ my $min = 'minimal.c'; # File name probably not in use
+ if (-f $min) { # but die if it is
+ warn "\nPlease rename minimal.c - I create it\n" ;
+ exit 1;
+ }
+ open(MIN, ">".$min);
+ print MIN <DATA>; # Create test program (from U-Haul)
+ close MIN;
+ unlink($output) if -f $output; # in case there is rubbish lying around
+
+ my $first_working = sub {
foreach (@_) {
- `$_ -h 2>&1`;
- return $_ if not $?;
+
+ system ($_, $min) ; # Attempt simplest possible compile
+ if (-f $output) # See if it produced something
+ {
+ unlink($output, $min); # Sweep up the debris
+ return $_ ; # And return the successful program name
+ }
}
+
+ unlink($min); # Tidy up, even after failure
return $null;
- };
-
+ };
my $ask = $conf->options->get('ask');
if ($ask) {
print <<'END';
@@ -66,6 +83,10 @@
$cc = integrate( $conf->data->get('cc'), $conf->options->get('cc') );
$cc = prompt( "What C compiler do you want to use?", $cc )
if $ask;
+ if ($first_working->($cc) eq 'echo') {
+ warn "No compiler found (tried '$cc')\n";
+ exit 1;
+ }
$conf->data->set( cc => $cc );
$link = integrate( $conf->data->get('link'), $conf->options->get('link') );
@@ -139,3 +160,13 @@
# fill-column: 100
# End:
# vim: expandtab shiftwidth=4:
+__DATA__
+/* Start of minimal.c - any C compiler should create a.out from this */
+include <stdio.h>
+
+int main()
+{
+ printf ("Compiler found \n");
+}
+
+/* End of minimal.c */
Chromatic
> > "Invoking the compiler on a simple source file, then checking that the
> > generated code exists seems such an obvious test that there must be a
> > fatal flaw in it. What am I missing?"
>
> This patch grew out of Hackathon Toronto and was posted to RT, but not
> initially cc-ed to the list. Please review this patch. Thank you very
> much.
This patch is very close. Instead of handling compilation manually, I
recommend instead using cc_gen() and cc_build() from Parrot::Configure::Step.
See config/auto/sizes.pm for an example.
-- c
James Keenan via RT
> This patch is very close. Instead of handling compilation manually, I
> recommend instead using cc_gen() and cc_build() from
> Parrot::Configure::Step.
> See config/auto/sizes.pm for an example.
>
> -- c
>
Can you explain why using these functions would be the better course? In particular, how
would this approach square with the criticism Andy Dougherty made earlier in this thread on
March 21:
> + unless ( eval { cc_build(); 1 } ) {
> + warn "Compilation failed with '$cc'\n";
> + exit 1;
> + }
> This has two problems. First, it ignores the return value of cc_build().
> That's understandable at the moment since cc_build doesn't seem to have a
> documented return value. It should, of course.
kid51
James Keenan via RT
'reconfigure' branch, I did not get good results:
CC="/usr/bin/gcc-3.3"
CX="/usr/bin/g++-3.3"
/usr/local/bin/perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" \
--ld="$CX" --without-icu --without-gmp \
$@
Parrot Version 0.4.12 Configure 2.0
Copyright (C) 2001-2007, The Perl Foundation.
Hello, I'm Configure. My job is to poke and prod your system to figure out
how to build Parrot. The process is completely automated, unless you passed in
the `--ask' flag on the command line, in which case it'll prompt you for a few
pieces of info.
Since you're running this program, you obviously have Perl 5--I'll be pulling
some defaults from its configuration.
Checking MANIFEST.....................................................done.
Setting up Configure's default values.................................done.
Setting up installation paths.........................................done.
Tweaking settings for miniparrot...................................skipped.
Loading platform and local hints files................................done.
Determining nongenerated header files.................................done.
Determining what C compiler and linker to use...minimal.c:2: error: parse error before '<'
token
No compiler found (tried '/usr/bin/gcc-3.3')
Was I doing something wrong?
kid51
Andy Dougherty
> On Fri Jun 01 09:29:18 2007, chromatic <!-- x --> at wgz.org wrote:
> > This patch is very close. Instead of handling compilation manually, I
> > recommend instead using cc_gen() and cc_build() from
> > Parrot::Configure::Step.
> > See config/auto/sizes.pm for an example.
> Can you explain why using these functions would be the better course? In particular, how
> would this approach square with the criticism Andy Dougherty made earlier in this thread on
> March 21:
>
> > + unless ( eval { cc_build(); 1 } ) {
> > + warn "Compilation failed with '$cc'\n";
> > + exit 1;
> > + }
>
> > This has two problems. First, it ignores the return value of cc_build().
> > That's understandable at the moment since cc_build doesn't seem to have a
> > documented return value. It should, of course.
I agree with chromatic -- I'd simply add that the cc_build() function
should be improved to have a meaningful return value, not that it should
be avoided.
--
Andy Dougherty doug...@lafayette.edu
Mark J. Reed
is named "a.out". On Cygwin, e.g., it's a.exe. Some compilers
default to filename.exe or bare filename (when compiling filename.c).
I think you may have to assume that it accepts the -o option and give
the tested-for executable an explicit name.
--
Mark J. Reed <mark...@mail.com>