On 2023/04/24 3:10, Michael Tokarev wrote:
23.04.2023 20:39, Akihiko Odaki пишет:
On 2023/04/23 22:22, Michael Tokarev wrote:
23.04.2023 14:47, Akihiko Odaki пишет:
https://salsa.debian.org/qemu-team/qemu/-/commit/e017f53a8550d0bcaaca81c6dacac8ec34295cf0
fwiw.
I seriously think you better consult GCC and other package maintainers
to have consensus on handling this kind of scenario. Otherwise you
don't get the behavior you expect from other packages.
I know no other software which does this. It's interesting you
mentioned GCC, -
I've seen it is doing that for years, wondered why. But it works just fine
when moved elsewhere - I just tried compiling a hello.c program by
/tmp/gcc, it works exactly the same way as compiled by /usr/bin/gcc.
And wast majority of software available on linux does not do these funny
tricks with relative-to-executable paths (I can't say for *all* software,
but it is definitely uncommon and I know no other examples). Only qemu
is broken in this context. The patch above fixes this breakage.
/mjt
Well for me GCC can't find cc1 as I pointed out earlier. The below is a
simple reproduction case using Podman:
podman run --rm -i debian <<EOS
apt-get update
apt-get install -y gcc
cp /usr/bin/gcc /tmp
cat > a.c <<EOC
int main()
{
}
EOC
/tmp/gcc a.c
EOS
The output ends with:
gcc: fatal error: cannot execute 'cc1': execvp: No such file or directory
compilation terminated.
This is because GCC uses relative paths to find cc1 and other files.
Regards,
Akihiko Odaki
