libssp_nonshared.a not present in native SDK.

libssp_nonshared.a not present in native SDK.

[Rafael Gago Castano]

Hello!

We are using krogoth for generating our images.

Yesterday, when cross-compiling with the SDK (relocatable/non-extensible), I noticed that CMake projects weren't generated because the compiler feature detection was failing. CMake enables fstack-protector for each of its platform tests and hance requires "libssp_nonshared.a" for linking. A quick search revealed that "libssp_nonshared.a" is actually missing from the SDK.

I found that "libssp_nonshared.a" comes from "gcc-utils.inc". So adding...

IMAGE_INSTALL_append += "libssp"

...fixes (or workarounds) the issue and allows CMake projects to cross-compile fine.

What I see is that I can't manually add all the libraries present in "gcc-utils.inc" as "IMAGE_INSTALL_append"s. Some of them (e.g libquadmath) fail with the error:

"Couldn't find anything to satisfy 'libquadmath'"

So I added those that doesn't cause errors by trial and error. This looks wrong.

All the statics in "gcc-utils.inc" look to me like they should be on the SDK by default, as they are gcc/libc related and in this case (libssp) essential to use some of the compiler features, so I'm wondering:

If this is a bug in krogoth?
If it isn't a bug, what is the right way to add all these gcc-runtime libs?

Best regards,
Rafa.

libssp_nonshared.a not present in native SDK.

[Rafael Gago Castano]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

Hello!

We are using krogoth for generating our images.

Yesterday, when cross-compiling with the SDK (relocatable/non-extensible), I noticed that CMake projects weren't generated because the compiler feature detection was failing. CMake enables fstack-protector for each of its platform tests and hance requires "libssp_nonshared.a" for linking. A quick search revealed that "libssp_nonshared.a" is actually missing from the SDK.

I found that "libssp_nonshared.a" comes from "gcc-utils.inc". So adding...

IMAGE_INSTALL_append += "libssp"

...fixes (or workarounds) the issue and allows CMake projects to cross-compile fine.

What I see is that I can't manually add all the libraries present in "gcc-utils.inc" as "IMAGE_INSTALL_append"s. Some of them (e.g libquadmath) fail with the error:

"Couldn't find anything to satisfy 'libquadmath'"

So I added those that doesn't cause errors by trial and error. This looks wrong.

All the statics in "gcc-utils.inc" look to me like they should be on the SDK by default, as they are gcc/libc related and in this case (libssp) essential to use some of the compiler features, so I'm wondering:

If this is a bug in krogoth?
If it isn't a bug, what is the right way to add all these gcc-runtime libs?

Best regards,
Rafa.

[-- Attachment #2: Type: text/html, Size: 2028 bytes --]

Re: libssp_nonshared.a not present in native SDK.

[Paul Eggleton]

Hi Rafael,

On Thu, 08 Dec 2016 16:05:04 Rafael Gago Castano wrote:
> Yesterday, when cross-compiling with the SDK (relocatable/non-extensible), I
> noticed that CMake projects weren't generated because the compiler feature
> detection was failing. CMake enables fstack-protector for each of its
> platform tests and hance requires "libssp_nonshared.a" for linking. A quick
> search revealed that "libssp_nonshared.a" is actually missing from the SDK.
> 
> I found that "libssp_nonshared.a" comes from "gcc-utils.inc". So adding...
> 
> IMAGE_INSTALL_append += "libssp"
> 
> ...fixes (or workarounds) the issue and allows CMake projects to
> cross-compile fine.
> 
> What I see is that I can't manually add all the libraries present in
> "gcc-utils.inc" as "IMAGE_INSTALL_append"s. Some of them (e.g libquadmath)
> fail with the error:
> 
> "Couldn't find anything to satisfy 'libquadmath'"
> 
> So I added those that doesn't cause errors by trial and error. This looks
> wrong.

AIUI libquadmath is only for Fortran so unless you're enabling and using that, 
you don't need it, and it wouldn't be present. However if you are enabling 
Fortran, there was a recent patch to correctly enable libquadmath here:

 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1013385b2f04b914538c0699a636074496911788
 
> All the statics in "gcc-utils.inc" look to me like they should be on the SDK
> by default, as they are gcc/libc related and in this case (libssp)
> essential to use some of the compiler features, so I'm wondering:
> 
> If this is a bug in krogoth?
> If it isn't a bug, what is the right way to add all these gcc-runtime libs?

So, yes and no. I looked earlier at adding a packagegroup for bringing all of 
these in together, but the more I looked at it the more I came to realise that 
in most circumstances you don't actually want all of these libraries - they 
should come in individually with the pieces that they're intended to be used 
with. Hence I added an RRECOMMENDS as it seemed appropriate:

  http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1c0fc7fcf7772ef8774f623126050972f526fe83

In particular libssp is now RRECOMMENDED by gcc for the target. This patch 
came in in the morty release so you wouldn't currently see this in krogoth 
though. Having said that your workaround shouldn't be too awkward in the mean 
time.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: libssp_nonshared.a not present in native SDK.

[Rafael Gago Castano]

[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]

Thanks for your answer. I'll keep things as they are then.


________________________________
From: Paul Eggleton <paul.eggleton@linux.intel.com>
Sent: Thursday, December 8, 2016 9:59 PM
To: Rafael Gago Castano
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] libssp_nonshared.a not present in native SDK.

Hi Rafael,

On Thu, 08 Dec 2016 16:05:04 Rafael Gago Castano wrote:
> Yesterday, when cross-compiling with the SDK (relocatable/non-extensible), I
> noticed that CMake projects weren't generated because the compiler feature
> detection was failing. CMake enables fstack-protector for each of its
> platform tests and hance requires "libssp_nonshared.a" for linking. A quick
> search revealed that "libssp_nonshared.a" is actually missing from the SDK.
>
> I found that "libssp_nonshared.a" comes from "gcc-utils.inc". So adding...
>
> IMAGE_INSTALL_append += "libssp"
>
> ...fixes (or workarounds) the issue and allows CMake projects to
> cross-compile fine.
>
> What I see is that I can't manually add all the libraries present in
> "gcc-utils.inc" as "IMAGE_INSTALL_append"s. Some of them (e.g libquadmath)
> fail with the error:
>
> "Couldn't find anything to satisfy 'libquadmath'"
>
> So I added those that doesn't cause errors by trial and error. This looks
> wrong.

AIUI libquadmath is only for Fortran so unless you're enabling and using that,
you don't need it, and it wouldn't be present. However if you are enabling
Fortran, there was a recent patch to correctly enable libquadmath here:

 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1013385b2f04b914538c0699a636074496911788

> All the statics in "gcc-utils.inc" look to me like they should be on the SDK
> by default, as they are gcc/libc related and in this case (libssp)
> essential to use some of the compiler features, so I'm wondering:
>
> If this is a bug in krogoth?
> If it isn't a bug, what is the right way to add all these gcc-runtime libs?

So, yes and no. I looked earlier at adding a packagegroup for bringing all of
these in together, but the more I looked at it the more I came to realise that
in most circumstances you don't actually want all of these libraries - they
should come in individually with the pieces that they're intended to be used
with. Hence I added an RRECOMMENDS as it seemed appropriate:

  http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1c0fc7fcf7772ef8774f623126050972f526fe83

In particular libssp is now RRECOMMENDED by gcc for the target. This patch
came in in the morty release so you wouldn't currently see this in krogoth
though. Having said that your workaround shouldn't be too awkward in the mean
time.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

[-- Attachment #2: Type: text/html, Size: 4277 bytes --]

Re: libssp_nonshared.a not present in native SDK.

[Rafael Gago Castano]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

Hello again.


I tried to fix this in my layers by adding a "recipes-devtools/gcc_5.3.bbappend" file to containing the additions that you did to poky on...


http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1c0fc7fcf7772ef8774f623126050972f526fe83


...as I think that adding these dependencies to gcc is the right thing.


Running "bitbake gcc -e" shows the next:


# $RRECOMMENDS_gcc
#   rename from RRECOMMENDS_${PN} data.py:169 [expandKeys]
#     "     libssp     libssp-dev "
RRECOMMENDS_gcc="     libssp     libssp-dev "

So the recipe is at least processed.

The problem is that "libssp_nonshared.a" is still not present on the SDK. It may happen that this is still happening in poky.

[-- Attachment #2: Type: text/html, Size: 2095 bytes --]

Re: libssp_nonshared.a not present in native SDK.

[Khem Raj]

On Fri, Dec 9, 2016 at 1:24 AM, Rafael Gago Castano <RGC@hms.se> wrote:
> Hello again.
>
>
> I tried to fix this in my layers by adding a
> "recipes-devtools/gcc_5.3.bbappend" file to containing the additions that
> you did to poky on...
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1c0fc7fcf7772ef8774f623126050972f526fe83
>
>
> ...as I think that adding these dependencies to gcc is the right thing.
>
>
> Running "bitbake gcc -e" shows the next:
>
>
> # $RRECOMMENDS_gcc
> #   rename from RRECOMMENDS_${PN} data.py:169 [expandKeys]
> #     "     libssp     libssp-dev "
> RRECOMMENDS_gcc="     libssp     libssp-dev "
>
> So the recipe is at least processed.
>
>
> The problem is that "libssp_nonshared.a" is still not present on the SDK. It
> may happen that this is still happening in poky.

how do you generate your SDK ? if you are not using -cpopulate_sdk
then it wont come in you might need to add it to TOOLCHAIN_TARGET_TASK

>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: libssp_nonshared.a not present in native SDK.

[Paul Eggleton]

On Fri, 09 Dec 2016 09:24:41 Rafael Gago Castano wrote:
> Hello again.
> 
> 
> I tried to fix this in my layers by adding a
> "recipes-devtools/gcc_5.3.bbappend" file to containing the additions that
> you did to poky on...
> 
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1c0fc7fcf7772ef877
> 4f623126050972f526fe83
> 
> 
> ...as I think that adding these dependencies to gcc is the right thing.
> 
> 
> Running "bitbake gcc -e" shows the next:
> 
> 
> # $RRECOMMENDS_gcc
> #   rename from RRECOMMENDS_${PN} data.py:169 [expandKeys]
> #     "     libssp     libssp-dev "
> RRECOMMENDS_gcc="     libssp     libssp-dev "
> 
> So the recipe is at least processed.
> 
> The problem is that "libssp_nonshared.a" is still not present on the SDK. It
> may happen that this is still happening in poky.

Hmm, I just tried building an SDK (bitbake -c populate_sdk core-image-minimal) 
with master and it definitely includes libssp_nonshared.a. Does the target 
manifest for your SDK indicate libssp-dev is included?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: libssp_nonshared.a not present in native SDK.

[Paul Eggleton]

Hi Rafael,

Looking at this a bit more closely I think the problem here is that within the 
SDK this RRECOMMENDS doesn't actually come into effect. In the SDK, gcc is in 
the host part, but you want the libssp library for the target which is in the 
target part of the SDK; RRECOMMENDS can't cross between those. On the target 
device it's simpler - both packages are in the same "namespace".

The only way I can see to fix this is to add libssp and libssp-dev to 
packagegroup-core-standalone-sdk-target so that it's explicitly brought into 
the SDK. I'll send a patch to do that.

Cheers,
Paul

On Thu, 15 Dec 2016 14:26:52 Rafael Gago Castano wrote:
> Sorry for the late reply, I had higher priority tasks meanwhile.
> 
> 
> Grepping libssp on the sdks ".target.manifest" file doesn't yield any
> result. libssp.so.0.0.0 is present on the toolchain.
> 
> When running bitbake gcc -e is see that this is the last match of
> RRECOMMENDS_gcc:
> 
> RRECOMMENDS_gcc="     libssp     libssp-dev "
> 
> ________________________________
> From: Paul Eggleton <paul.eggleton@linux.intel.com>
> Sent: Monday, December 12, 2016 5:14 AM
> To: Rafael Gago Castano
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] libssp_nonshared.a not present in native SDK.
> 
> On Fri, 09 Dec 2016 09:24:41 Rafael Gago Castano wrote:
> > Hello again.
> > 
> > 
> > I tried to fix this in my layers by adding a
> > "recipes-devtools/gcc_5.3.bbappend" file to containing the additions that
> > you did to poky on...
> > 
> > 
> > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=1c0fc7fcf7772ef8
> > 77 4f623126050972f526fe83
> > 
> > 
> > ...as I think that adding these dependencies to gcc is the right thing.
> > 
> > 
> > Running "bitbake gcc -e" shows the next:
> > 
> > 
> > # $RRECOMMENDS_gcc
> > #   rename from RRECOMMENDS_${PN} data.py:169 [expandKeys]
> > #     "     libssp     libssp-dev "
> > RRECOMMENDS_gcc="     libssp     libssp-dev "
> > 
> > So the recipe is at least processed.
> > 
> > The problem is that "libssp_nonshared.a" is still not present on the SDK.
> > It may happen that this is still happening in poky.
> 
> Hmm, I just tried building an SDK (bitbake -c populate_sdk
> core-image-minimal) with master and it definitely includes
> libssp_nonshared.a. Does the target manifest for your SDK indicate
> libssp-dev is included?
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre

-- 

Paul Eggleton
Intel Open Source Technology Centre