Re: perl/experimental FTBFS on m68k, sh4

On Sun, Jul 07, 2019 at 12:07:27PM +0200, John Paul Adrian Glaubitz wrote:

> So, some more information: This issue affects qemu-user only and can be reproduced
> on armhf as well. If this is an issue with Perl in general, it means that this
> particular version of Perl will not work on any version of qemu-user independent
> of the architecture used.

Thanks for your work narrowing this down!

I can reproduce it with qemu-armhf. It's not a general issue with Perl,
just with the build machinery. See below.
 
> @Niki: Did you make any changes in particular to the Perl configuration itself? I
>        would like to find out what change exactly triggered the bug and file a
>        bug report either against qemu-user or the component in question. This
>        bug should definitely get fixed otherwise users won't be able to use
>        qemu-user anymore. It's not specific to m68k and sh4.

The change that triggered this is passing -Dmksymlinks to Configure.
This creates a symlink farm of the source in a build subdirectory.
The idea here is that the different flavours (static, shared, debug)
can now be built and tested in parallel in different directories.

The qemu-user specific thing is that $0 (= /proc/pid/cmdline) contains
an absolute path to the binary there regardless of how it was actually
invoked.

On normal systems:

  % sh -c 'echo $0'
  sh

On qemu-user:

  $ sh -c 'echo $0'
  /usr/bin/sh

It looks like the cflags.SH gets called in a different way in a
subdirectory build, from Configure:2013 or so. In a subdirectory build
it gets run with 'sh < cflags.SH' while in a "normal" build it gets run
as 'sh cflags.SH'. The former causes $0 to contain '/usr/bin/sh' under
qemu-user, and this then gets treated as an absolute path argument. So
the code changes to the same path (here /usr/bin) and tries to create
files there.

Looking at https://patchwork.kernel.org/patch/9633901/ I suspect
the $0 handling in qemu-user is not easily fixed. I suppose the the
Perl build machinery should handle this case just like it handles
other quirks in weird systems and environments.

I'll file a bug separately.