Re: [yocto] [meta-freescale] Including Static Libraries from sysroot in an autotools based package

[zhenhua....@freescale.com]

The following article would be helpful for you.

http://stackoverflow.com/questions/2057472/howto-add-a-link-to-a-library-in-autoconf-configure-script-makefile


Best Regards,

Zhenhua

From: meta-freescale-boun...@yoctoproject.org 
[mailto:meta-freescale-boun...@yoctoproject.org] On Behalf Of Priya Agarwal
Sent: Thursday, March 19, 2015 5:07 PM
To: meta-freesc...@yoctoproject.org; yocto-bui...@yoctoproject.org; 
yocto@yoctoproject.org
Subject: Re: [meta-freescale] Including Static Libraries from sysroot in an 
autotools based package

Hi,
I need to link some libraries which are in sysroot into my source code. These 
are usdpaa libraries.
I added DEPENDS += "usdpaa" in .bb file.
Apart from that also changed the Makefile.am of my source to include the 
following:
area_LDADD = -lusdpaa_of
Then I ran aclocal, autoconf, automake --add-missing and retarred my package.
When the package is being built from recipe, do_compile fails. It shows 
"undefined reference to" error.
So this means that libraries are not getting linked by just doing the above 
changes. What else I need to change?

I think this problem is specific to autotools based projects as when I include 
the libraries during the gcc command they are easily included.

do_compile() {
${CC} check.c -o check -lusdpaa_of
}
link to area.bb
http://pastebin.com/Bef2C7nX
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-freescale] Including Static Libraries from sysroot in an autotools based package

[Priya Agarwal]

I have edited the Makefile.am as well in this way:

squid_LDADD += -lusdpaa_of

Then I just retarred squid code and build it again.

And The libraries are shown in the compile command as well, when I see the
log.do_compile generated during the build.
Check Line number 403 in this pastebin link. (ctrl+F 'usdpaa_of' could show
where all it occurs). http://pastebin.com/LpaymTQa
So how is it possible they are not actually linked.
I even checked the OVERRIDE variable in bitbake.conf which is set
correctly.
I really need to link this library. :/

On Fri, Mar 20, 2015 at 8:43 AM, Khem Raj  wrote:

>
> On Mar 19, 2015, at 2:07 AM, Priya Agarwal <
> priya_agar...@students.iitmandi.ac.in> wrote:
>
> Hi,
>
> I need to link some libraries which are in sysroot into my source code.
> These are usdpaa libraries.
>
> I added DEPENDS += "usdpaa" in .bb file.
> Apart from that also changed the Makefile.am of my source to include the
> following:
> area_LDADD = -lusdpaa_of
> Then I ran aclocal, autoconf, automake --add-missing and retarred my
> package.
>
> When the package is being built from recipe, do_compile fails. It shows
> "undefined reference to" error.
> So this means that libraries are not getting linked by just doing the
> above changes. What else I need to change?
>
>
> I think you need to specify them in Makefile.am using LDADD since it is
> using auto tools. Please take a look at Automake documentation
> http://www.gnu.org/software/automake/manual/html_node/Linking.html
> might be helpful.
>
>
> I think this problem is specific to autotools based projects as when I
> include the libraries during the gcc command they are easily included.
>
> do_compile() {
> ${CC} check.c -o check -lusdpaa_of
> }
> link to area.bb
> http://pastebin.com/Bef2C7nX
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> ___
> meta-freescale mailing list
> meta-freesc...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Including Static Libraries from sysroot in an autotools based package

[Khem Raj]

> On Mar 19, 2015, at 2:07 AM, Priya Agarwal 
>  wrote:
> 
> Hi,
> 
> I need to link some libraries which are in sysroot into my source code. These 
> are usdpaa libraries.
> 
> I added DEPENDS += "usdpaa" in .bb file.
> Apart from that also changed the Makefile.am of my source to include the 
> following:
> area_LDADD = -lusdpaa_of
> Then I ran aclocal, autoconf, automake --add-missing and retarred my package.
> 
> When the package is being built from recipe, do_compile fails. It shows 
> "undefined reference to" error.
> So this means that libraries are not getting linked by just doing the above 
> changes. What else I need to change?

I think you need to specify them in Makefile.am using LDADD since it is using 
auto tools. Please take a look at Automake documentation
http://www.gnu.org/software/automake/manual/html_node/Linking.html 

might be helpful.

> 
> I think this problem is specific to autotools based projects as when I 
> include the libraries during the gcc command they are easily included.
> 
> do_compile() {
> ${CC} check.c -o check -lusdpaa_of
> }
> link to area.bb 
> http://pastebin.com/Bef2C7nX -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] meta-toolchain not always relocatable

[akuster808]

On 03/19/2015 10:20 AM, Paul Eggleton wrote:

Hi Marco,

On Thursday 19 March 2015 17:46:44 Marco Cavallini wrote:

I am facing to a very odd behaviour installing the resulting meta-toolchain.
I launch
poky-glibc-i686-meta-toolchain-cortexa9hf-vfp-neon-toolchain-1.7.1.sh

If I install in the default directory or in /opt/poky/test it works as
expected, but if I install in /opt/poky/1.7.1-cortexa9hf there is a
problem. Using YP older that dizzy it worked with a charm.

$ ./poky-glibc-i686-meta-toolchain-cortexa9hf-vfp-neon-toolchain-1.7.1.sh
Enter target directory for SDK (default: /opt/poky/1.7.1):
/opt/poky/1.7.1-cortexa9hf
You are about to install the SDK to "/opt/poky/1.7.1-cortexa9hf".
Proceed[Y/n]? Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.

Now I can't use it calling the env setup as usual
$ .
/opt/poky/1.7.1-cortexa9hf/environment-setup-cortexa9hf-vfp-neon-poky-linux
-gnueabi

the reason is that the resulting path is incorrect

$ env | grep PATH
PATH=/opt/poky/1.7.1-cortexa9hf-cortexa9hf/sysroots/i686-pokysdk-linux/usr/b
in:/opt/poky/1.7.1-cortexa9hf-cortexa9hf/sysroots/i686-pokysdk-linux/usr/bin
/arm-poky-linux-gnueabi:.


Yes, I discovered this a few months ago and it got fixed in master:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=7032

It looks like we still haven't backported the fix to 1.7 though. Anibal, could
you please take care of that?


I can if Anibal is working on other things. I have slowly back porting 
changes anyway for the next dizzy release.


- armin


Thanks,
Paul


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

Re: [yocto] How to support arm-none-eabi toolchain for u-boot on Amlogic

[Christian Ege]

Am 19.03.2015 00:35 schrieb "Khem Raj" :
>
> On Wed, Mar 18, 2015 at 12:55 PM, Christian Ege  wrote:
> > Hello,
> >
> > it looks like that Amlogic based devices like the ODROID-C1 [1]
> > requires their u-boot compiled with an arm-none-eabi toolchain. The
> > rest kernel and rootfs is compiled with standard arm eabi toolchain. I
> > am wondering how to support this in yocto/openembedded.
>
> are there any specific reasons for doing that ?
> can it be done by passing -ffreestanding option via CFLAGS
> afterall uboot is a baremetal/standalone app.

I do not know any reason, but all tutorials require a arm-none-eabi
toolchain. Could this be required by the ROM bootloader? Frankly I not
familiar with this eabi none eabi difference. Due to the fact that there is
lack of documentation I have to try if I can build it with eabi toolchain.

Regards,
Christian
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] meta-toolchain not always relocatable

[Paul Eggleton]

Hi Marco,

On Thursday 19 March 2015 17:46:44 Marco Cavallini wrote:
> I am facing to a very odd behaviour installing the resulting meta-toolchain.
> I launch
> poky-glibc-i686-meta-toolchain-cortexa9hf-vfp-neon-toolchain-1.7.1.sh
> 
> If I install in the default directory or in /opt/poky/test it works as
> expected, but if I install in /opt/poky/1.7.1-cortexa9hf there is a
> problem. Using YP older that dizzy it worked with a charm.
> 
> $ ./poky-glibc-i686-meta-toolchain-cortexa9hf-vfp-neon-toolchain-1.7.1.sh
> Enter target directory for SDK (default: /opt/poky/1.7.1):
> /opt/poky/1.7.1-cortexa9hf
> You are about to install the SDK to "/opt/poky/1.7.1-cortexa9hf".
> Proceed[Y/n]? Extracting SDK...done
> Setting it up...done
> SDK has been successfully set up and is ready to be used.
> 
> Now I can't use it calling the env setup as usual
> $ .
> /opt/poky/1.7.1-cortexa9hf/environment-setup-cortexa9hf-vfp-neon-poky-linux
> -gnueabi
> 
> the reason is that the resulting path is incorrect
> 
> $ env | grep PATH
> PATH=/opt/poky/1.7.1-cortexa9hf-cortexa9hf/sysroots/i686-pokysdk-linux/usr/b
> in:/opt/poky/1.7.1-cortexa9hf-cortexa9hf/sysroots/i686-pokysdk-linux/usr/bin
> /arm-poky-linux-gnueabi:.

Yes, I discovered this a few months ago and it got fixed in master:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=7032

It looks like we still haven't backported the fix to 1.7 though. Anibal, could 
you please take care of that?

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] meta-toolchain not always relocatable

[Marco Cavallini]

Hi,
I am facing to a very odd behaviour installing the resulting meta-toolchain.
I launch poky-glibc-i686-meta-toolchain-cortexa9hf-vfp-neon-toolchain-1.7.1.sh

If I install in the default directory or in /opt/poky/test it works as
expected, but if I install in /opt/poky/1.7.1-cortexa9hf there is a
problem. Using YP older that dizzy it worked with a charm.

$ ./poky-glibc-i686-meta-toolchain-cortexa9hf-vfp-neon-toolchain-1.7.1.sh
Enter target directory for SDK (default: /opt/poky/1.7.1):
/opt/poky/1.7.1-cortexa9hf
You are about to install the SDK to "/opt/poky/1.7.1-cortexa9hf". Proceed[Y/n]?
Extracting SDK...done
Setting it up...done
SDK has been successfully set up and is ready to be used.

Now I can't use it calling the env setup as usual
$ . 
/opt/poky/1.7.1-cortexa9hf/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi

the reason is that the resulting path is incorrect

$ env | grep PATH
PATH=/opt/poky/1.7.1-cortexa9hf-cortexa9hf/sysroots/i686-pokysdk-linux/usr/bin:/opt/poky/1.7.1-cortexa9hf-cortexa9hf/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi:.

--
Marco
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] FW: [openssl-announce] OpenSSL Security Advisory

[Sona Sarmadi]

FYI,

-Original Message-
From: openssl-announce [mailto:openssl-announce-boun...@openssl.org] On Behalf 
Of OpenSSL
Sent: den 19 mars 2015 15:12
To: OpenSSL Developer ML; OpenSSL User Support ML; OpenSSL Announce ML
Subject: [openssl-announce] OpenSSL Security Advisory

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [19 Mar 2015]
===

OpenSSL 1.0.2 ClientHello sigalgs DoS (CVE-2015-0291) 
=

Severity: High

If a client connects to an OpenSSL 1.0.2 server and renegotiates with an 
invalid signature algorithms extension a NULL pointer dereference will occur.
This can be exploited in a DoS attack against the server.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 users should upgrade to 1.0.2a.

This issue was was reported to OpenSSL on 26th February 2015 by David Ramos of 
Stanford University. The fix was developed by Stephen Henson and Matt Caswell 
of the OpenSSL development team.

Reclassified: RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) 


Severity: High

This security issue was previously announced by the OpenSSL project and 
classified as "low" severity. This severity rating has now been changed to 
"high".

This was classified low because it was originally thought that server RSA 
export ciphersuite support was rare: a client was only vulnerable to a MITM 
attack against a server which supports an RSA export ciphersuite. Recent 
studies have shown that RSA export ciphersuites support is far more common.

This issue affects OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.1 users should upgrade to 1.0.1k.
OpenSSL 1.0.0 users should upgrade to 1.0.0p.
OpenSSL 0.9.8 users should upgrade to 0.9.8zd.

This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan 
Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen 
Henson of the OpenSSL core team. It was previously announced in the OpenSSL 
security advisory on 8th January 2015.

Multiblock corrupted pointer (CVE-2015-0290) 


Severity: Moderate

OpenSSL 1.0.2 introduced the "multiblock" performance improvement. This feature 
only applies on 64 bit x86 architecture platforms that support AES NI 
instructions. A defect in the implementation of "multiblock" can cause 
OpenSSL's internal write buffer to become incorrectly set to NULL when using 
non-blocking IO. Typically, when the user application is using a socket BIO for 
writing, this will only result in a failed connection. However if some other 
BIO is used then it is likely that a segmentation fault will be triggered, thus 
enabling a potential DoS attack.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 users should upgrade to 1.0.2a.

This issue was reported to OpenSSL on 13th February 2015 by Daniel Danner and 
Rainer Mueller. The fix was developed by Matt Caswell of the OpenSSL 
development team.

Segmentation fault in DTLSv1_listen (CVE-2015-0207) 
===

Severity: Moderate

The DTLSv1_listen function is intended to be stateless and processes the 
initial ClientHello from many peers. It is common for user code to loop over 
the call to DTLSv1_listen until a valid ClientHello is received with an 
associated cookie. A defect in the implementation of DTLSv1_listen means that 
state is preserved in the SSL object from one invocation to the next that can 
lead to a segmentation fault. Errors processing the initial ClientHello can 
trigger this scenario. An example of such an error could be that a DTLS1.0 only 
client is attempting to connect to a DTLS1.2 only server.

This issue affects OpenSSL version: 1.0.2

OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2a.

This issue was reported to OpenSSL on 27th January 2015 by Per Allansson. The 
fix was developed by Matt Caswell of the OpenSSL development team.

Segmentation fault in ASN1_TYPE_cmp (CVE-2015-0286) 
===

Severity: Moderate

The function ASN1_TYPE_cmp will crash with an invalid read if an attempt is 
made to compare ASN.1 boolean types. Since ASN1_TYPE_cmp is used to check 
certificate signature algorithm consistency this can be used to crash any 
certificate verification operation and exploited in a DoS attack. Any 
application which performs certificate verification is vulnerable including 
OpenSSL clients and servers which enable client authentication.

This issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

OpenSSL 1.0.2 users should upgrade to 1.0.2a OpenSSL 1.0.1 users should upgrade 
to 1.0.1m.
OpenSSL 1.0.0 users should upgrade to 1.0.0r.
OpenSSL 0.9.8 users should upgrade to 0.9.8zf.

This issue was discovered and fixed by Stephen Henson of the OpenSSL 
development team.

Segmentation fault for invalid PSS pa

[yocto] [meta-freescale][meta-ivi][meta-fsl_ivi] build instruction update

[eien sakebe]

Hello everybody,
im trying to build foton-image following instructions from
https://github.com/Freescale/meta-fsl-ivi. My aim is to test IVI Layer
manager with MXGAL graphics backend (really not interested to test
X11/Wayland features).
Im quite new to Yocto and getting more and more confused how to build this
image.

My instructions:

mkdir fsl-community-bsp

cd fsl-community-bsp
repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b
master
(I dont really know what branch to consider)

repo sync
export MACHINE=imx6dlsabresd

source ./sources/poky/oe-init-build-env

cd /home/ui/fsl-community-bsp/sources
git clone https://git.yoctoproject.org/git/meta-ivi
git branch 4.0
(instead of git://git.openembedded.org/meta-ivi wich does not exist, it
also requires branch 4.0 and a given commit)

git clone https://github.com/Freescale/meta-fsl-ivi.git

cd /home/ui/fsl-community-bsp/build
vim conf/bblayers.conf

ive added the following to BBLAYERS :


/home/ui/fsl-community-bsp/sources/meta-fsl-arm \
/home/ui/fsl-community-bsp/sources/meta-ivi/meta-ivi \
/home/ui/fsl-community-bsp/sources/meta-fsl-ivi \

Added the following to my local.conf
MACHINE ?= "imx6dlsabresd"
INCOMPATIBLE_LICENSE = "GPLv3"
DISTRO ?= "fsl-ivi-vfb"
UBOOT_SUFFIX = "bin"
UBOOT_PADDING = "2"
PREFERRED_PROVIDER_u-boot = "u-boot-imx"
ACCEPT_FSL_EULA = "1"


bitbake foton-image


ERROR: No recipes available for:

/home/ui/fsl-community-bsp/sources/meta-ivi/meta-ivi/recipes-connectivity/neard/neard_0.14.bbappend

/home/ui/fsl-community-bsp/sources/meta-ivi/meta-ivi/recipes-graphics/wayland/weston_1.5.0.bbappend

/home/ui/fsl-community-bsp/sources/meta-fsl-ivi/recipes-graphics/layer-management/layer-management_1.0.1.bbappend

/home/ui/fsl-community-bsp/sources/meta-ivi/meta-ivi/recipes-multimedia/pulseaudio/pulseaudio_5.0.bbappend

/home/ui/fsl-community-bsp/sources/meta-ivi/meta-ivi/recipes-connectivity/libpcap/libpcap_1.6.1.bbappend

/home/ui/fsl-community-bsp/sources/meta-ivi/meta-ivi/recipes-core-ivi/busybox/busybox_1.22.1.bbappend

1st error
=
removing these files get me to the next error

ERROR: Nothing PROVIDES 'foton-image'. Close matches:
  python-image
  python3-image

There are few topics arround, but theres no evident solution.
Please help :(
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mono][PATCH] mono: Support to build mono without X support.

[Alex J Lennon]

On 18/03/2015 15:23, Enric Balletbo i Serra wrote:
> Use PACKAGECONFIG to build a version of mono with or without X support in
> function of x11 DISTRO_FEATURES.
>
> Tested on qemux86 (mono using X) and imx6 board (mono without X)
>
> Signed-off-by: Enric Balletbo i Serra 

Merged. Thanks Enric.

Alex

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

Re: [yocto] Including Static Libraries from sysroot in an autotools based package

[Priya Agarwal]

Hi,

I need to link some libraries which are in sysroot into my source code.
These are usdpaa libraries.

I added DEPENDS += "usdpaa" in .bb file.
Apart from that also changed the Makefile.am of my source to include the
following:
area_LDADD = -lusdpaa_of
Then I ran aclocal, autoconf, automake --add-missing and retarred my
package.

When the package is being built from recipe, do_compile fails. It shows
"undefined reference to" error.
So this means that libraries are not getting linked by just doing the above
changes. What else I need to change?

I think this problem is specific to autotools based projects as when I
include the libraries during the gcc command they are easily included.

do_compile() {
${CC} check.c -o check -lusdpaa_of
}
link to area.bb
http://pastebin.com/Bef2C7nX
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Including Static Libraries from sysroot in an autotools based package

[Priya Agarwal]

Hi,

I need to link some libraries which are in sysroot into my source code.
These are usdpaa libraries.

I added DEPENDS += "usdpaa" in .bb file.
Apart from that also changed the Makefile.am of my source to include the
following:
area_LDADD = -lusdpaa_of
Then I ran aclocal, autoconf, automake --add-missing and retarred my
package.

When the package is being built from recipe, do_compile fails.
So this means that libraries are not getting linked by just doing the above
changes. What else I need to change?

I think this problem is specific to autotools based projects as when I
include the libraries during the gcc command they are easily included.

do_compile() {
${CC} check.c -o check -lusdpaa_of
}
link to area.bb
http://pastebin.com/Bef2C7nX
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto