Re: get_relocated_path: the configured paths are not looked for?

[Akihiko Odaki]

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