Bug#896057: gcc-7: doesn't look for "as" in dir specified by -B
On Fri, 20 Apr 2018 00:20:33 +0200 Jakub Wilkwrote: > * Helmut Grohne , 2018-04-19, 06:36: > >>perhaphs gcc-7 should ship an appropriate symlink in > >>/usr/lib/gcc//7/, instead of hardcoding path to "as" at > >>configure time? > -- > Jakub Wilk Please could assist with what you believe the best workaround is to get this working again? I've tried the latest build (7.3.0-17) and it's still not working. Adding a symlink didn't seem to help. Thanks, Bob McChesney
Bug#896057: gcc-7: doesn't look for "as" in dir specified by -B
* Helmut Grohne, 2018-04-19, 06:36: perhaphs gcc-7 should ship an appropriate symlink in /usr/lib/gcc//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? Yes. * Do cross toolchains also need such a symlink? No. (Although I suppose it wouldn't hurt either.) * If yes, where to place it? (They use a different directory layout.) * Which make variable contains the correct path? $(gcc_lib_dir) would be my guess. -- Jakub Wilk
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 */ > > 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//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
Bug#896057: gcc-7: doesn't look for "as" in dir specified by -B
Package: gcc-7 Version: 7.3.0-16 Control: block 895618 with -1 GCC no longer looks for "as" in the directory specified by the -B option: $ gcc --version | head -n1 gcc (Debian 7.3.0-16) 7.3.0 $ strace -f -o '| grep -w as' gcc -B/foo/bar/ -c -x c /dev/null 3641 access("/usr/bin/x86_64-linux-gnu-as", X_OK) = 0 3644 execve("/usr/bin/x86_64-linux-gnu-as", ["/usr/bin/x86_64-linux-gnu-as", "--64", "-o", "null.o", "/tmp/cc40S4xu.s"], 0x1ca26d0 /* 24 vars */ 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. 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 */ 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//7/, instead of hardcoding path to "as" at configure time? -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcc-7 depends on: ii binutils 2.30-15 ii cpp-7 7.3.0-16 ii gcc-7-base7.3.0-16 ii libc6 2.27-3 ii libcc1-0 8-20180414-1 ii libgcc-7-dev 7.3.0-16 ii libgcc1 1:8-20180414-1 ii libgmp10 2:6.1.2+dfsg-3 ii libisl19 0.19-1 ii libmpc3 1.1.0-1 ii libmpfr6 4.0.1-1 ii libstdc++68-20180414-1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages gcc-7 recommends: ii libc6-dev 2.27-3 -- Jakub Wilk