2. moritz++ pointed out that Rakudo's RT #76808 apparently refers to the same problem.

3. I have attached a patch which, AFAICT, enables me to build and install Parrot, run make clean on the build directory (my sandbox), and then have all the installed executables work. ('work' in the sense of, I can call the executable with --version, --help, etc., get expected output and not get warnings or failure messages.)

But this comes at a cost. Before I installed, when I ran make test in the build dir (as I customarily do), I got these failures in t/tools/mk_language_shell.t:

Until today I never looked at this test before, and I have never used the program it calls, tools/dev/mk_language_shell.pl, before.

So I can't tell whether this indicates a serious problem with my patch or whether it's a side effect of the way that program and its corresponding test file are written. Does it make sense to try to create a new language on top of a Parrot in the build directory as opposed to an installed Parrot?

Note: I'm working on Darwin/PPC, so this is purely a Darwin issue -- not a PPC vs Intel issue.

Until today I never looked at this test before, and I have never used the program it calls, tools/dev/mk_language_shell.pl, before.
So I can't tell whether this indicates a serious problem with my patch or whether it's a side effect of the way that program and its corresponding test file are written. Does it make sense to try to create a new language on top of a Parrot in the build directory as opposed to an installed Parrot?

On Darwin, I configured with a --prefix directory and subsequently called make install. I then followed the instructions in tools/dev/mk_language_shell.pl for creating a new language implementation:

$> perl tools/dev/mk_language_shell.pl Xyz
$> cd xyz

Using, in turn, each of the installed parrot and the build-directory parrot, I then called:

$> parrot setup.pir
$> parrot setup.pir test

In each case, the language built and tested satisfactorily. I also ran mk_language_shell.pl, changed the name of the build directory, and ran the setup.pir commands with the installed executable. Again, the results were satisfactory.

I infer from this that the test failure in t/tools/mk_language_shell.t I experienced earlier when configuring with my patch to config/init/hints/darwin.pm is a problem with the test file -- not a problem with the patch or with tools/dev/mk_language_shell.pl.

Replying to jkeenan:
I infer from this that the test failure in t/tools/mk_language_shell.t I experienced earlier when configuring with my patch to config/init/hints/darwin.pm is a problem with the test file -- not a problem with the patch or with tools/dev/mk_language_shell.pl.

I have confirmed this inference. I modified t/tools/mk_language_shell.t to look first for an installed parrot and only later for a build parrot in determining which parrot executable to use in running setup.pir and setup.pir test. I then cleared away some of the underbrush surrounding the system calls. I then used a SKIP block to test for the case that I was running on Darwin but before I had an installed Parrot. With these modifications, I was able to create workable language shells which passed all tests.