[oe] How can I make recipes conditionally enabled?

2013-08-27 Thread Carlos Rafael Giani

Hello,

I have a question about a problem I've had several times in the past:

if I write a layer, and add .bbappends, then the layers with the 
corresponding .bb files become hard dependencies.
But lets say I want to write a BSP layer, and I add some machine 
specific Qt5 patches. Now everybody who wants to use
my layer must also include meta-qt5, even when they don't really want to 
use Qt5 anywhere. This is made even worse
if I have a dependency on meta-oe, which itself brings in a lot of 
modifications.


In short, I'd like to be able to make .bbappends and .bb files dependend 
on whether or not a layer is available. The hard
dependency is fine if it concerns things that are essential in my layer. 
But if its about optional things, it shouldn't cause

a build failure.

Thoughts?
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [meta-oe] [PATCH] log4cplus: add recipe

2013-08-27 Thread Maxin B. John
On Mon, Aug 26, 2013 at 07:59:57PM +0100, Paul Eggleton wrote:

Hi Paul,

 Hi Maxin,
 On Monday 26 August 2013 13:06:19 maxin.j...@enea.com wrote:
  From: Maxin B. John maxin.j...@enea.com
  log4cplus provides a simple C++ logging API for log management.
  Signed-off-by: Maxin B. John maxin.j...@enea.com
  ---
   .../recipes-devtools/log4cplus/log4cplus_1.1.1.bb|   18
  ++ 1 file changed, 18 insertions(+)
snip
 If you're setting a short description only, please set it in SUMMARY rather·
 than DESCRIPTION.
Ok, I will set it in SUMMARY.

  +SECTION = libs
  +HOMEPAGE = http://sourceforge.net/projects/liblog4cplus/;
 This HOMEPAGE value is incorrect.
ouch. Will correct it.

Thank you very much for reviewing this. I will send the updated
version soon.
 Cheers,
 Paul

Thanks and Regards,
Maxin
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


[oe] [meta-oe][PATCH ] libhugetlbfs: add recipe

2013-08-27 Thread b40290
From: Chunrong Guo b40...@freescale.com

  *libhugetlbfs is a library which provides easy access to huge pages of memory

Signed-off-by: Chunrong Guo b40...@freescale.com
---
 ...ler-to-be-override-regardless-of-32-or-64.patch |   94 ++
 ...rl-lib-to-directory-perl-instead-of-perl5.patch |   41 ++
 ...s-avoid-search-host-library-path-for-cros.patch |   70 +++
 .../files/0002-Fix-cross-compiling-on-PPC.patch|   39 ++
 ...fs-Remove-segment-based-alignment-restric.patch |  130 
 ...-run_tests.py-fix-typo-in-test-invocation.patch |   29 +
 .../files/checks-if-mtab-is-a-symlink.patch|   30 +
 ...s-Fix-perl-lib-can-not-be-shiped-to-sub-p.patch |   34 +
 ...ng-LIB32-and-LIB64-if-they-point-to-the-s.patch |   47 +++
 ...Makefile-install-static-4G-edge-testcases.patch |   29 +
 .../libhugetlbfs/libhugetlbfs_git.bb   |   49 
 11 files changed, 592 insertions(+), 0 deletions(-)
 create mode 100644 
meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Allow-compiler-to-be-override-regardless-of-32-or-64.patch
 create mode 100644 
meta-oe/recipes-benchmark/libhugetlbfs/files/0001-install-perl-lib-to-directory-perl-instead-of-perl5.patch
 create mode 100644 
meta-oe/recipes-benchmark/libhugetlbfs/files/0001-libhugetlbfs-avoid-search-host-library-path-for-cros.patch
 create mode 100644 
meta-oe/recipes-benchmark/libhugetlbfs/files/0002-Fix-cross-compiling-on-PPC.patch
 create mode 100644 
meta-oe/recipes-benchmark/libhugetlbfs/files/0003-libhugetlbfs-Remove-segment-based-alignment-restric.patch
 create mode 100644 
meta-oe/recipes-benchmark/libhugetlbfs/files/0004-tests-run_tests.py-fix-typo-in-test-invocation.patch
 create mode 100644 
meta-oe/recipes-benchmark/libhugetlbfs/files/checks-if-mtab-is-a-symlink.patch
 create mode 100644 
meta-oe/recipes-benchmark/libhugetlbfs/files/libhugetlbfs-Fix-perl-lib-can-not-be-shiped-to-sub-p.patch
 create mode 100644 
meta-oe/recipes-benchmark/libhugetlbfs/files/skip-checking-LIB32-and-LIB64-if-they-point-to-the-s.patch
 create mode 100644 
meta-oe/recipes-benchmark/libhugetlbfs/files/tests-Makefile-install-static-4G-edge-testcases.patch
 create mode 100644 meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb

diff --git 
a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Allow-compiler-to-be-override-regardless-of-32-or-64.patch
 
b/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Allow-compiler-to-be-override-regardless-of-32-or-64.patch
new file mode 100644
index 000..ee9138b
--- /dev/null
+++ 
b/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Allow-compiler-to-be-override-regardless-of-32-or-64.patch
@@ -0,0 +1,94 @@
+From efba2e8dae0d2140289acd7a7fcc0e30ff00d676 Mon Sep 17 00:00:00 2001
+From: Chunrong Guo b40...@freescale.com
+Date: Mon, 5 Aug 2013 21:36:57 -0500
+Subject: [PATCH] Allow compiler to be override regardless of 32 or 64-bit build
+
+Provide an easy means for cross compiling to override the compiler
+without having to know if we intend a 32-bit or 64-bit build.
+
+
+Upstream-Status: Accepted
+Signed-off-by: Kumar Gala ga...@kernel.crashing.org
+Signed-off-by: Chunrong b40...@freescale.com
+---
+ Makefile |   23 ---
+ 1 file changed, 12 insertions(+), 11 deletions(-)
+
+diff --git a/Makefile b/Makefile
+index 48205af..878c71b 100644
+--- a/Makefile
 b/Makefile
+@@ -33,58 +33,59 @@ CFLAGS += -Wall -fPIC
+ CPPFLAGS += -D__LIBHUGETLBFS__
+ 
+ ARCH = $(shell uname -m | sed -e s/i.86/i386/)
++CC = gcc
+ 
+ CUSTOM_LDSCRIPTS = yes
+ 
+ ifeq ($(ARCH),ppc64)
+-CC64 = gcc -m64
++CC64 = $(CC) -m64
+ ELF64 = elf64ppc
+ TMPLIB64 = lib64
+ TMPLIB32 = lib
+ ifneq ($(BUILDTYPE),NATIVEONLY)
+-CC32 = gcc -m32
++CC32 = $(CC) -m32
+ ELF32 = elf32ppclinux
+ endif
+ else
+ ifeq ($(ARCH),ppc)
+-CC32 = gcc -m32
++CC32 = $(CC) -m32
+ ELF32 = elf32ppclinux
+ TMPLIB32 = lib
+ else
+ ifeq ($(ARCH),armv7l)
+-CC32 = gcc
++CC32 = $(CC)
+ TMPLIB32 = lib
+ ELF32 += armelf_linux_eabi
+ CUSTOM_LDSCRIPTS = no
+ else
+ ifeq ($(ARCH),i386)
+-CC32 = gcc
++CC32 = $(CC)
+ ELF32 = elf_i386
+ TMPLIB32 = lib
+ else
+ ifeq ($(ARCH),x86_64)
+-CC64 = gcc -m64
++CC64 = $(CC) -m64
+ ELF64 = elf_x86_64
+ TMPLIB64 = lib64
+ TMPLIB32 = lib
+ ifneq ($(BUILDTYPE),NATIVEONLY)
+-CC32 = gcc -m32
++CC32 = $(CC) -m32
+ ELF32 = elf_i386
+ endif
+ else
+ ifeq ($(ARCH),ia64)
+-CC64 = gcc
++CC64 = $(CC)
+ TMPLIB64 = lib64
+ CFLAGS += -DNO_ELFLINK
+ else
+ ifeq ($(ARCH),sparc64)
+-CC64 = gcc -m64
++CC64 = $(CC) -m64
+ TMPLIB64 = lib64
+ CFLAGS += -DNO_ELFLINK
+ else
+ ifeq ($(ARCH),s390x)
+-CC64 = gcc -m64
+-CC32 = gcc -m31
++CC64 = $(CC) -m64
++CC32 = $(CC) -m31
+ ELF32 = elf_s390
+ ELF64 = elf64_s390
+ TMPLIB64 = lib64
+-- 
+1.7.9.7
+
diff --git 
a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-install-perl-lib-to-directory-perl-instead-of-perl5.patch
 
b/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-install-perl-lib-to-directory-perl-instead-of-perl5.patch
new file mode 100644
index 

Re: [oe] How can I make recipes conditionally enabled?

2013-08-27 Thread Martin Jansa
On Tue, Aug 27, 2013 at 09:12:15AM +0200, Carlos Rafael Giani wrote:
 Hello,
 
 I have a question about a problem I've had several times in the past:
 
 if I write a layer, and add .bbappends, then the layers with the 
 corresponding .bb files become hard dependencies.
 But lets say I want to write a BSP layer, and I add some machine 
 specific Qt5 patches. Now everybody who wants to use
 my layer must also include meta-qt5, even when they don't really want to 
 use Qt5 anywhere. This is made even worse
 if I have a dependency on meta-oe, which itself brings in a lot of 
 modifications.
 
 In short, I'd like to be able to make .bbappends and .bb files dependend 
 on whether or not a layer is available. The hard
 dependency is fine if it concerns things that are essential in my layer. 
 But if its about optional things, it shouldn't cause
 a build failure.

BB_DANGLINGAPPENDS_WARNONLY is the magic word.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


[oe] [meta-oe] [PATCH v2] log4cplus: add recipe

2013-08-27 Thread maxin.john
From: Maxin B. John maxin.j...@enea.com

log4cplus provides a simple C++ logging API for log management.

Signed-off-by: Maxin B. John maxin.j...@enea.com
---
 .../recipes-devtools/log4cplus/log4cplus_1.1.1.bb|   18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 meta-oe/recipes-devtools/log4cplus/log4cplus_1.1.1.bb

diff --git a/meta-oe/recipes-devtools/log4cplus/log4cplus_1.1.1.bb 
b/meta-oe/recipes-devtools/log4cplus/log4cplus_1.1.1.bb
new file mode 100644
index 000..e0ae1e6
--- /dev/null
+++ b/meta-oe/recipes-devtools/log4cplus/log4cplus_1.1.1.bb
@@ -0,0 +1,18 @@
+SUMMARY = log4cplus provides a simple C++ logging API for log management
+SECTION = libs
+HOMEPAGE = http://sourceforge.net/projects/log4cplus/;
+BUGTRACKER = http://sourceforge.net/p/log4cplus/bugs/;
+
+LICENSE = Apache-2.0
+LIC_FILES_CHKSUM = file://INSTALL;md5=fd3fffde3e364ca1fb46c81b741a766a
+
+PR = r0
+
+SRC_URI = 
${SOURCEFORGE_MIRROR}/project/log4cplus/log4cplus-stable/${PV}/log4cplus-${PV}.tar.gz
+
+SRC_URI[md5sum] = 104bd6dd07ee71bc52ee9adca4d4d5fc
+SRC_URI[sha256sum] = 
96905e763fc6f1e3a854c3d1964c21e877de909b0aed99806c62a68be838
+
+inherit autotools pkgconfig
+
+BBCLASSEXTEND += native
-- 
1.7.10.4

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [meta-oe][PATCH] python-docutils: upgrade to 0.11

2013-08-27 Thread Prica, Mihai
-Original Message-
From: openembedded-devel-boun...@lists.openembedded.org
Subject: Re: [oe] [meta-oe][PATCH] python-docutils: upgrade to 0.11

On Mon, Aug 26, 2013 at 04:54:47PM +0300, Mihai Prica wrote:
 Signed-off-by: Mihai Prica mihai.pr...@intel.com

What was changed in license file?

I took a closer look at the license file changes and it seems that some
files which are licensed BSD-2-Clause and GPLv3 have been added to the
package. I will send and updated patch. 


 ---
  ...hon-docutils_0.5.bb = python-docutils_0.11.bb} |7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)  rename
 meta-oe/recipes-devtools/python/{python-docutils_0.5.bb =
 python-docutils_0.11.bb} (55%)

 diff --git a/meta-oe/recipes-devtools/python/python-docutils_0.5.bb
 b/meta-oe/recipes-devtools/python/python-docutils_0.11.bb
 similarity index 55%
 rename from meta-oe/recipes-devtools/python/python-docutils_0.5.bb
 rename to meta-oe/recipes-devtools/python/python-docutils_0.11.bb
 index e4c8a7d..f435e1b 100644
 --- a/meta-oe/recipes-devtools/python/python-docutils_0.5.bb
 +++ b/meta-oe/recipes-devtools/python/python-docutils_0.11.bb
 @@ -2,14 +2,13 @@ DESCRIPTION = Text processing system
  HOMEPAGE = http://docutils.sourceforge.net;
  SECTION = devel/python
  LICENSE = PSF
 -LIC_FILES_CHKSUM =
file://COPYING.txt;md5=ac6ee29ac0310c091afab5ac4bea2fa3
 -PR = r2
 +LIC_FILES_CHKSUM =
file://COPYING.txt;md5=da0d261d1db78ab21ce86c79364a4098

  DEPENDS = python

  SRC_URI = ${SOURCEFORGE_MIRROR}/docutils/docutils-${PV}.tar.gz
 -SRC_URI[md5sum] = dd72dac92fc8e3eb0f48c3effeef80f6
 -SRC_URI[sha256sum] =
747cf984edfca0575addbb42453274a1bdd98ec7780bd37a883dc8b2a66a610e
 +SRC_URI[md5sum] = 20ac380a18b369824276864d98ec0ad6
 +SRC_URI[sha256sum] =
9af4166adf364447289c5c697bb83c52f1d6f57e77849abcccd6a4a18a5e7ec9

  S = ${WORKDIR}/docutils-${PV}

 --
 1.7.9.5

 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel

--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


[oe] [meta-oe][PATCH v2] python-docutils: upgrade to 0.11

2013-08-27 Thread Mihai Prica
Update LICENSE. The package contains files that are BSD-2-Clause or GPLv3.

Signed-off-by: Mihai Prica mihai.pr...@intel.com
---
 ...hon-docutils_0.5.bb = python-docutils_0.11.bb} |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)
 rename meta-oe/recipes-devtools/python/{python-docutils_0.5.bb = 
python-docutils_0.11.bb} (51%)

diff --git a/meta-oe/recipes-devtools/python/python-docutils_0.5.bb 
b/meta-oe/recipes-devtools/python/python-docutils_0.11.bb
similarity index 51%
rename from meta-oe/recipes-devtools/python/python-docutils_0.5.bb
rename to meta-oe/recipes-devtools/python/python-docutils_0.11.bb
index e4c8a7d..7987244 100644
--- a/meta-oe/recipes-devtools/python/python-docutils_0.5.bb
+++ b/meta-oe/recipes-devtools/python/python-docutils_0.11.bb
@@ -1,15 +1,14 @@
 DESCRIPTION = Text processing system
 HOMEPAGE = http://docutils.sourceforge.net;
 SECTION = devel/python
-LICENSE = PSF
-LIC_FILES_CHKSUM = file://COPYING.txt;md5=ac6ee29ac0310c091afab5ac4bea2fa3
-PR = r2
+LICENSE = PSF  BSD-2-Clause  GPLv3
+LIC_FILES_CHKSUM = file://COPYING.txt;md5=da0d261d1db78ab21ce86c79364a4098
 
 DEPENDS = python
 
 SRC_URI = ${SOURCEFORGE_MIRROR}/docutils/docutils-${PV}.tar.gz
-SRC_URI[md5sum] = dd72dac92fc8e3eb0f48c3effeef80f6
-SRC_URI[sha256sum] = 
747cf984edfca0575addbb42453274a1bdd98ec7780bd37a883dc8b2a66a610e
+SRC_URI[md5sum] = 20ac380a18b369824276864d98ec0ad6
+SRC_URI[sha256sum] = 
9af4166adf364447289c5c697bb83c52f1d6f57e77849abcccd6a4a18a5e7ec9
 
 S = ${WORKDIR}/docutils-${PV}
 
-- 
1.7.9.5

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] How can I make recipes conditionally enabled?

2013-08-27 Thread Erik Botö
Hi,

On Tue, Aug 27, 2013 at 9:54 AM, Martin Jansa martin.ja...@gmail.com wrote:
 On Tue, Aug 27, 2013 at 09:12:15AM +0200, Carlos Rafael Giani wrote:
 Hello,

 I have a question about a problem I've had several times in the past:

 if I write a layer, and add .bbappends, then the layers with the
 corresponding .bb files become hard dependencies.
 But lets say I want to write a BSP layer, and I add some machine
 specific Qt5 patches. Now everybody who wants to use
 my layer must also include meta-qt5, even when they don't really want to
 use Qt5 anywhere. This is made even worse
 if I have a dependency on meta-oe, which itself brings in a lot of
 modifications.

 In short, I'd like to be able to make .bbappends and .bb files dependend
 on whether or not a layer is available. The hard
 dependency is fine if it concerns things that are essential in my layer.
 But if its about optional things, it shouldn't cause
 a build failure.

 BB_DANGLINGAPPENDS_WARNONLY is the magic word.

I also saw some nice use of inspecting BBFILE_COLLECTIONS in the layer
configuration done by Mentor, see
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/conf/layer.conf#n9

Then you would place the files you only want to enable for e.g.
meta-qt5 in a qt5-layer directory in your layer. Those files would
then just be used if BBFILE_COLLECTIONS contains qt5-layer, which is
only the case if you have added meta-qt5.

I know meta-fsl-arm uses this for meta-qt5 bbappends.

Cheers,
Erik Botö


 --
 Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] How can I make recipes conditionally enabled?

2013-08-27 Thread Martin Jansa
On Tue, Aug 27, 2013 at 03:56:40PM +0200, Erik Botö wrote:
 Hi,
 
 On Tue, Aug 27, 2013 at 9:54 AM, Martin Jansa martin.ja...@gmail.com wrote:
  On Tue, Aug 27, 2013 at 09:12:15AM +0200, Carlos Rafael Giani wrote:
  Hello,
 
  I have a question about a problem I've had several times in the past:
 
  if I write a layer, and add .bbappends, then the layers with the
  corresponding .bb files become hard dependencies.
  But lets say I want to write a BSP layer, and I add some machine
  specific Qt5 patches. Now everybody who wants to use
  my layer must also include meta-qt5, even when they don't really want to
  use Qt5 anywhere. This is made even worse
  if I have a dependency on meta-oe, which itself brings in a lot of
  modifications.
 
  In short, I'd like to be able to make .bbappends and .bb files dependend
  on whether or not a layer is available. The hard
  dependency is fine if it concerns things that are essential in my layer.
  But if its about optional things, it shouldn't cause
  a build failure.
 
  BB_DANGLINGAPPENDS_WARNONLY is the magic word.
 
 I also saw some nice use of inspecting BBFILE_COLLECTIONS in the layer
 configuration done by Mentor, see
 http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/conf/layer.conf#n9
 
 Then you would place the files you only want to enable for e.g.
 meta-qt5 in a qt5-layer directory in your layer. Those files would
 then just be used if BBFILE_COLLECTIONS contains qt5-layer, which is
 only the case if you have added meta-qt5.
 
 I know meta-fsl-arm uses this for meta-qt5 bbappends.

Something similar was also used in meta-systemd layer (you need to check
older revision than 8b465f791a5ef3d9ef138a206c6fb9c3bbcb55b1)

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [meta-oe][PATCH ] libhugetlbfs: add recipe

2013-08-27 Thread Luo Zhenhua-B19537
Hi, 

libhugetlbfs should be moved to a common layer, since it can be used by other 
BSPs except linaro. 


Best Regards,

Zhenhua

 -Original Message-
 From: openembedded-devel-boun...@lists.openembedded.org
 [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
 Fathi Boudra
 Sent: Tuesday, August 27, 2013 4:00 PM
 To: openembedded-devel@lists.openembedded.org
 Subject: Re: [oe] [meta-oe][PATCH ] libhugetlbfs: add recipe
 
 Hi,
 
 please, check http://layers.openembedded.org/layerindex/recipe/5471/
 Could you integrate it into your work?
 
 On 27 August 2013 10:48,  b40...@freescale.com wrote:
  From: Chunrong Guo b40...@freescale.com
 
*libhugetlbfs is a library which provides easy access to huge pages
  of memory
 
  Signed-off-by: Chunrong Guo b40...@freescale.com
  ---
   ...ler-to-be-override-regardless-of-32-or-64.patch |   94
 ++
   ...rl-lib-to-directory-perl-instead-of-perl5.patch |   41 ++
   ...s-avoid-search-host-library-path-for-cros.patch |   70 +++
   .../files/0002-Fix-cross-compiling-on-PPC.patch|   39 ++
   ...fs-Remove-segment-based-alignment-restric.patch |  130
 
   ...-run_tests.py-fix-typo-in-test-invocation.patch |   29 +
   .../files/checks-if-mtab-is-a-symlink.patch|   30 +
   ...s-Fix-perl-lib-can-not-be-shiped-to-sub-p.patch |   34 +
   ...ng-LIB32-and-LIB64-if-they-point-to-the-s.patch |   47 +++
   ...Makefile-install-static-4G-edge-testcases.patch |   29 +
   .../libhugetlbfs/libhugetlbfs_git.bb   |   49 
   11 files changed, 592 insertions(+), 0 deletions(-)  create mode
  100644
  meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Allow-compiler-to-be
  -override-regardless-of-32-or-64.patch
   create mode 100644
  meta-oe/recipes-benchmark/libhugetlbfs/files/0001-install-perl-lib-to-
  directory-perl-instead-of-perl5.patch
   create mode 100644
  meta-oe/recipes-benchmark/libhugetlbfs/files/0001-libhugetlbfs-avoid-s
  earch-host-library-path-for-cros.patch
   create mode 100644
  meta-oe/recipes-benchmark/libhugetlbfs/files/0002-Fix-cross-compiling-
  on-PPC.patch  create mode 100644
  meta-oe/recipes-benchmark/libhugetlbfs/files/0003-libhugetlbfs-Remove-
  segment-based-alignment-restric.patch
   create mode 100644
  meta-oe/recipes-benchmark/libhugetlbfs/files/0004-tests-run_tests.py-f
  ix-typo-in-test-invocation.patch  create mode 100644
  meta-oe/recipes-benchmark/libhugetlbfs/files/checks-if-mtab-is-a-symli
  nk.patch  create mode 100644
  meta-oe/recipes-benchmark/libhugetlbfs/files/libhugetlbfs-Fix-perl-lib
  -can-not-be-shiped-to-sub-p.patch  create mode 100644
  meta-oe/recipes-benchmark/libhugetlbfs/files/skip-checking-LIB32-and-L
  IB64-if-they-point-to-the-s.patch  create mode 100644
  meta-oe/recipes-benchmark/libhugetlbfs/files/tests-Makefile-install-st
  atic-4G-edge-testcases.patch  create mode 100644
  meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
 
  diff --git
  a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Allow-compiler-to-
  be-override-regardless-of-32-or-64.patch
  b/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Allow-compiler-to-
  be-override-regardless-of-32-or-64.patch
  new file mode 100644
  index 000..ee9138b
  --- /dev/null
  +++ b/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Allow-compiler
  +++ -to-be-override-regardless-of-32-or-64.patch
  @@ -0,0 +1,94 @@
  +From efba2e8dae0d2140289acd7a7fcc0e30ff00d676 Mon Sep 17 00:00:00
  +2001
  +From: Chunrong Guo b40...@freescale.com
  +Date: Mon, 5 Aug 2013 21:36:57 -0500
  +Subject: [PATCH] Allow compiler to be override regardless of 32 or
  +64-bit build
  +
  +Provide an easy means for cross compiling to override the compiler
  +without having to know if we intend a 32-bit or 64-bit build.
  +
  +
  +Upstream-Status: Accepted
  +Signed-off-by: Kumar Gala ga...@kernel.crashing.org
  +Signed-off-by: Chunrong b40...@freescale.com
  +---
  + Makefile |   23 ---
  + 1 file changed, 12 insertions(+), 11 deletions(-)
  +
  +diff --git a/Makefile b/Makefile
  +index 48205af..878c71b 100644
  +--- a/Makefile
   b/Makefile
  +@@ -33,58 +33,59 @@ CFLAGS += -Wall -fPIC  CPPFLAGS +=
  +-D__LIBHUGETLBFS__
  +
  + ARCH = $(shell uname -m | sed -e s/i.86/i386/)
  ++CC = gcc
  +
  + CUSTOM_LDSCRIPTS = yes
  +
  + ifeq ($(ARCH),ppc64)
  +-CC64 = gcc -m64
  ++CC64 = $(CC) -m64
  + ELF64 = elf64ppc
  + TMPLIB64 = lib64
  + TMPLIB32 = lib
  + ifneq ($(BUILDTYPE),NATIVEONLY)
  +-CC32 = gcc -m32
  ++CC32 = $(CC) -m32
  + ELF32 = elf32ppclinux
  + endif
  + else
  + ifeq ($(ARCH),ppc)
  +-CC32 = gcc -m32
  ++CC32 = $(CC) -m32
  + ELF32 = elf32ppclinux
  + TMPLIB32 = lib
  + else
  + ifeq ($(ARCH),armv7l)
  +-CC32 = gcc
  ++CC32 = $(CC)
  + TMPLIB32 = lib
  + ELF32 += armelf_linux_eabi
  + CUSTOM_LDSCRIPTS = no
  + else
  + ifeq ($(ARCH),i386)
  +-CC32 = gcc
  ++CC32 = $(CC)
  + ELF32 = elf_i386
  + TMPLIB32 = lib
  + else
  + ifeq 

Re: [oe] [meta-oe][PATCH ] libhugetlbfs: add recipe

2013-08-27 Thread Fathi Boudra
Hi,

On 28 August 2013 05:56, Luo Zhenhua-B19537 b19...@freescale.com wrote:
 Hi,

 libhugetlbfs should be moved to a common layer, since it can be used by other 
 BSPs

agreed.

 except linaro.

what do you mean by except Linaro?

Cheers,
Fathi
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [meta-oe][PATCH ] libhugetlbfs: add recipe

2013-08-27 Thread Luo Zhenhua-B19537
 -Original Message-
 From: openembedded-devel-boun...@lists.openembedded.org
 [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
 Fathi Boudra
 
 On 28 August 2013 05:56, Luo Zhenhua-B19537 b19...@freescale.com wrote:
  Hi,
 
  libhugetlbfs should be moved to a common layer, since it can be used by
 other BSPs
 
 agreed.
 
  except linaro.
 
 what do you mean by except Linaro?
[Luo Zhenhua-B19537] I mean libhugetlbfs recipe is maintained in meta-linaro 
layer. 


Best Regards,

Zhenhua

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel


Re: [oe] [meta-oe][PATCH ] libhugetlbfs: add recipe

2013-08-27 Thread Fathi Boudra
On 28 August 2013 08:21, Luo Zhenhua-B19537 b19...@freescale.com wrote:
 -Original Message-
 From: openembedded-devel-boun...@lists.openembedded.org
 [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of
 Fathi Boudra

 On 28 August 2013 05:56, Luo Zhenhua-B19537 b19...@freescale.com wrote:
  Hi,
 
  libhugetlbfs should be moved to a common layer, since it can be used by
 other BSPs

 agreed.

  except linaro.

 what do you mean by except Linaro?
 [Luo Zhenhua-B19537] I mean libhugetlbfs recipe is maintained in meta-linaro 
 layer.

It make sense to get rid of if in meta-linaro and move libhugetlbfs in
a common layer where it can be used by everybody.
Now the question is who's doing this work? I suggested that you'll do
it since you've submitted libhugetlbfs inclusion.
However, if you don't want to do it, fair enough, I'll take a look to
make it generic and will propose patches.

Thought?

Cheers,
Fathi
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel