openssh unix dev - Jun 2018 - vanilla build of 7.7p1 release on linux/4.17 fails with gcc8 @ "/usr/bin/ld: unrecognized option '-Wl,-z,retpolineplt'"

On 6/7/18 8:37 PM, Darren Tucker wrote:
> On 8 June 2018 at 12:21, Darren Tucker <dtucker at dtucker.net>
wrote:
>> On 8 June 2018 at 12:09, PGNet Dev <pgnet.dev at gmail.com>
wrote:
>> [...]
>>>          /usr/bin/ld -o ssh ssh.o readconf.o clientloop.o sshtty.o
sshconnect.o sshconnect2.o mux.o -L. -Lopenbsd-compat/  -Wl,-z,relro -Wl,-z,now
-Wl,-z,noexecstack -fstack-protector-strong -pie  -lssh -lopenbsd-compat  -lutil
-lz  -lcrypt -lresolv
>>>          /usr/bin/ld: unrecognized option '-Wl,-z,relro'
>>
>> That's a slightly different problem: -Wl is a gcc flag that means
>> "pass the following flag through to the linker".  Since
AC_LINK_IFLESE
>> uses $CC and not $LD, this works in configure, but apparently bare ld
>> does not understand -Wl.  The only way I can think of right now to fix
>> that is to manually invoke $LD inside the test macro.  Lemme have a
>> bit more of a think.
> 
> Looking into autoconf some more it appears that its C language support
> does not include $LD at all:
>
https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=lib/autoconf/c.m4;h=42c6ac1b1c29748ef7a9f9792301e3280b5be049;hb=HEAD#l65
> 
> ac_cpp='$CPP $CPPFLAGS'
> ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext
>&AS_MESSAGE_LOG_FD'
> ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
> conftest.$ac_ext $LIBS >&AS_MESSAGE_LOG_FD'
> 
> I'm thinking we should remove the ability to set $LD and if you want
> to override the linker you would have to use the corresponding
> compiler option such as gcc's -fuse-ld.  That would be simpler than
> trying to code around this particular problem.
The build certainly works if

	unset LD

or

	LD=gcc

so it's certainly not untenable; just a bit befuddling it you've got 
LD=ld in use.

I'm curious as to what's unique/new here -- as I've typically got
LD=ld
set (by env) for other builds, and don't see this problem.

I've also built previous versions of openssh, with earlier versions of 
GCC/LD (pre retpoline patches? not sure atm ...), without this issue, 
either.

On Fri, Jun 08, 2018 at 07:25:13AM -0700, PGNet Dev
wrote:
> The build certainly works if
> 
> 	unset LD
> 
> or
> 
> 	LD=gcc
> 
> so it's certainly not untenable; just a bit befuddling it you've
got LD=ld
> in use.
> 
> I'm curious as to what's unique/new here -- as I've typically
got LD=ld set
> (by env) for other builds, and don't see this problem.
I think the bug is really just in OpenSSH trying to use $(LD) to link
program executables rather than $(CC).  The latter is normal practice in
most build systems I see these days, and anything else is incompatible
with the common practice of putting the GCC-style -Wl,... in LDFLAGS
combined with the expectation that it should be possible to set LD=ld.

Debian sets LDFLAGS=-Wl,-z,relro by default if you use a reasonably
modern version of its package build helper tools.  While it's not
unheard of for packages to fail due to linking with ld rather than gcc
and for us to need to override this, it's rare.

That said, I'm not sure why you felt the need to explicitly set LD=ld;
generally speaking, either that's the default already, or it will break
stuff as it does here.

-- 
Colin Watson                                       [cjwatson at debian.org]

On 6/8/18 4:03 PM, Colin Watson wrote:
> On Fri, Jun 08, 2018 at 07:25:13AM -0700, PGNet Dev wrote:
>> The build certainly works if
>>
>> 	unset LD
>>
>> or
>>
>> 	LD=gcc
>>
>> so it's certainly not untenable; just a bit befuddling it
you've got LD=ld
>> in use.
>>
>> I'm curious as to what's unique/new here -- as I've
typically got LD=ld set
>> (by env) for other builds, and don't see this problem.
> 
> I think the bug is really just in OpenSSH trying to use $(LD) to link
> program executables rather than $(CC).  The latter is normal practice in
> most build systems I see these days, and anything else is incompatible
> with the common practice of putting the GCC-style -Wl,... in LDFLAGS
> combined with the expectation that it should be possible to set LD=ld.
> 
> Debian sets LDFLAGS=-Wl,-z,relro by default if you use a reasonably
> modern version of its package build helper tools.  While it's not
> unheard of for packages to fail due to linking with ld rather than gcc
> and for us to need to override this, it's rare.
> 
> That said, I'm not sure why you felt the need to explicitly set LD=ld;
> generally speaking, either that's the default already, or it will break
> stuff as it does here.
It harkens (way) back to problems with my own cross-compiling of media 
apps, and having to set LD=ld to solve them.  It solved those issues, 
and until this point with openssh, has simply never caused a different 
issue (that I've realized); and I've never proactively un-set it.

Particularly, I've never had issues adding 'GCC-style -Wl,... in 
LDFLAGS'; I use them very frequently with rpath-ing.

That all may simply be because I've fortuitously dodged the bullet 'til
now.

In any case, I've now noted the issue, and will know where to (start to) 
look should it arise again.

In the meantime, my openssh 7.7p1/no-openssl build is humming along nicely.