From @doughera88

Trying a build with the rakudo "ins" branch today on OpenSolaris/x86 with
Sun's compiler, I hit the following error​:

cd src/pmc && cc -c -I/export/home/doughera/src/parrot/rakudo-ins/parrot/install/include/1.2.0-devel -I/export/home/doughera/src/parrot/rakudo-ins/parrot/install/include/1.2.0-devel/pmc -D_REENTRANT -DPTR_IS_LONG -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHASATTRIBUTE_CONST -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHAS_GETTEXT -KPIC -g -DHAVE_COMPUTED_GOTO *.c
p6invocation.c​:
"./src/pmc/p6invocation.pmc", line 22​: cannot find include file​: "pmc_perl6multisub.h"
cc​: acomp failed for p6invocation.c
gmake​: *** [dynext/perl6_group.so] Error 1

What's happening is this​: p6invocation.c starts like this (I've omitted
irrelevant lines)​:

  #include "parrot/parrot.h"

  [ . . . ]

  #line 1 "./src/pmc/p6invocation.pmc"

  [ . . . ]

  #include "pmc_perl6multisub.h"

The './src/pmc/' part of the #line directive is what is confusing Sun's compiler.
It tries to #include "src/pmc/pmc_perl6multisub.h". However, since we are *in*
the src/pmc directory already, that fails.

Removing the './src/pmc/' part of the #line directive fixes it.

--
  Andy Dougherty doughera@​lafayette.edu

From @pmichaud

On Fri Jun 12 13​:42​:59 2009, doughera wrote​:

Trying a build with the rakudo "ins" branch today on OpenSolaris/x86
with
Sun's compiler, I hit the following error​:

[...]
"./src/pmc/p6invocation.pmc", line 22​: cannot find include file​:
"pmc_perl6multisub.h"
cc​: acomp failed for p6invocation.c
gmake​: *** [dynext/perl6_group.so] Error 1
...
#line 1 "./src/pmc/p6invocation.pmc"
...

The './src/pmc/' part of the #line directive is what is confusing
Sun's compiler.
It tries to #include "src/pmc/pmc_perl6multisub.h". However, since we
are *in*
the src/pmc directory already, that fails.

Removing the './src/pmc/' part of the #line directive fixes it.

Unfortunately, the #line directives are generated code, so I don't know
that Rakudo has any direct control over this. We may need to report it
as a Parrot toolchain bug.

Can you verify that this is still a problem in the 'ins2' branch? Thanks!

Pm

The RT System itself - Status changed from 'new' to 'open'

From @doughera88

On Fri, 24 Jul 2009, Patrick R. Michaud via RT wrote​:

On Fri Jun 12 13​:42​:59 2009, doughera wrote​:

Trying a build with the rakudo "ins" branch today on OpenSolaris/x86
with
Sun's compiler, I hit the following error​:

[...]
"./src/pmc/p6invocation.pmc", line 22​: cannot find include file​:
"pmc_perl6multisub.h"
cc​: acomp failed for p6invocation.c
gmake​: *** [dynext/perl6_group.so] Error 1
...
#line 1 "./src/pmc/p6invocation.pmc"
...

The './src/pmc/' part of the #line directive is what is confusing
Sun's compiler.
It tries to #include "src/pmc/pmc_perl6multisub.h". However, since we
are *in*
the src/pmc directory already, that fails.

Removing the './src/pmc/' part of the #line directive fixes it.

Unfortunately, the #line directives are generated code, so I don't know
that Rakudo has any direct control over this. We may need to report it
as a Parrot toolchain bug.

Can you verify that this is still a problem in the 'ins2' branch? Thanks!

Yes, it's still there. It's the 'cd' at the beginning of this line​:

  cd $(PMC_DIR) && $(CC) -c $(CINCLUDES) $(CFLAGS) *.c

If memory serves, parrot doesn't change directories like that. Instead, it sets
the output location directly, with something like

  $(CC) -c $(CINCLUDES) $(CFLAGS) -o src/pmc/p6invocation.o src/pmc/p6invocation.c

--
  Andy Dougherty doughera@​lafayette.edu

From @pmichaud

Yes, it's still there. It's the 'cd' at the beginning of this line​:

cd $\(PMC\_DIR\) && $\(CC\) \-c $\(CINCLUDES\) $\(CFLAGS\) \*\.c

If memory serves, parrot doesn't change directories like that.
Instead, it sets
the output location directly, with something like

$\(CC\) \-c $\(CINCLUDES\) $\(CFLAGS\) \-o src/pmc/p6invocation\.o

src/pmc/p6invocation.c

That's a bit of a pain, isn't it? It means we have to explicitly list
every .c file generated from the *.pmc files explicitly in the Makefile,
instead of just using "*.c" .

I guess we'll have to do it that way, but I wish there was something
better. I don't know of an easy "macro-ish" way to solve that problem
in the Makefile (which is one of the reasons I'm disappointed that
Parrot eliminated the dynpmc.pl script that could handle this for us).

Pm

From @doughera88

On Wed, 29 Jul 2009, Patrick R. Michaud via RT wrote​:

Yes, it's still there. It's the 'cd' at the beginning of this line​:

cd $\(PMC\_DIR\) && $\(CC\) \-c $\(CINCLUDES\) $\(CFLAGS\) \*\.c

If memory serves, parrot doesn't change directories like that.
Instead, it sets
the output location directly, with something like

$\(CC\) \-c $\(CINCLUDES\) $\(CFLAGS\) \-o src/pmc/p6invocation\.o

src/pmc/p6invocation.c

That's a bit of a pain, isn't it? It means we have to explicitly list
every .c file generated from the *.pmc files explicitly in the Makefile,
instead of just using "*.c" .

Yes, it's a bit of a pain. (Though reasonably automated.) I wonder if it
would be easier to convince the parrot tool to stop emitting the line
numbers. I vaguely recall that at one time, at least one of the scripts
had an option to do that.

--
  Andy Dougherty doughera@​lafayette.edu

From @pmichaud

On Wed Jul 29 11​:30​:10 2009, pmichaud wrote​:

I guess we'll have to do it that way, but I wish there was something
better. I don't know of an easy "macro-ish" way to solve that problem
in the Makefile (which is one of the reasons I'm disappointed that
Parrot eliminated the dynpmc.pl script that could handle this for us).

Actually, perhaps I'll just create a build/gen_*.pl script that builds
Makefiles in the src/pmc directory, and then recursively call "make" in
the src/pmc directory from that.

Pm

From @pmichaud

On Wed Jul 29 11​:35​:17 2009, doughera wrote​:

I wonder if it
would be easier to convince the parrot tool to stop emitting the line
numbers. I vaguely recall that at one time, at least one of the scripts
had an option to do that.

Aha! It does have an option, and I've now updated the ins2 branch to
use that option. Let me know if it works on Sun now (within the bounds
of "working", given your comments on other tickets about difficulty
getting Parrot+Rakudo to compile on Sun).

Pm

From @doughera88

Omitting the line numbers worked. This is fixed in the ins2 branch by

commit 5d8fc611d2b9b7eacd506f94771b5ba0f7ed8200
Author​: pmichaud <pmichaud@​pobox.com>
Date​: Wed Jul 29 14​:53​:02 2009 -0500

  Don't generate #line directives in pmc2c output (for Sun compilers).
  See RT #​66560 (suggestion courtesy Andy Dougherty).

From [Unknown Contact. See original ticket]

Omitting the line numbers worked. This is fixed in the ins2 branch by

commit 5d8fc611d2b9b7eacd506f94771b5ba0f7ed8200
Author​: pmichaud <pmichaud@​pobox.com>
Date​: Wed Jul 29 14​:53​:02 2009 -0500

  Don't generate #line directives in pmc2c output (for Sun compilers).
  See RT #​66560 (suggestion courtesy Andy Dougherty).

@doughera88 - Status changed from 'open' to 'resolved'