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. -- Niko
