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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
