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

[PGNet Dev]

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.