Bug#896057: gcc-7: doesn't look for "as" in dir specified by -B

2018-05-03 Thread Bob McChesney 

On Fri, 20 Apr 2018 00:20:33 +0200 Jakub Wilk  wrote:
> * 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

2018-04-19 Thread Jakub Wilk 

* 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

2018-04-18 Thread Helmut Grohne 
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

2018-04-18 Thread Jakub Wilk 

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