[Buildroot] Question about openssh.mk

[Buildroot] Question about openssh.mk

[ANDY KENNEDY]

Thomas/Peter/all,

RE:  Header I found on git:
(Commit #c761eafb021c2beaf52b2d1a383433deac5fc2b4)
openssl: pass LDFLAGS to fix incorrect link

We already pass the LD variable to openssl in order to use gcc as the
driver for the link process, instead of directly using the ld
linker. However, we were not passing LDFLAGS so that the compiler
flags are passed, which means that with multilib toolchains, the
incorrect library variant could be used at link time, leading to
invalid binaries (partly ARMv4, partly ARMv5) or broken compilation
(when the build took place in soft-float, but the link stage takes
place against hard-float libraries).

This fixes a problem reported on IRC by amo-ej1 when compiling ssh on
PowerPC e500v2 with a CodeSourcery toolchain ("crtbegin.o uses hard
float, sshd uses soft float").

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> 

The code in question:

OPENSSH_CONF_ENV = LD="$(TARGET_CC)" LDFLAGS="$(TARGET_CFLAGS)"

Taken from package/openssh/openssh.mk

Here we are setting LDFLAGS to TARGET_CFLAGS.  Is that really what
you meant to do?  I mean, it "works", but not in every case.

Also, this appears to be overriding the TARGET_CONFIGURE_OPTS in
Makefile.in.  Is this legacy crap left over from the centralization
project years ago?

Still working on it, may have an update to this later on today.

Andy

[Buildroot] Question about openssh.mk

[Thomas Petazzoni]

Hello,

On Mon, 8 Sep 2014 18:49:09 +0000, ANDY KENNEDY wrote:

> We already pass the LD variable to openssl in order to use gcc as the
> driver for the link process, instead of directly using the ld
> linker. However, we were not passing LDFLAGS so that the compiler
> flags are passed, which means that with multilib toolchains, the
> incorrect library variant could be used at link time, leading to
> invalid binaries (partly ARMv4, partly ARMv5) or broken compilation
> (when the build took place in soft-float, but the link stage takes
> place against hard-float libraries).
> 
> This fixes a problem reported on IRC by amo-ej1 when compiling ssh on
> PowerPC e500v2 with a CodeSourcery toolchain ("crtbegin.o uses hard
> float, sshd uses soft float").
> 
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> 
> 
> The code in question:
> 
> OPENSSH_CONF_ENV = LD="$(TARGET_CC)" LDFLAGS="$(TARGET_CFLAGS)"
> 
> Taken from package/openssh/openssh.mk
> 
> Here we are setting LDFLAGS to TARGET_CFLAGS.  Is that really what
> you meant to do?  I mean, it "works", but not in every case.

Yes, that's what we want to do: openssh uses $(LD) and
$(TARGET_LDFLAGS) as if they were the compiler. In which case have you
identified this to not work?

> Also, this appears to be overriding the TARGET_CONFIGURE_OPTS in
> Makefile.in.  Is this legacy crap left over from the centralization
> project years ago?

No, it's not "legacy crap". TARGET_CONFIGURE_OPTS does LD=$(TARGET_LD)
and LDFLAGS=$(TARGET_LDFLAGS), assuming that the packages are really
using $(LD) as the linker and $(LDFLAGS) as the flags for the linker.
This is not what OpenSSH is doing, which is the reason why we override
those variables specifically for OpenSSH.

> Still working on it, may have an update to this later on today.

It would be easier if you let us know about the real problem :-)

Thanks for your report!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Question about openssh.mk

[ANDY KENNEDY]

> Yes, that's what we want to do: openssh uses $(LD) and
> $(TARGET_LDFLAGS) as if they were the compiler. In which case have you
> identified this to not work?

Okay, then it should probably be LDFAGS="$(TARGET_CFLAGS) $(TARGET_LDFLAGS)".

> No, it's not "legacy crap". TARGET_CONFIGURE_OPTS does LD=$(TARGET_LD)

Sorry!  I meant no offense. :)

> and LDFLAGS=$(TARGET_LDFLAGS), assuming that the packages are really
> using $(LD) as the linker and $(LDFLAGS) as the flags for the linker.
> This is not what OpenSSH is doing, which is the reason why we override
> those variables specifically for OpenSSH.
> 
> > Still working on it, may have an update to this later on today.
> 
> It would be easier if you let us know about the real problem :-)

For some reason, it breaks on every third or so build.  I dunno why.
Working on it.  I don't even have enough info to tell you where it is
breaking (at the moment).  I'll keep you advised.

It probably has something to do with the fact that I use
BR2_PREFER_STATIC_LIB=y
Though, I have built with this several times today and I only got the
error once out of three times.  It is complaining that it cannot build
a shared object with openssl.a as it is statically linked.

Like I said, I don't really have enough info to tell you what is broken.

Andy

> 
> Thanks for your report!
> 
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

[Buildroot] Question about openssh.mk

[Thomas Petazzoni]

Hello,

On Mon, 8 Sep 2014 20:46:05 +0000, ANDY KENNEDY wrote:
> > Yes, that's what we want to do: openssh uses $(LD) and
> > $(TARGET_LDFLAGS) as if they were the compiler. In which case have you
> > identified this to not work?
> 
> Okay, then it should probably be LDFAGS="$(TARGET_CFLAGS) $(TARGET_LDFLAGS)".

No, because $(TARGET_LDFLAGS) may contain flags that are not valid for
$(TARGET_CC).

> For some reason, it breaks on every third or so build.  I dunno why.
> Working on it.  I don't even have enough info to tell you where it is
> breaking (at the moment).  I'll keep you advised.
> 
> It probably has something to do with the fact that I use
> BR2_PREFER_STATIC_LIB=y
> Though, I have built with this several times today and I only got the
> error once out of three times.  It is complaining that it cannot build
> a shared object with openssl.a as it is statically linked.
> 
> Like I said, I don't really have enough info to tell you what is broken.

Weird. If it happens once in a while, it might look like a parallel
build issue.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Question about openssh.mk

[ANDY KENNEDY]

> > Okay, then it should probably be LDFAGS="$(TARGET_CFLAGS) $(TARGET_LDFLAGS)".
> 
> No, because $(TARGET_LDFLAGS) may contain flags that are not valid for
> $(TARGET_CC).

Hmmm.  I see TARGET_LDFLAGS only as --static on my system.  I do know that I
desire this flag to be sent down to the build, which, as it stands right now,
it doesn't (since the TARGET_LDFLAGS is not getting passed to LDFLAGS as a part
of configure).

So, what about something like this:

OPENSSH_LDFLAGS_FOR_CONF = $(TARGET_CFLAGS)

ifeq ($(BR2_PREFER_STATIC_LIB),y)
OPENSSH_LDFLAGS_FOR_CONF += --static
endif

OPENSSH_CONFIGURE_ENV += LDFLAGS="$(OPENSSH_LDFLAGS_FOR_CONF)"

???

Assuming that what I wrote down below [I modified this section after
typing the below -- you cannot read my e-mails straight through as I'm
a bit scatter-brained] does holds true for several rebuilds.

> 
> > For some reason, it breaks on every third or so build.  I dunno why.
> > Working on it.  I don't even have enough info to tell you where it is
> > breaking (at the moment).  I'll keep you advised.
> >
> > It probably has something to do with the fact that I use
> > BR2_PREFER_STATIC_LIB=y
> > Though, I have built with this several times today and I only got the
> > error once out of three times.  It is complaining that it cannot build
> > a shared object with openssl.a as it is statically linked.
> >
> > Like I said, I don't really have enough info to tell you what is broken.
> 
> Weird. If it happens once in a while, it might look like a parallel
> build issue.

Right, but the top-level is .NOTPARALLEL:, so it would stand that this would
not be possible to ever make happen.  Given that openssh has a HARD dependency
on openssl.

I dunno.  I'm still working on it.  I did just try to pass in TARGET_LDFLAGS
to LDFLAGS as part of the CONFIGURE_ENV and that seemed to have worked.

I'll have to run it again a few times before I'm comfortable with that.

I'm perplexed.

Andy