[yocto] [meta-cgl][PATCH] openais: upgrade from 1.1.3 to 1.1.4

[Lei Maohui]

Signed-off-by: Lei Maohui 
---
 meta-cgl-common/recipes-cgl/openais/openais_1.1.3.bb | 19 ---
 meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb | 18 ++
 2 files changed, 18 insertions(+), 19 deletions(-)
 delete mode 100644 meta-cgl-common/recipes-cgl/openais/openais_1.1.3.bb
 create mode 100644 meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb

diff --git a/meta-cgl-common/recipes-cgl/openais/openais_1.1.3.bb 
b/meta-cgl-common/recipes-cgl/openais/openais_1.1.3.bb
deleted file mode 100644
index f4563c9..000
--- a/meta-cgl-common/recipes-cgl/openais/openais_1.1.3.bb
+++ /dev/null
@@ -1,19 +0,0 @@
-DESCRIPTION = "Implementation of the Service Availability Forum Application 
Interface Specification (AIS)"
-LICENSE = "BSD"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=4cb00dd52a063edbece6ae248a2ba663"
-DEPENDS = "cluster-glue corosync"
-
-#  ftp://f...@openais.org/downloads/openais-${PV}/openais-${PV}.tar.gz
-
-SRC_URI = " \
-   ftp://f...@tux.rainside.sk/gentoo/distfiles/openais-${PV}.tar.gz \
-   file://fix-lcrso-linkage.patch \
-file://build-cleanup-configure-ac.patch \
-file://openais-fix-bash.patch \
-   "
-SRC_URI[md5sum] = "13d8d590f806fb396d750b086c6c0b78"
-SRC_URI[sha256sum] = 
"eeef58dd2df3eb16ba68b3fbdc6f0d4dfb537443f1c091ec6f0431594f2f00b6"
-
-inherit autotools pkgconfig
-
-FILES_${PN}-dbg += "${libexecdir}/lcrso/.debug"
diff --git a/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb 
b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
new file mode 100644
index 000..69934a5
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/openais/openais_1.1.4.bb
@@ -0,0 +1,18 @@
+DESCRIPTION = "Implementation of the Service Availability Forum Application 
Interface Specification (AIS)"
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=4cb00dd52a063edbece6ae248a2ba663"
+DEPENDS = "cluster-glue corosync"
+
+
+SRC_URI = " \
+ftp://f...@tux.rainside.sk/gentoo/distfiles/openais-${PV}.tar.gz \
+file://fix-lcrso-linkage.patch \
+file://build-cleanup-configure-ac.patch \
+file://openais-fix-bash.patch \
+   "
+SRC_URI[md5sum] = "e500ad3c49fdc45d8653f864e80ed82c"
+SRC_URI[sha256sum] = 
"974b4959f3c401c16156dab31e65a6d45bbf84dd85a88c2a362712e738c06934"
+
+inherit autotools pkgconfig
+
+FILES_${PN}-dbg += "${libexecdir}/lcrso/.debug"
-- 
1.8.4.2

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

[yocto] Recipe for ipset 6.x

[Albert K]

Hi,

Does anyone know where can I get the ipset recipe for yocto 1.7.1?  Thank
you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] ds1307-rtc-overlay.dtb has been removed from the kernel tree

[Herve Jourdain]

Hi,

 

I'm not sure about the formalism of submitting patches to this list, so I
hope you will forgive any misstep.

 

Recently, the RaspberryPi kernel has removed some "deprecated" DTB overlays
from the kernel tree, causing the meta-raspberrypi layer to fail at compile
time.

The failure message is:

No rule to make target `arch/arm/boot/dts/ds1307-rtc-overlay.dtb'.  Stop.

 

The DTB overlays that have been deleted are:

ds1307-rtc-overlay

pf2127-rtc-overlay

pcf8523-rtc-overlay

pfc8563-rtc-overlay

 

They've been replaced by: i2c-rtc-overlay

 

Therefore, the file conf/machine/include/rpi-base.inc must be modified to
accommodate those changes.

 

The proposed patch is:

--- meta-raspberrypi/conf/machine/include/rpi-base.inc 2015-06-10
12:59:09.069237631 +0800

+++ meta-raspberrypi.new/conf/machine/include/rpi-base.inc 2015-06-17
01:11:58.125869271 +0800

@@ -23,15 +23,14 @@

 bcm2708-rpi-b-plus.dtb \

 bcm2709-rpi-2-b.dtb \

 \

-ds1307-rtc-overlay.dtb \

 hifiberry-amp-overlay.dtb \

 hifiberry-dac-overlay.dtb \

 hifiberry-dacplus-overlay.dtb \

 hifiberry-digi-overlay.dtb \

+i2c-rtc-overlay.dtb \

 iqaudio-dac-overlay.dtb \

 iqaudio-dacplus-overlay.dtb \

 lirc-rpi-overlay.dtb \

-pcf8523-rtc-overlay.dtb \

 pps-gpio-overlay.dtb \

 w1-gpio-overlay.dtb \

 w1-gpio-pullup-overlay.dtb \

Signed-off-by: herve.jourd...@neuf.fr  

 

Regards



meta-raspberrypi-rpi-base.patch
Description: Binary data
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCHv3 09/11][auh] upgradehelper.py: Change policy for send emails and fix error handling.

[Aníbal Limón]

Add MaintainerError class for identify errors that can be hanlded by
Maintainers, only send emails when error is instance of MaintainerError.

Get rid of UpgradeNotNeededError when run steps now is handled by
new upstream version detection only load recipes that need update.

[YOCTO #7489]

Signed-off-by: Aníbal Limón 
---
 errors.py| 16 
 upgradehelper.py | 16 +++-
 2 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/errors.py b/errors.py
index c650165..7194944 100644
--- a/errors.py
+++ b/errors.py
@@ -31,6 +31,11 @@ class Error(Exception):
 def __str__(self):
 return "Failed(other errors)"
 
+class MaintainerError(Error):
+""" Class for group error that can be sent to Maintainer's """
+def __init__(self, message=None, stdout=None, stderr=None):
+super(MaintainerError, self).__init__(message, stdout, stderr)
+
 class FetchError(Error):
 def __init__(self):
 super(FetchError, self).__init__("do_fetch failed")
@@ -38,25 +43,28 @@ class FetchError(Error):
 def __str__(self):
 return "Failed(do_fetch)"
 
-class PatchError(Error):
+class PatchError(MaintainerError):
 def __init__(self):
 super(PatchError, self).__init__("do_patch failed")
 
 def __str__(self):
 return "Failed(do_patch)"
 
-class ConfigureError(Error):
+class ConfigureError(MaintainerError):
 def __init__(self):
 super(ConfigureError, self).__init__("do_configure failed")
 
-class CompilationError(Error):
+def __str__(self):
+return "Failed(do_configure)"
+
+class CompilationError(MaintainerError):
 def __init__(self):
 super(CompilationError, self).__init__("do_compile failed")
 
 def __str__(self):
 return "Failed(do_compile)"
 
-class LicenseError(Error):
+class LicenseError(MaintainerError):
 def __init__(self):
 super(LicenseError, self).__init__("license checksum does not match")
 
diff --git a/upgradehelper.py b/upgradehelper.py
index b1f075d..7756b36 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -346,8 +346,6 @@ class Updater(object):
 self.git.clean_untracked()
 return
 
-status = type(err).__name__
-
 # drop last upgrade from git. It's safer this way if the upgrade has
 # problems and other recipes depend on it. Give the other recipes a
 # chance...
@@ -381,8 +379,11 @@ class Updater(object):
 "Attached are the patch, license diff (if change) and bitbake 
log.\n\n" \
 "Regards,\nThe Upgrade Helper"
 
-# don't bother maintainer with mail if the recipe is already up to 
date
-if status == "UpgradeNotNeededError":
+# only send email to Maintainer when is an error that can handle
+if err and not isinstance(err, MaintainerError):
+D( "%s: Don't send email to maintainer because the error was " 
\
+   "%s and the information isn't useful, please review it." \
+% (self.pn, type(err).__name__))
 return
 
 if self.maintainer in maintainer_override:
@@ -478,6 +479,7 @@ class Updater(object):
 
 attempted_pkgs = 0
 for self.pn, self.new_ver, self.maintainer in pkgs_to_upgrade:
+error = None
 self.recipe = None
 attempted_pkgs += 1
 I(" ATTEMPT PACKAGE %d/%d" % (attempted_pkgs, total_pkgs))
@@ -489,10 +491,6 @@ class Updater(object):
 step()
 
 I(" %s: Upgrade SUCCESSFUL! Please test!" % self.pn)
-error = None
-except UpgradeNotNeededError as e:
-I(" %s: %s" % (self.pn, e.message))
-error = e
 except Error as e:
 E(" %s: %s" % (self.pn, e.message))
 E(" %s: Upgrade FAILED! Logs and/or file diffs are available 
in %s" % (self.pn, self.workdir))
@@ -667,7 +665,7 @@ class UniverseUpdater(Updater):
 
 # overriding the base method
 def pkg_upgrade_handler(self, err):
-super(UniverseUpdater, self).pkg_upgrade_handler(self)
+super(UniverseUpdater, self).pkg_upgrade_handler(err)
 self.update_history(self.pn, self.new_ver, self.maintainer,
 self._get_status_msg(err))
 
-- 
1.8.4.5

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

[yocto] Help using bitbake to compile a custom package.

[Rafael E. Herrera]

Hello,

I'm trying to port an in-house piece of software in my Yocto tree. I managed to 
create a rudimentary recipe file that grabs the tar ball from the local disk 
and attempts to compile using:

host $ bitbake -f -c compile example

>From the output I infer that the tar ball got unpacked and a make executed in 
>the source code tree.

However, my build fails because a number of libraries are missing. 

For example, the libuuid library seems not to be found. How do I verify that 
this library is available in my Yocto tree? 

If not, how to determine what recipe do I need to build to get it installed?

How do I make sure that the header files for the library are also installed?

I'm assuming that once a library is built using the right bitbake recipe, it is 
available to the code that calls it. If not, how is that configured?

Thank you,

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

Re: [yocto] [PATCHv2 09/11][auh] upgradehelper.py: Change policy for send emails and fix error passing

[Aníbal Limón]

Hi Paul,

On 16/06/15 08:01, Paul Eggleton wrote:

Hi Aníbal,

On Friday 12 June 2015 20:10:45 Aníbal Limón wrote:

Now send emails almost in all cases this give the maintainer
patches and diff to continue work also if the build isn't
succesful.

[YOCTO #7489]

Signed-off-by: Aníbal Limón 
---
  upgradehelper.py | 19 ++-
  1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index b1f075d..d065fba 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -346,8 +346,6 @@ class Updater(object):
  self.git.clean_untracked()
  return

-status = type(err).__name__
-
  # drop last upgrade from git. It's safer this way if the upgrade
has # problems and other recipes depend on it. Give the other recipes a #
chance...
@@ -381,8 +379,14 @@ class Updater(object):
  "Attached are the patch, license diff (if change) and
bitbake log.\n\n" \ "Regards,\nThe Upgrade Helper"

-# don't bother maintainer with mail if the recipe is already up
to date -if status == "UpgradeNotNeededError":
+# if error only send email when useful infomration for
maintainers exist +if err and not (isinstance(err, PatchError)
or \
+   isinstance(err, ConfigureError) or \
+   isinstance(err, CompilationError) or \
+   isinstance(err, LicenseError)):
+D( "%s: Don't send email to maintainer because the error
was " \ +   "%s and the information isn't useful, please
review it." \ +% (self.pn, type(err).__name__))
  return

I think a better approach here would be to have the classes of error that are
likely to be fixable by the maintainer as inheriting from a particular class
(e.g. MaintainerError) and then we can just check for that rather than having
to extend this code every time we add a new type of error.
I agree, i'll add new class MaintainerError and make 
Configure/Compilation/Patch/License to

extend it.




  if self.maintainer in maintainer_override:
@@ -478,6 +482,7 @@ class Updater(object):

  attempted_pkgs = 0
  for self.pn, self.new_ver, self.maintainer in pkgs_to_upgrade:
+error = None
  self.recipe = None
  attempted_pkgs += 1
  I(" ATTEMPT PACKAGE %d/%d" % (attempted_pkgs, total_pkgs))
@@ -489,10 +494,6 @@ class Updater(object):
  step()

  I(" %s: Upgrade SUCCESSFUL! Please test!" % self.pn)
-error = None
-except UpgradeNotNeededError as e:
-I(" %s: %s" % (self.pn, e.message))
-error = e

I'm confused by this. Won't this change result in UpgradeNotNeededError being
treated as an actual error? Surely we don't actually want that?
Now UpgradeNotNeededError is handled by new upstream mechanism when load 
recipes to upgrade

printing message about it.



Cheers,
Paul



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

Re: [yocto] [prelink-cross] error while loading shared libraries: ld-linux.so.3

[Florian Boehmak]

> The error indicates that it found a library required called
'ld-linux.so.3', but
> could not find that in the "path".  (The path generally being the sysroot
path
> passed to the rtld.)

I tried to move the files to their location in sysroot:

arm-2012.03/arm-none-linux-gnueabi/libc/usr/local/include/world.h
arm-2012.03/arm-none-linux-gnueabi/libc/usr/local/lib/libworld.so
arm-2012.03/arm-none-linux-gnueabi/libc/usr/local/bin/hello
arm-2012.03/arm-none-linux-gnueabi/libc/etc/prelink.conf


> What command did you use to run the prelinker?  And does your sysroot
contain
> the /lib/ld-linux.so.3?

prelink command:

PATH=/usr/local/sbin prelink --verbose
--root=arm-2012.03/arm-none-linux-gnueabi/libc
--cache-file=/etc/cache/prelink.cache --config-file=/etc/prelink.conf
--ld-library-path="/usr/local/lib;/lib;/usr/lib;" -h /usr/local/bin/hello


error message:

prelink: /lib/libdl-2.15.so is not present in any config file directories,
nor was specified on command line
prelink: /lib/libc-2.15.so is not present in any config file directories,
nor was specified on command line
prelink: /lib/libgcc_s.so.1 is not present in any config file directories,
nor was specified on command line
prelink: /lib/ld-2.15.so is not present in any config file directories, nor
was specified on command line
Laying out 1 libraries in virtual address space 4100-5000
Assigned virtual address space slots for libraries:
/usr/local/lib/libworld.so
4100-410086d0
prelink: Could not prelink /usr/lib/bin/localedef because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/POSIX_V6_ILP32_OFFBIG because its
dependency /lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/zdump because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/POSIX_V7_ILP32_OFF32 because its
dependency /lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/local/lib/libworld.so because its
dependency /lib/libgcc_s.so.1 could not be prelinked
prelink: Could not prelink /usr/local/bin/hello because its dependency
/usr/local/lib/libworld.so could not be prelinked
prelink: Could not prelink /usr/lib/bin/pldd because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/zic because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/sprof because its dependency
/lib/libdl.so.2 could not be prelinked
prelink: Could not prelink /usr/lib/bin/POSIX_V6_ILP32_OFF32 because its
dependency /lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/gdbserver because its dependency
/lib/libdl.so.2 could not be prelinked
prelink: Could not prelink /usr/lib/bin/XBS5_ILP32_OFFBIG because its
dependency /lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/XBS5_ILP32_OFF32 because its
dependency /lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/makedb because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/pcprofiledump because its
dependency /lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/iconv because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/locale because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/gencat because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/POSIX_V7_ILP32_OFFBIG because its
dependency /lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/rpcgen because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/getent because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/getconf because its dependency
/lib/libc.so.6 could not be prelinked
prelink: Could not prelink /usr/lib/bin/iconvconfig because its dependency
/lib/libc.so.6 could not be prelinked


prelink.conf

-l /lib
-h /lib
-l /usr/lib
-h /usr/lib
-l /usr/local/lib
-h /usr/local/lib


Now there is no error message from rtld and libworld.so seems to be found.
But what's the problem with the folling libraries?

libdl-2.15.so
libc-2.15.so
libgcc_s.so.1
ld-2.15.so


I can see them in this folder arm-2012.03/arm-none-linux-gnueabi/libc/lib:

-rwxr-xr-x 1 developer users  177212 10. Jun 18:43 ld-2.15.so
lrwxrwxrwx 1 developer users  10 10. Jun 18:43 ld-linux.so.3 ->
ld-2.15.so
-rwxr-xr-x 1 developer users 1777390 10. Jun 18:43 libc-2.15.so
lrwxrwxrwx 1 developer users  12 10. Jun 18:43 libc.so.6 -> libc-2.15.so
-rwxr-xr-x 1 developer users   26841 10. Jun 18:43 libdl-2.15.so
lrwxrwxrwx 1 developer users  13 10. Jun 18:43 libdl.so.2 ->
libdl-2.15.so
-rw-r--r-- 1 developer users 135 10. Jun 18:43 libgcc_s.so
-rw-r--r-- 1 developer users 3190583 10. Jun 18:43 libgcc_s.so.1
lrwxrwxrwx 1 developer users  

[yocto] [PATCH] dev-manual: Include biosfilename runqemu option

[leonardo . sandoval . gonzalez]

From: Leonardo Sandoval 

Poky's commit edde3e58da00adf9ef3a8cc687268f6e24294c7c included the
biosfilename option on the runqemu script.

Signed-off-by: Leonardo Sandoval 
---
 documentation/dev-manual/dev-manual-qemu.xml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/documentation/dev-manual/dev-manual-qemu.xml 
b/documentation/dev-manual/dev-manual-qemu.xml
index 4d95fbd..ccc915f 100644
--- a/documentation/dev-manual/dev-manual-qemu.xml
+++ b/documentation/dev-manual/dev-manual-qemu.xml
@@ -171,6 +171,9 @@
 Establishes a custom directory for BIOS, VGA BIOS and
 keymaps.
 
+biosfilename:
+Establishes a custom BIOS name.
+
 
qemuparams=\"xyz\":
 Specifies custom QEMU parameters.
 Use this option to pass options other than the simple
-- 
1.8.4.5

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

Re: [yocto] [prelink-cross] error while loading shared libraries: ld-linux.so.3

[Mark Hatle]

On 6/16/15 2:01 AM, Florian Boehmak wrote:
> Hi,
> 
> I am having difficulties to cross-prelink a simple hello world program.
> Prelinking for my x86 machine works fine (host system) but when using the arm
> cross-compile toolchain I get the error: 
> 
> prelink: bin_arm/hello: Could not parse `/usr/local/sbin//prelink-rtld: error
> while loading shared libraries: ld-linux.so.3'

The error indicates that it found a library required called 'ld-linux.so.3', but
could not find that in the "path".  (The path generally being the sysroot path
passed to the rtld.)

What command did you use to run the prelinker?  And does your sysroot contain
the /lib/ld-linux.so.3?

--Mark

> If I understand it correctly then prelink-rtld emulates ld-linux.so but why is
> it parsed by rtld?
> 
> Here are my files:
> 
> # main.cpp
> 
> #include 
> #include "world.h"
> int main (int argc, char *argv[])
> {
> fprintf(stdout, "hello\n");
> World w;
> w.Str();
> return 0;
> }
> 
> 
> # world.cpp
> 
> #include "world.h"
> void World::Str()
> {
> fprintf(stdout, "world\n");
> }
> 
> 
> # prelink_arm.conf
> 
> -l arm-2012.03/arm-none-linux-gnueabi/libc/lib 
> -h arm-2012.03/arm-none-linux-gnueabi/libc/lib 
> -l arm-2012.03/arm-none-linux-gnueabi/libc/usr/lib
> -h arm-2012.03/arm-none-linux-gnueabi/libc/usr/lib
> 
> 
> # compiling
> 
> ../arm-2012.03/bin/arm-none-linux-gnueabi-gcc -Wall -fPIC -shared -Iinclude -o
> lib_arm/libworld.so src/world.cpp 
> arm-2012.03/bin/arm-none-linux-gnueabi-gcc -Wall -Iworld/include
> -Lworld/lib_arm/ -lworld -o bin_arm/hello src/main.cpp
> 
> 
> # prelink-cross
> 
> PATH=/usr/local/sbin prelink --verbose --cache-file=cache/prelink_arm.cache
> --config-file=prelink_arm.conf
> --ld-library-path="world/lib_arm;arm-2012.03/arm-none-linux-gnueabi/libc/lib;arm-2012.03/arm-none-linux-gnueabi/libc/usr/lib;"
> -h bin_arm/hello
> 
> 
> I am sort of stuck. Could you point me in the right direction. What am I 
> missing
> or doing wrong?
> Thank you.
> 
> Cheers
> Florian
> 
> Ps. I have put together the code on github this would be the "shared-library"
> branch.
> https://github.com/fnbk/prelink-cross-example 
> 
> Ps. I posted a similar question on stackoverflow, cross-prelinking but without
> shared libraries.
> http://stackoverflow.com/q/30849060/5011904
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

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

[yocto] how to "harden" a freescale yocto-produced OS?

[Robert P. J. Day]

  i'm mailing to both lists since, while this question relates
specifically to the freescale SDK, i suspect others on the general
yocto list might have some opinions.

  an acquaintance asks if there is a way to security harden an OS
produced by the freescale v1.7 linux sdk, which i'm assuming is the
one available here:

 http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=SDKLINUX

so, other than the obvious technique of manually crawling over the
build configuration and locking things down, is there in fact a
recommended approach for locking down a yocto build, either in general
or perhaps specifically for the freescale SDK?

rday

p.s. i'm aware of the meta-security layer, although i've never taken a
close look at it. maybe now is the time.

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

Re: [yocto] Can not compile u-boot with meta toolchain

[mar.krzeminski]

That does the trick:

make CROSS_COMPILE=arm-poky-linux-gnueabi- 
CC="arm-poky-linux-gnueabi-gcc 
--sysroot=/media/work/sdk/sysroots/armv7a-vfp-neon-poky-linux-gnueabi" all


Regards,
Marcin

W dniu 16.06.2015 o 21:16, mar.krzeminski pisze:

Hi,

I've got problem with compiling u-boot usind SDK.
I am building image for my platform, then I am running commnad bitbake 
meta-toolchain.

In result I've got:
  CC  examples/standalone/hello_world.o
  LD  examples/standalone/hello_world
arm-poky-linux-gnueabi-ld.bfd: cannot find -lgcc
make[2]: *** [examples/standalone/hello_world] Error 1
scripts/Makefile.build:421: recipe for target 'examples/standalone' 
failed

make[1]: *** [examples/standalone] Error 2
Makefile:1145: recipe for target 'examples' failed
make: *** [examples] Error 2

In yocto environment u-boot builds fine.
I've also tried
unset LDFLAGS
unset CFLAGS
unset CPPFLAHS
before compilation.

What might be wrong here?

Regards,
Marcin


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

[yocto] Can not compile u-boot with meta toolchain

[mar.krzeminski]

Hi,

I've got problem with compiling u-boot usind SDK.
I am building image for my platform, then I am running commnad bitbake 
meta-toolchain.

In result I've got:
  CC  examples/standalone/hello_world.o
  LD  examples/standalone/hello_world
arm-poky-linux-gnueabi-ld.bfd: cannot find -lgcc
make[2]: *** [examples/standalone/hello_world] Error 1
scripts/Makefile.build:421: recipe for target 'examples/standalone' failed
make[1]: *** [examples/standalone] Error 2
Makefile:1145: recipe for target 'examples' failed
make: *** [examples] Error 2

In yocto environment u-boot builds fine.
I've also tried
unset LDFLAGS
unset CFLAGS
unset CPPFLAHS
before compilation.

What might be wrong here?

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

[yocto] [prelink-cross] error while loading shared libraries: ld-linux.so.3

[Florian Boehmak]

Hi, I tried to track down the error message which comes from rtld. This is
the call stack:

rtld.c:main()
rtld.c:process_one_dso()
dl-version.c:_dl_check_map_versions()



This is the code that produces the error message:

Elf64_Vernaux *aux;
struct link_map *needed = find_needed (strtab + ent->vn_file, map);

/* If NEEDED is NULL this means a dependency was not found
 and no stub entry was created.  This should never happen.  */
if (needed == NULL)
{
  _dl_signal_error (errval, NULL, NULL, strtab + ent->vn_file);
  printf("error while loading shared libraries: %s", strtab + ent->vn_file);
  exit (1);
}



This code loops through the needed versions of the link_map (Elf64_Verneed
*ent) and calls find_needed for each entry. find_needed calls
_dl_name_match_p and compares the library name. I have captured the
individual calls in debug statements and this is the result:

_dl_name_match_p name:libc.so.6
_dl_name_match_p name:libc.so.6
_dl_name_match_p name:libc.so.6
_dl_check_map_versions needed:1, file:libc.so.6

_dl_name_match_p name:libgcc_s.so.1
_dl_name_match_p name:libgcc_s.so.1
_dl_check_map_versions needed:1, file:libgcc_s.so.1

_dl_name_match_p name:libc.so.6
_dl_name_match_p name:libc.so.6
_dl_check_map_versions needed:1, file:libc.so.6

_dl_name_match_p name:ld-linux.so.3
_dl_name_match_p name:ld-linux.so.3
_dl_check_map_versions needed:NULL, file:ld-linux.so.3



As I can see the dependencies libc.so.6 and libgcc_s.so.1 are met. Only
ld-linux.so.3 is not. libc.so.6, libgcc_s.so.1 and ld-linux.so.3 are all in
the same location, so I don't understand what this error means.

arm-2012.03/arm-none-linux-gnueabi/libc/lib:
-rwxr-xr-x 1 developer users  177212 10. Jun 18:43 ld-2.15.so
lrwxrwxrwx 1 developer users  10 10. Jun 18:43 ld-linux.so.3 ->
ld-2.15.so
lrwxrwxrwx 1 developer users  12 10. Jun 18:43 libc.so.6 -> libc-2.15.so
-rw-r--r-- 1 developer users 135 10. Jun 18:43 libgcc_s.so
-rw-r--r-- 1 developer users 3190583 10. Jun 18:43 libgcc_s.so.1
...


Any hints? :-)
Thank you.

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

[yocto] [PATCH] Add support for libpam and rsyslog packages.

[Alexandru . Vaduva]

Signed-off-by: Alexandru.Vaduva 
---
 meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb 
b/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb
index 7bf6cca..2f2d55f 100644
--- a/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb
+++ b/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb
@@ -48,6 +48,8 @@ RDEPENDS_packagegroup-cgl-applications = " \
 audit \
 crash \
 pam-passwdqc \
+libpam \
+rsyslog \
 "
 
 LTTNG ?= "\
-- 
1.9.1

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

Re: [yocto] Removing rootfs from SDK

[Paul Eggleton]

On Tuesday 16 June 2015 14:20:35 John Ernberg wrote:
> On 2015-06-16 16:11, Paul Eggleton wrote:
> > On Tuesday 16 June 2015 14:05:15 John Ernberg wrote:
> >> On 2015-06-15 10:59, Paul Eggleton wrote:
> >>> On Monday 15 June 2015 05:39:24 John Ernberg wrote:
>  On 2015-06-12 14:43, Paul Eggleton wrote:
> > On Thursday 04 June 2015 09:30:49 John Ernberg wrote:
> >> We're trying to optimize the SDK generated by bitbake -c
> >> populate_sdk.
> >> Currently we're trying to remove the kernel, modules and other
> >> executables which we have no use for, most of it could be removed
> >> using
> >> IMAGE_INSTALL = "" and IMAGE_FEATURES = "".
> >> 
> >> Due to us using 2 different kernel module sets, we're using
> >> IMAGE_INSTALL_append_[machine] additions to IMAGE_INSTALL which are
> >> not
> >> cleared by the IMAGE_INSTALL = "" setting.
> >> 
> >> I've tried to do IMAGE_INSTALL_remove using the same variable that we
> >> use to populate the IMAGE_INSTALL_append, but that doesn't work. I
> >> can
> >> however remove each individual package added by IMAGE_INSTALL_append.
> >> Due to the number of packages added by IMAGE_INSTALL_append this is
> >> not
> >> really feasible.
> >> 
> >> Is there a way to clear IMAGE_INSTALL_append without doing an
> >> IMAGE_INSTALL_remove per package? Alternatively clearing it using a
> >> python loop without needing to know the name of each package.
> >> 
> >> We're also seeing busybox getting included into the SDK without
> >> anything
> >> showing a dependency on it from running bitbake -g -c populate_sdk.
> >> 
> >> What could be going on with that?
> > 
> > We construct the SDK for an image by getting a list of the packages in
> > the
> > image, and then including the -dev and -dbg packages that correspond
> > to
> > those in the host portion of the SDK. Thus if your image has busybox
> > in
> > it then you will get busybox-dev and busybox-dbg in your SDK.
> > 
> > In the dizzy (1.7) and later releases, there is a
> > PACKAGE_EXCLUDE_COMPLEMENTARY variable that can take a regex to match
> > packages that you do not wish to install complementary packages for.
> > You
> > could set this in your image recipe. Note that this will affect all
> > complementary package processing for the image as well as the SDK
> > (e.g.
> > dev-pkgs in IMAGE_FEATURES will also be affected, if you used that).
>  
>  I managed to clear out everything set by IMAGE_INSTALL and
>  IMAGE_FEATURES by setting PACKAGE_INSTALL = "".
>  So we no longer package the kernel etc into our SDK.
>  We do however still package the busybox binaries, when I run:
>  bitbake -e -c populate_sdk [image] | less
>  and then search for busybox, I get no results, so according to the
>  variables nothing adds busybox to the SDK.
>  I cannot figure out why busybox would get included, and I don't mean
>  the
>  dev and dbg packages here, but the actual binary package.
> >>> 
> >>> That'll be because the -dev package depends on the main package;
> >>> meta/conf/bitbake.conf has the following line which sets up this
> >>> dependency:
> >>> 
> >>> RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
> >>> 
> >>> You could set RDEPENDS_${PN}-dev = "" at the configuration level to
> >>> disable this, or you could do it per recipe with bbappends.
> >> 
> >> I just tried to apply this, combined with the PACKAGE_INSTALL solution,
> >> it will not work, and throws a huge build error log. Removing the
> >> PACKAGE_INSTALL solution and setting only the RDEPENDS solution in the
> >> local.conf will have no effect on the SDK at all. Busybox is still
> >> included, and it seems like all other binaries are back as well.
> > 
> > OK, that is not what I would expect - somehow there is still a dependency
> > on those files. You may wish to enable buildhistory as described here and
> > look at the dependency graphs it produces:
> > 
> > http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#mainta
> > ining-build-output-quality
> > 
> > It just occurred to me that if *any* of the packages you include in your
> > SDK include shell scripts, rpm will pretty much insist that you have a
> > provider of /bin/sh and that would be busybox, so that might also account
> > for busybox being in there. I don't immediately know how you would
> > exclude that.> 
> >> An excerpt of the build log:
> >> ERROR: Cannot get the package dependencies. Command
> >> '[path-to-yocto-build-dir]/tmp/sysroots/x86_64-linux/usr/bin/rpmresolve
> >> -t
> >> [path-to-yocto-build-dir]/tmp/work/[machine-and-sdk]/1.0-r0/sdk/image/opt
> >> /[d istro]/1.5+snapshot/sysroots/[target-arch]/var/lib/rpm' returned 1:
> >> base-files|busybox
> >> base-files|busybox
> >> base-files|busybox
> >> base-files|busybox
> >> base-files|busybox
> >> base-files|busy

Re: [yocto] Removing rootfs from SDK

[John Ernberg]

On 2015-06-16 16:11, Paul Eggleton wrote:
> On Tuesday 16 June 2015 14:05:15 John Ernberg wrote:
>> On 2015-06-15 10:59, Paul Eggleton wrote:
>>> On Monday 15 June 2015 05:39:24 John Ernberg wrote:
 On 2015-06-12 14:43, Paul Eggleton wrote:
> On Thursday 04 June 2015 09:30:49 John Ernberg wrote:
>> We're trying to optimize the SDK generated by bitbake -c populate_sdk.
>> Currently we're trying to remove the kernel, modules and other
>> executables which we have no use for, most of it could be removed using
>> IMAGE_INSTALL = "" and IMAGE_FEATURES = "".
>>
>> Due to us using 2 different kernel module sets, we're using
>> IMAGE_INSTALL_append_[machine] additions to IMAGE_INSTALL which are not
>> cleared by the IMAGE_INSTALL = "" setting.
>>
>> I've tried to do IMAGE_INSTALL_remove using the same variable that we
>> use to populate the IMAGE_INSTALL_append, but that doesn't work. I can
>> however remove each individual package added by IMAGE_INSTALL_append.
>> Due to the number of packages added by IMAGE_INSTALL_append this is not
>> really feasible.
>>
>> Is there a way to clear IMAGE_INSTALL_append without doing an
>> IMAGE_INSTALL_remove per package? Alternatively clearing it using a
>> python loop without needing to know the name of each package.
>>
>> We're also seeing busybox getting included into the SDK without
>> anything
>> showing a dependency on it from running bitbake -g -c populate_sdk.
>>
>> What could be going on with that?
> We construct the SDK for an image by getting a list of the packages in
> the
> image, and then including the -dev and -dbg packages that correspond to
> those in the host portion of the SDK. Thus if your image has busybox in
> it then you will get busybox-dev and busybox-dbg in your SDK.
>
> In the dizzy (1.7) and later releases, there is a
> PACKAGE_EXCLUDE_COMPLEMENTARY variable that can take a regex to match
> packages that you do not wish to install complementary packages for. You
> could set this in your image recipe. Note that this will affect all
> complementary package processing for the image as well as the SDK (e.g.
> dev-pkgs in IMAGE_FEATURES will also be affected, if you used that).
 I managed to clear out everything set by IMAGE_INSTALL and
 IMAGE_FEATURES by setting PACKAGE_INSTALL = "".
 So we no longer package the kernel etc into our SDK.
 We do however still package the busybox binaries, when I run:
 bitbake -e -c populate_sdk [image] | less
 and then search for busybox, I get no results, so according to the
 variables nothing adds busybox to the SDK.
 I cannot figure out why busybox would get included, and I don't mean the
 dev and dbg packages here, but the actual binary package.
>>> That'll be because the -dev package depends on the main package;
>>> meta/conf/bitbake.conf has the following line which sets up this
>>> dependency:
>>>
>>> RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
>>>
>>> You could set RDEPENDS_${PN}-dev = "" at the configuration level to
>>> disable this, or you could do it per recipe with bbappends.
>> I just tried to apply this, combined with the PACKAGE_INSTALL solution,
>> it will not work, and throws a huge build error log. Removing the
>> PACKAGE_INSTALL solution and setting only the RDEPENDS solution in the
>> local.conf will have no effect on the SDK at all. Busybox is still
>> included, and it seems like all other binaries are back as well.
> OK, that is not what I would expect - somehow there is still a dependency on
> those files. You may wish to enable buildhistory as described here and look at
> the dependency graphs it produces:
>
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality
>
> It just occurred to me that if *any* of the packages you include in your
> SDK include shell scripts, rpm will pretty much insist that you have a 
> provider
> of /bin/sh and that would be busybox, so that might also account for busybox
> being in there. I don't immediately know how you would exclude that.
>
>> An excerpt of the build log:
>> ERROR: Cannot get the package dependencies. Command
>> '[path-to-yocto-build-dir]/tmp/sysroots/x86_64-linux/usr/bin/rpmresolve
>> -t
>> [path-to-yocto-build-dir]/tmp/work/[machine-and-sdk]/1.0-r0/sdk/image/opt/[d
>> istro]/1.5+snapshot/sysroots/[target-arch]/var/lib/rpm' returned 1:
>> base-files|busybox
>> base-files|busybox
>> base-files|busybox
>> base-files|busybox
>> base-files|busybox
>> base-files|busybox
>> base-files|busybox
>> base-files|busybox
>> base-passwd|busybox
>> base-passwd-dev|libc6-dev [REC]
>> busybox|libc6
>> busybox|update-alternatives-opkg
>> busybox|libc6
>> busybox|libc6
>> busybox|libc6
>> busybox|libc6
>>
>> And then the log continues similarly for several pages. What could have
>> gone wrong?
> I can't tell what could be wrong from

Re: [yocto] Removing rootfs from SDK

[Paul Eggleton]

On Tuesday 16 June 2015 14:05:15 John Ernberg wrote:
> On 2015-06-15 10:59, Paul Eggleton wrote:
> > On Monday 15 June 2015 05:39:24 John Ernberg wrote:
> >> On 2015-06-12 14:43, Paul Eggleton wrote:
> >>> On Thursday 04 June 2015 09:30:49 John Ernberg wrote:
>  We're trying to optimize the SDK generated by bitbake -c populate_sdk.
>  Currently we're trying to remove the kernel, modules and other
>  executables which we have no use for, most of it could be removed using
>  IMAGE_INSTALL = "" and IMAGE_FEATURES = "".
>  
>  Due to us using 2 different kernel module sets, we're using
>  IMAGE_INSTALL_append_[machine] additions to IMAGE_INSTALL which are not
>  cleared by the IMAGE_INSTALL = "" setting.
>  
>  I've tried to do IMAGE_INSTALL_remove using the same variable that we
>  use to populate the IMAGE_INSTALL_append, but that doesn't work. I can
>  however remove each individual package added by IMAGE_INSTALL_append.
>  Due to the number of packages added by IMAGE_INSTALL_append this is not
>  really feasible.
>  
>  Is there a way to clear IMAGE_INSTALL_append without doing an
>  IMAGE_INSTALL_remove per package? Alternatively clearing it using a
>  python loop without needing to know the name of each package.
>  
>  We're also seeing busybox getting included into the SDK without
>  anything
>  showing a dependency on it from running bitbake -g -c populate_sdk.
>  
>  What could be going on with that?
> >>> 
> >>> We construct the SDK for an image by getting a list of the packages in
> >>> the
> >>> image, and then including the -dev and -dbg packages that correspond to
> >>> those in the host portion of the SDK. Thus if your image has busybox in
> >>> it then you will get busybox-dev and busybox-dbg in your SDK.
> >>> 
> >>> In the dizzy (1.7) and later releases, there is a
> >>> PACKAGE_EXCLUDE_COMPLEMENTARY variable that can take a regex to match
> >>> packages that you do not wish to install complementary packages for. You
> >>> could set this in your image recipe. Note that this will affect all
> >>> complementary package processing for the image as well as the SDK (e.g.
> >>> dev-pkgs in IMAGE_FEATURES will also be affected, if you used that).
> >> 
> >> I managed to clear out everything set by IMAGE_INSTALL and
> >> IMAGE_FEATURES by setting PACKAGE_INSTALL = "".
> >> So we no longer package the kernel etc into our SDK.
> >> We do however still package the busybox binaries, when I run:
> >> bitbake -e -c populate_sdk [image] | less
> >> and then search for busybox, I get no results, so according to the
> >> variables nothing adds busybox to the SDK.
> >> I cannot figure out why busybox would get included, and I don't mean the
> >> dev and dbg packages here, but the actual binary package.
> > 
> > That'll be because the -dev package depends on the main package;
> > meta/conf/bitbake.conf has the following line which sets up this
> > dependency:
> > 
> > RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
> > 
> > You could set RDEPENDS_${PN}-dev = "" at the configuration level to
> > disable this, or you could do it per recipe with bbappends.
> 
> I just tried to apply this, combined with the PACKAGE_INSTALL solution,
> it will not work, and throws a huge build error log. Removing the
> PACKAGE_INSTALL solution and setting only the RDEPENDS solution in the
> local.conf will have no effect on the SDK at all. Busybox is still
> included, and it seems like all other binaries are back as well.

OK, that is not what I would expect - somehow there is still a dependency on
those files. You may wish to enable buildhistory as described here and look at
the dependency graphs it produces:

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality

It just occurred to me that if *any* of the packages you include in your
SDK include shell scripts, rpm will pretty much insist that you have a provider
of /bin/sh and that would be busybox, so that might also account for busybox
being in there. I don't immediately know how you would exclude that.

> An excerpt of the build log:
> ERROR: Cannot get the package dependencies. Command
> '[path-to-yocto-build-dir]/tmp/sysroots/x86_64-linux/usr/bin/rpmresolve
> -t
> [path-to-yocto-build-dir]/tmp/work/[machine-and-sdk]/1.0-r0/sdk/image/opt/[d
> istro]/1.5+snapshot/sysroots/[target-arch]/var/lib/rpm' returned 1:
> base-files|busybox
> base-files|busybox
> base-files|busybox
> base-files|busybox
> base-files|busybox
> base-files|busybox
> base-files|busybox
> base-files|busybox
> base-passwd|busybox
> base-passwd-dev|libc6-dev [REC]
> busybox|libc6
> busybox|update-alternatives-opkg
> busybox|libc6
> busybox|libc6
> busybox|libc6
> busybox|libc6
> 
> And then the log continues similarly for several pages. What could have
> gone wrong?

I can't tell what could be wrong from just this start of the message -
is there anything useful at the end

Re: [yocto] Strange sstate problem

[Paul Eggleton]

On Sunday 14 June 2015 14:31:34 Gary Thomas wrote:
> On 2015-06-10 13:58, Gary Thomas wrote:
> > I'm building for two similar targets and sharing sstate between
> > them.  Actually, I build for target A and use that sstate cache
> > in my SSTATE_MIRRORS for target B.
> > 
> > If I try to build target B from scratch, i.e. wipe out most
> > 
> > everything from my build tree:
> >% mv cache sstate-cache tmp old2; rm -fr old&
> > 
> > I also have a PR server for each target - in local.conf:
> >PRSERV_HOST = "localhost:0"
> > 
> > When I build in target B, I'm getting a ton of QA errors, basically
> > one for every package selected, e.g.
> > 
> >ERROR: QA Issue: Package version for package fsl-alsa-plugins went
> >backwards which would break package feeds from (0:1.0.25-r0.2 to
> >0:1.0.25-r0.0) [version-going-backwards]> 
> > What could be going on here?
> > 
> > n.b. I'm using a fairly recent Poky/Yocto master
> > (a05663bfa10352fd5af6ca9a9d7b323c1c099f35)
>
> I discovered what was causing these errors - I have buildhistory
> enabled for target B.  Periodically I rebuild target A from scratch
> and this gives buildhistory on target B fits.  For now, I'll just
> disable buildhistory...
> 
> BTW, except for the buildhistory "errors", using sstate like
> this does help quite a lot.

FWIW buildhistory is only trying to help preserve the ability to do upgrades 
from your feeds here - if you don't care to see such errors you can remove 
"version-going-backwards" from your ERROR_QA value.

Cheers,
Paul

-- 

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

Re: [yocto] Removing rootfs from SDK

[John Ernberg]

On 2015-06-15 10:59, Paul Eggleton wrote:
> On Monday 15 June 2015 05:39:24 John Ernberg wrote:
>> On 2015-06-12 14:43, Paul Eggleton wrote:
>>> On Thursday 04 June 2015 09:30:49 John Ernberg wrote:
 We're trying to optimize the SDK generated by bitbake -c populate_sdk.
 Currently we're trying to remove the kernel, modules and other
 executables which we have no use for, most of it could be removed using
 IMAGE_INSTALL = "" and IMAGE_FEATURES = "".

 Due to us using 2 different kernel module sets, we're using
 IMAGE_INSTALL_append_[machine] additions to IMAGE_INSTALL which are not
 cleared by the IMAGE_INSTALL = "" setting.

 I've tried to do IMAGE_INSTALL_remove using the same variable that we
 use to populate the IMAGE_INSTALL_append, but that doesn't work. I can
 however remove each individual package added by IMAGE_INSTALL_append.
 Due to the number of packages added by IMAGE_INSTALL_append this is not
 really feasible.

 Is there a way to clear IMAGE_INSTALL_append without doing an
 IMAGE_INSTALL_remove per package? Alternatively clearing it using a
 python loop without needing to know the name of each package.

 We're also seeing busybox getting included into the SDK without anything
 showing a dependency on it from running bitbake -g -c populate_sdk.

 What could be going on with that?
>>> We construct the SDK for an image by getting a list of the packages in the
>>> image, and then including the -dev and -dbg packages that correspond to
>>> those in the host portion of the SDK. Thus if your image has busybox in
>>> it then you will get busybox-dev and busybox-dbg in your SDK.
>>>
>>> In the dizzy (1.7) and later releases, there is a
>>> PACKAGE_EXCLUDE_COMPLEMENTARY variable that can take a regex to match
>>> packages that you do not wish to install complementary packages for. You
>>> could set this in your image recipe. Note that this will affect all
>>> complementary package processing for the image as well as the SDK (e.g.
>>> dev-pkgs in IMAGE_FEATURES will also be affected, if you used that).
>> I managed to clear out everything set by IMAGE_INSTALL and
>> IMAGE_FEATURES by setting PACKAGE_INSTALL = "".
>> So we no longer package the kernel etc into our SDK.
>> We do however still package the busybox binaries, when I run:
>> bitbake -e -c populate_sdk [image] | less
>> and then search for busybox, I get no results, so according to the
>> variables nothing adds busybox to the SDK.
>> I cannot figure out why busybox would get included, and I don't mean the
>> dev and dbg packages here, but the actual binary package.
> That'll be because the -dev package depends on the main package;
> meta/conf/bitbake.conf has the following line which sets up this dependency:
>
> RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
>
> You could set RDEPENDS_${PN}-dev = "" at the configuration level to disable
> this, or you could do it per recipe with bbappends.
>
> Cheers,
> Paul
>
Hi Paul

I just tried to apply this, combined with the PACKAGE_INSTALL solution, 
it will not work, and throws a huge build error log. Removing the 
PACKAGE_INSTALL solution and setting only the RDEPENDS solution in the 
local.conf will have no effect on the SDK at all. Busybox is still 
included, and it seems like all other binaries are back as well.

An excerpt of the build log:
ERROR: Cannot get the package dependencies. Command 
'[path-to-yocto-build-dir]/tmp/sysroots/x86_64-linux/usr/bin/rpmresolve 
-t 
[path-to-yocto-build-dir]/tmp/work/[machine-and-sdk]/1.0-r0/sdk/image/opt/[distro]/1.5+snapshot/sysroots/[target-arch]/var/lib/rpm'
 
returned 1:
base-files|busybox
base-files|busybox
base-files|busybox
base-files|busybox
base-files|busybox
base-files|busybox
base-files|busybox
base-files|busybox
base-passwd|busybox
base-passwd-dev|libc6-dev [REC]
busybox|libc6
busybox|update-alternatives-opkg
busybox|libc6
busybox|libc6
busybox|libc6
busybox|libc6

And then the log continues similarly for several pages. What could have 
gone wrong?

Best regards // John Ernberg
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sstate black hole?

[Paul Eggleton]

On Tuesday 16 June 2015 07:21:05 Gary Thomas wrote:
> On 2015-06-16 06:36, Paul Eggleton wrote:
> > On Tuesday 16 June 2015 04:47:53 Gary Thomas wrote:
> >> On 2015-06-16 02:37, Paul Eggleton wrote:
> >>> On Monday 15 June 2015 18:19:21 Gary Thomas wrote:
>  I followed this down to an i.MX6 specific package which is
>  
>  in DEPENDS:
>   Variable PROVIDES value changed from
>   '${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl
>  
>  virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
>  virtual/libgles2' to
>  
>   '${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl
>  
>  virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
>  virtual/libgles2 virtual/libgl virtual/libgles1 virtual/libgles2'
>  
>  Why aren't these considered the same (duplicate elements and/or order)
>  should not matter for PROVIDES.  Is there some way we could get bitbake
>  to collapse this and remove the duplicates?
>  
>  I found that this happens in
>  meta-fsl-arm:recipes-graphics/imx-gpu-viv/imx-gpu-viv.inc which
>  contains
>  
>  these lines:
>   PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl
>  
>  virtual/libopenvg virtual/libg2d"
>  PROVIDES_append_mx6q  = " virtual/libgl virtual/libgles1
>  virtual/libgles2"
>  PROVIDES_append_mx6dl  = " virtual/libgl virtual/libgles1
>  virtual/libgles2"
>  PROVIDES_append_mx6sx  = " virtual/libgl virtual/libgles1
>  virtual/libgles2"
>  
>  Some i.MX6 targets, nitrogen6x in particular, has overrides for both
>  mx6q
>  and mx6dl, hence the duplication.
>  
>  Note: I removed the extra override (for testing) and found that
>  now the packages built by target A can be shared via sstate with
>  target B (at least the few I tested)
> >>> 
> >>> I agree this would be nice, but for this to work we'd probably need to
> >>> introduce a typing system within bitbake so that it can understand that
> >>> this variable is a space-separated list. That is something we will
> >>> probably do at some point for a variety of reasons, but I don't know
> >>> that
> >>> it's something we will get to soon.
> >> 
> >> Is there some way to solve this in the recipe itself?  I can see that
> >> it needs to make sure that those values are provided for each of the
> >> [sub]class of processor, but is there a way to write it so that they
> >> are only added once?  Perhaps a little bit of Python magic?
> > 
> > Sure, you could use an anonymous python function with actual conditional
> > statements instead of overrides to set PROVIDES here.
> 
> Thanks.  I found a much simpler way - I replaced the previous version by:
>EXTRA_PROVIDES = ""
>EXTRA_PROVIDES_mx6q  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> EXTRA_PROVIDES_mx6dl  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> EXTRA_PROVIDES_mx6sx  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d ${EXTRA_PROVIDES}"
> 
> If the additions were unique, i.e. _mx6q was somehow different from _mx6dl,
> I would have had to use the python function, but since they are all the same
> this simpler way works just fine.

Yep, that will work too - good job :)

Cheers,
Paul

-- 

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

Re: [yocto] [oe] [OE-core] Webkit-gtk will be updated to latest upstream; midori browser to be replaced with Epiphany

[Alexander Kanavin]

On 06/16/2015 04:37 PM, Alexander Kanavin wrote:

Latest epiphany will be provided as a replacement for midori. It
works fine here in the core-image-sato under qemu. I can't promise it
will work on ARM, but any ARM-specific issues are almost certainly
in webkit's (or other web engine's) javascript JIT code and have
nothing to do with the browser.


Oh, and with webkit it's trivial to disable JIT at compile time; in fact
I have to do it for ARMv5 and ARMv6 because it has bitrotten for those
architectures due to lack of upstream testing.

Alex

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

Re: [yocto] [OE-core] Webkit-gtk will be updated to latest upstream; midori browser to be replaced with Epiphany

[Alexander Kanavin]

On 06/16/2015 04:27 PM, Andreas Müller wrote:


Yes and midori is the only working browser in Yocto (I know): firefox
crashes since very long time for illegal ARM instruction and chromium
does not start at all.


Latest epiphany will be provided as a replacement for midori. It works 
fine here in the core-image-sato under qemu. I can't promise it will 
work on ARM, but any ARM-specific issues are almost certainly in 
webkit's (or other web engine's) javascript JIT code and have nothing to 
do with the browser.


Alex

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

Re: [yocto] [OE-core] Webkit-gtk will be updated to latest upstream; midori browser to be replaced with Epiphany

[Andreas Müller]

On Tue, Jun 16, 2015 at 2:39 PM, Alexander Kanavin
 wrote:
> On 06/16/2015 09:50 AM, Andreas Müller wrote:
>
>> How about doing same as others do e.g fedora [1-2]: Keep two version
>> of webkit-gtk based on same recent code:
>>
>> * gtk2/webkit1
>> * gtk3/webkit2
>
>
> Before showing how, you need to explain why. Fedora has to package webkit1
> because they have a lot of apps in the Gnome stack that still haven't been
> ported to webkit2. Oe-core on the other hand has only one such app: midori.
Yes and midori is the only working browser in Yocto (I know): firefox
crashes since very long time for illegal ARM instruction and chromium
does not start at all.

I suggest we stop discussing my comment: You continue updating
webkitgtk and I'll try to get a working browser.

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

Re: [yocto] sstate black hole?

[Gary Thomas]

On 2015-06-16 06:36, Paul Eggleton wrote:

On Tuesday 16 June 2015 04:47:53 Gary Thomas wrote:

On 2015-06-16 02:37, Paul Eggleton wrote:

On Monday 15 June 2015 18:19:21 Gary Thomas wrote:

I followed this down to an i.MX6 specific package which is

in DEPENDS:
 Variable PROVIDES value changed from
 '${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl

virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
virtual/libgles2' to

 '${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl

virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
virtual/libgles2 virtual/libgl virtual/libgles1 virtual/libgles2'

Why aren't these considered the same (duplicate elements and/or order)
should not matter for PROVIDES.  Is there some way we could get bitbake
to collapse this and remove the duplicates?

I found that this happens in
meta-fsl-arm:recipes-graphics/imx-gpu-viv/imx-gpu-viv.inc which contains

these lines:
 PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl

virtual/libopenvg virtual/libg2d"
PROVIDES_append_mx6q  = " virtual/libgl virtual/libgles1
virtual/libgles2"
PROVIDES_append_mx6dl  = " virtual/libgl virtual/libgles1
virtual/libgles2"
PROVIDES_append_mx6sx  = " virtual/libgl virtual/libgles1
virtual/libgles2"

Some i.MX6 targets, nitrogen6x in particular, has overrides for both mx6q
and mx6dl, hence the duplication.

Note: I removed the extra override (for testing) and found that
now the packages built by target A can be shared via sstate with
target B (at least the few I tested)


I agree this would be nice, but for this to work we'd probably need to
introduce a typing system within bitbake so that it can understand that
this variable is a space-separated list. That is something we will
probably do at some point for a variety of reasons, but I don't know that
it's something we will get to soon.


Is there some way to solve this in the recipe itself?  I can see that
it needs to make sure that those values are provided for each of the
[sub]class of processor, but is there a way to write it so that they
are only added once?  Perhaps a little bit of Python magic?


Sure, you could use an anonymous python function with actual conditional
statements instead of overrides to set PROVIDES here.


Thanks.  I found a much simpler way - I replaced the previous version by:
  EXTRA_PROVIDES = ""
  EXTRA_PROVIDES_mx6q  = " virtual/libgl virtual/libgles1 virtual/libgles2"
  EXTRA_PROVIDES_mx6dl  = " virtual/libgl virtual/libgles1 virtual/libgles2"
  EXTRA_PROVIDES_mx6sx  = " virtual/libgl virtual/libgles1 virtual/libgles2"
  PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl virtual/libopenvg 
virtual/libg2d ${EXTRA_PROVIDES}"

If the additions were unique, i.e. _mx6q was somehow different from _mx6dl,
I would have had to use the python function, but since they are all the same
this simpler way works just fine.

Thanks for the pointers

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] [PATCHv2 09/11][auh] upgradehelper.py: Change policy for send emails and fix error passing

[Paul Eggleton]

Hi Aníbal,

On Friday 12 June 2015 20:10:45 Aníbal Limón wrote:
> Now send emails almost in all cases this give the maintainer
> patches and diff to continue work also if the build isn't
> succesful.
> 
> [YOCTO #7489]
> 
> Signed-off-by: Aníbal Limón 
> ---
>  upgradehelper.py | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/upgradehelper.py b/upgradehelper.py
> index b1f075d..d065fba 100755
> --- a/upgradehelper.py
> +++ b/upgradehelper.py
> @@ -346,8 +346,6 @@ class Updater(object):
>  self.git.clean_untracked()
>  return
> 
> -status = type(err).__name__
> -
>  # drop last upgrade from git. It's safer this way if the upgrade
> has # problems and other recipes depend on it. Give the other recipes a #
> chance...
> @@ -381,8 +379,14 @@ class Updater(object):
>  "Attached are the patch, license diff (if change) and
> bitbake log.\n\n" \ "Regards,\nThe Upgrade Helper"
> 
> -# don't bother maintainer with mail if the recipe is already up
> to date -if status == "UpgradeNotNeededError":
> +# if error only send email when useful infomration for
> maintainers exist +if err and not (isinstance(err, PatchError)
> or \
> +   isinstance(err, ConfigureError) or \
> +   isinstance(err, CompilationError) or \
> +   isinstance(err, LicenseError)):
> +D( "%s: Don't send email to maintainer because the error
> was " \ +   "%s and the information isn't useful, please
> review it." \ +% (self.pn, type(err).__name__))
>  return

I think a better approach here would be to have the classes of error that are 
likely to be fixable by the maintainer as inheriting from a particular class 
(e.g. MaintainerError) and then we can just check for that rather than having 
to extend this code every time we add a new type of error.

>  if self.maintainer in maintainer_override:
> @@ -478,6 +482,7 @@ class Updater(object):
> 
>  attempted_pkgs = 0
>  for self.pn, self.new_ver, self.maintainer in pkgs_to_upgrade:
> +error = None
>  self.recipe = None
>  attempted_pkgs += 1
>  I(" ATTEMPT PACKAGE %d/%d" % (attempted_pkgs, total_pkgs))
> @@ -489,10 +494,6 @@ class Updater(object):
>  step()
> 
>  I(" %s: Upgrade SUCCESSFUL! Please test!" % self.pn)
> -error = None
> -except UpgradeNotNeededError as e:
> -I(" %s: %s" % (self.pn, e.message))
> -error = e

I'm confused by this. Won't this change result in UpgradeNotNeededError being 
treated as an actual error? Surely we don't actually want that?

Cheers,
Paul

-- 

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

Re: [yocto] [OE-core] Webkit-gtk will be updated to latest upstream; midori browser to be replaced with Epiphany

[Alexander Kanavin]

On 06/16/2015 09:50 AM, Andreas Müller wrote:


How about doing same as others do e.g fedora [1-2]: Keep two version
of webkit-gtk based on same recent code:

* gtk2/webkit1
* gtk3/webkit2


Before showing how, you need to explain why. Fedora has to package 
webkit1 because they have a lot of apps in the Gnome stack that still 
haven't been ported to webkit2. Oe-core on the other hand has only one 
such app: midori.


Also, webkit1 has been deprecated for years, and there is no commitment 
from upstream to maintain the 2.4.x series which is the last that still 
has it in the source tree; they may cease to do it at any moment. So 
once again, why keep it in oe-core?


Regards,
Alex

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

Re: [yocto] sstate black hole?

[Paul Eggleton]

On Tuesday 16 June 2015 04:47:53 Gary Thomas wrote:
> On 2015-06-16 02:37, Paul Eggleton wrote:
> > On Monday 15 June 2015 18:19:21 Gary Thomas wrote:
> >> I followed this down to an i.MX6 specific package which is
> >> 
> >> in DEPENDS:
> >> Variable PROVIDES value changed from
> >> '${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl
> >> 
> >> virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
> >> virtual/libgles2' to
> >> 
> >> '${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl
> >> 
> >> virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
> >> virtual/libgles2 virtual/libgl virtual/libgles1 virtual/libgles2'
> >> 
> >> Why aren't these considered the same (duplicate elements and/or order)
> >> should not matter for PROVIDES.  Is there some way we could get bitbake
> >> to collapse this and remove the duplicates?
> >> 
> >> I found that this happens in
> >> meta-fsl-arm:recipes-graphics/imx-gpu-viv/imx-gpu-viv.inc which contains
> >> 
> >> these lines:
> >> PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl
> >> 
> >> virtual/libopenvg virtual/libg2d"
> >> PROVIDES_append_mx6q  = " virtual/libgl virtual/libgles1
> >> virtual/libgles2"
> >> PROVIDES_append_mx6dl  = " virtual/libgl virtual/libgles1
> >> virtual/libgles2"
> >> PROVIDES_append_mx6sx  = " virtual/libgl virtual/libgles1
> >> virtual/libgles2"
> >> 
> >> Some i.MX6 targets, nitrogen6x in particular, has overrides for both mx6q
> >> and mx6dl, hence the duplication.
> >> 
> >> Note: I removed the extra override (for testing) and found that
> >> now the packages built by target A can be shared via sstate with
> >> target B (at least the few I tested)
> > 
> > I agree this would be nice, but for this to work we'd probably need to
> > introduce a typing system within bitbake so that it can understand that
> > this variable is a space-separated list. That is something we will
> > probably do at some point for a variety of reasons, but I don't know that
> > it's something we will get to soon.
> 
> Is there some way to solve this in the recipe itself?  I can see that
> it needs to make sure that those values are provided for each of the
> [sub]class of processor, but is there a way to write it so that they
> are only added once?  Perhaps a little bit of Python magic?

Sure, you could use an anonymous python function with actual conditional 
statements instead of overrides to set PROVIDES here.

Cheers,
Paul

-- 

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

Re: [yocto] sstate black hole?

[Gary Thomas]

On 2015-06-16 02:37, Paul Eggleton wrote:

On Monday 15 June 2015 18:19:21 Gary Thomas wrote:

I followed this down to an i.MX6 specific package which is
in DEPENDS:
Variable PROVIDES value changed from
'${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl
virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
virtual/libgles2' to
'${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl
virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
virtual/libgles2 virtual/libgl virtual/libgles1 virtual/libgles2'

Why aren't these considered the same (duplicate elements and/or order)
should not matter for PROVIDES.  Is there some way we could get bitbake
to collapse this and remove the duplicates?

I found that this happens in
meta-fsl-arm:recipes-graphics/imx-gpu-viv/imx-gpu-viv.inc which contains
these lines:
PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl
virtual/libopenvg virtual/libg2d"
PROVIDES_append_mx6q  = " virtual/libgl virtual/libgles1 virtual/libgles2"
PROVIDES_append_mx6dl  = " virtual/libgl virtual/libgles1 virtual/libgles2"
PROVIDES_append_mx6sx  = " virtual/libgl virtual/libgles1 virtual/libgles2"

Some i.MX6 targets, nitrogen6x in particular, has overrides for both mx6q
and mx6dl, hence the duplication.

Note: I removed the extra override (for testing) and found that
now the packages built by target A can be shared via sstate with
target B (at least the few I tested)


I agree this would be nice, but for this to work we'd probably need to
introduce a typing system within bitbake so that it can understand that this
variable is a space-separated list. That is something we will probably do at
some point for a variety of reasons, but I don't know that it's something we
will get to soon.


Is there some way to solve this in the recipe itself?  I can see that
it needs to make sure that those values are provided for each of the
[sub]class of processor, but is there a way to write it so that they
are only added once?  Perhaps a little bit of Python magic?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] sstate black hole?

[Paul Eggleton]

On Monday 15 June 2015 18:19:21 Gary Thomas wrote:
> I followed this down to an i.MX6 specific package which is
> in DEPENDS:
>Variable PROVIDES value changed from
>'${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
> virtual/libgles2' to
>'${PN}  virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d virtual/libgl virtual/libgles1
> virtual/libgles2 virtual/libgl virtual/libgles1 virtual/libgles2'
> 
> Why aren't these considered the same (duplicate elements and/or order)
> should not matter for PROVIDES.  Is there some way we could get bitbake
> to collapse this and remove the duplicates?
> 
> I found that this happens in
> meta-fsl-arm:recipes-graphics/imx-gpu-viv/imx-gpu-viv.inc which contains
> these lines:
>PROVIDES += "virtual/wayland-egl virtual/libgal-x11 virtual/egl
> virtual/libopenvg virtual/libg2d" 
> PROVIDES_append_mx6q  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> PROVIDES_append_mx6dl  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> PROVIDES_append_mx6sx  = " virtual/libgl virtual/libgles1 virtual/libgles2"
> 
> Some i.MX6 targets, nitrogen6x in particular, has overrides for both mx6q
> and mx6dl, hence the duplication.
> 
> Note: I removed the extra override (for testing) and found that
> now the packages built by target A can be shared via sstate with
> target B (at least the few I tested)

I agree this would be nice, but for this to work we'd probably need to 
introduce a typing system within bitbake so that it can understand that this 
variable is a space-separated list. That is something we will probably do at 
some point for a variety of reasons, but I don't know that it's something we 
will get to soon.

Cheers,
Paul

-- 

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

[yocto] [prelink-cross] error while loading shared libraries: ld-linux.so.3

[Florian Boehmak]

Hi,

I am having difficulties to cross-prelink a simple hello world program.
Prelinking for my x86 machine works fine (host system) but when using the
arm cross-compile toolchain I get the error:

prelink: bin_arm/hello: Could not parse `/usr/local/sbin//prelink-rtld:
error while loading shared libraries: ld-linux.so.3'

If I understand it correctly then prelink-rtld emulates ld-linux.so but why
is it parsed by rtld?

Here are my files:

# main.cpp

#include 
#include "world.h"
int main (int argc, char *argv[])
{
fprintf(stdout, "hello\n");
World w;
w.Str();
return 0;
}


# world.cpp

#include "world.h"
void World::Str()
{
fprintf(stdout, "world\n");
}


# prelink_arm.conf

-l arm-2012.03/arm-none-linux-gnueabi/libc/lib
-h arm-2012.03/arm-none-linux-gnueabi/libc/lib
-l arm-2012.03/arm-none-linux-gnueabi/libc/usr/lib
-h arm-2012.03/arm-none-linux-gnueabi/libc/usr/lib


# compiling

../arm-2012.03/bin/arm-none-linux-gnueabi-gcc -Wall -fPIC -shared -Iinclude
-o lib_arm/libworld.so src/world.cpp
arm-2012.03/bin/arm-none-linux-gnueabi-gcc -Wall -Iworld/include
-Lworld/lib_arm/ -lworld -o bin_arm/hello src/main.cpp


# prelink-cross

PATH=/usr/local/sbin prelink --verbose --cache-file=cache/prelink_arm.cache
--config-file=prelink_arm.conf
--ld-library-path="world/lib_arm;arm-2012.03/arm-none-linux-gnueabi/libc/lib;arm-2012.03/arm-none-linux-gnueabi/libc/usr/lib;"
-h bin_arm/hello


I am sort of stuck. Could you point me in the right direction. What am I
missing or doing wrong?
Thank you.

Cheers
Florian

Ps. I have put together the code on github this would be the
"shared-library" branch.
https://github.com/fnbk/prelink-cross-example

Ps. I posted a similar question on stackoverflow, cross-prelinking but
without shared libraries.
http://stackoverflow.com/q/30849060/5011904
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto