Bug#896057: gcc-7: doesn't look for "as" in dir specified by -B
Hi Jakub,
On Thu, Apr 19, 2018 at 12:31:03AM +0200, Jakub Wilk wrote:
> GCC no longer looks for "as" in the directory specified by the -B option:
Yes, I asked Matthias for passing --with-as to gcc.
> This breaks afl-gcc (part of the afl package), which uses the -B option to
> talk GCC into using a hacked version of the assembler.
>
> I guess this is fallout from fixing #895251.
I am sorry for having broken afl-gcc along the way and imposing the
work of discovering why on you.
> Previously it worked like this:
>
> $ gcc --version | head -n1
> gcc (Debian 7.3.0-15) 7.3.0
>
> $ strace -f -o '| grep -w as' gcc -B/foo/bar/ -c -x c /dev/null
> 3770 stat("/foo/bar/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770 stat("/foo/bar/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770 stat("/foo/bar/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/7/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3770 stat("/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/as", 0x7ffd82351450) = -1 ENOENT (No such file or directory)
> 3773 execve("/usr/local/bin/as", ["as", "--64", "-o", "null.o", "/tmp/ccFhN057.s"], 0xbe46d0 /* 24 vars */) = -1 ENOENT (No such file or directory)
> 3773 execve("/usr/bin/as", ["as", "--64", "-o", "null.o", "/tmp/ccFhN057.s"], 0xbe46d0 /* 24 vars */ <unfinished ...>
>
> As you can see, GCC was already looking for "as" in a triplet-specific
> directory. So perhaphs gcc-7 should ship an appropriate symlink in
> /usr/lib/gcc/<triplet>/7/, instead of hardcoding path to "as" at configure
> time?
Your suggestion makes a lot of sense. The devil is in the detail though:
* Does it work the same way for ld?
* Do cross toolchains also need such a symlink?
* If yes, where to place it? (They use a different directory layout.)
* Which make variable contains the correct path?
Plan:
* I think it is reasonable to simply revert #895251 for the time being.
That should fix this bug.
* I'll look into the details and will propose an improved patch.
Helmut
Reply to: