On Mon, 6 Aug 2007 15:20:39 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> On Monday 06 August 2007 15:10:30 Andy Lester wrote:
>
> > On Mon, Aug 06, 2007 at 02:40:06PM -0700, chromatic
> > ([EMAIL PROTECTED])
> wrote:
>
> > > I find these two lines confusing:
> > >
> > > my %eval = eval cc_run();
> > > return if !%eval;
>
> > Have you looked at the string it returns? It looks like this:
> >
> > (
> > GCC_VERSION => 3,
> > GCC_MINOR => 4
> > );
> >
> > Or something similar. It perplexed me as well.
>
> I thought so too, but the probe uses config/auto/attributes/test_c.in:
>
> /* as long as the file compiles, everything is okay */
> int
> main(int argc, char *argv[])
> {
> return EXIT_SUCCESS;
> }
>
> That's not exactly the same as a stringified hash. I think we can
> just remove the cc_run() bits and be fine (at least, it worked for
> me).
I just chased this down, and then found this mailing list thread. So
please excuse my arriving late to the party :)
Currently (r20530), I'm not getting *any* attributes defined on my x86
linux box, because of this. This despite the fact that gcc 3.4.6
supports lots (if not all) of the attributes, and Configure.pl
--verbose reports "exit code 0" (meaning, success).
cc_run() returns "", eval cc_run() returns (), which fails the !%eval
check on the line below. Which means lots of nice things,
PARROT_DOES_NOT_RETURN for instance, are currently noops in my build.
Removing the cc_run bit sounds like the right fix to me, too. The whole
stringified hash thing seems to be used elsewhere to detect compiler
version, but we don't need anything compiler-specific in this
particular check. The important part is that it built, which was
already checked.
Mark
