[oe] at91bootstrap and gcc 4.6+

2012-09-10 Thread Chris Verges 
Hi all,

For anyone doing development on the AT91-based platforms, there is a known
issue with at91bootstrap and gcc 4.6 (and later) where the
linker erroneously causes an overlap between sections.  There is a known
fix here, just needs to be turned into a patch file for OE:

http://www.at91.com/forum/viewtopic.php/f,12/t,20624/

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

Re: [oe] OpenEmbedded/Yocto Freescale ARM BSP Layer

2012-02-12 Thread Chris Verges 
On Sat, Feb 11, 2012 at 11:19 AM, Adrian Alonso aalons...@gmail.com wrote:

 *We are proud to announce the creation of a mailing list to easy the
 communication of people using Freescale’s ARM*


Hi Adrian,

As one of these users, thank you for helping to create a support structure
around OpenEmbedded and the Freescale portfolio!  I noticed that the i.MX51
is all that is in there right now.  Would this be an appropriate place for
the i.MX23 as well?  I wasn't sure if the scope was being limited or if
this was an artifact of the newness of the repository.

Again, many thanks!

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

Re: [oe] Documentation problems

2011-11-27 Thread Chris Verges 
On Sun, Nov 27, 2011 at 9:11 PM, Tom Rini tom.r...@gmail.com wrote:

 Does anyone reading this know people that _like_ editing wikis?  Can
 we ask them what keeps them engaged in the process?


Hi Tom,

This is an excellent discussion.  As someone interested in seeing some good
documentation come out of the OE project, consider that documentation is
really the way that users first interact with the software.  If the
documentation is poor, the user will more than likely seek another project.
 But if the documentation helps explain things well, the user will be able
to start interacting with the software and/or code more quickly.

Some consider a necessary evil, but I prefer to think of it as the
gateway to the product.  I actually do find documenting my designs and
code to be useful, as I find I can't keep track of as many things the older
I get.  :-)

On that note, as a user of OE for the past 5 years, I want to thank you ALL
for producing a great piece of software.  It's revolutionized how I start
embedded projects, and is one of those essential tools in my war chest.
 The classic docs were decent enough, but even as someone with 5 years of
OE experience, I'm having problems figuring out the new scheme fully.  I've
been waiting silently to read any docs that are produced, in fact.

I'm happy to help document, but obviously would need some knowledge
transfer to make that happen.  Catch-22, eh?

Thanks again,
Chris
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] tzdata moved to ICANN, URLs to update?

2011-10-17 Thread Chris Verges 
Hi all,

I just saw the posting that the tz database has been moved to ICANN
after the law suit issue occurred.  Do we need to update any recipes
or has this been handled already?

http://www.iana.org/time-zones

Thanks,
Chris

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

Re: [oe] [PATCH] ptpd: added recipe for v1.1.0.

2011-08-05 Thread Chris Verges 

 Why not jump to version 2.1.0 right away...


My project has a need for 1.1.0, so I bumped to that for now.  I also
haven't verified the build process to see if 2.x builds the same as 1.x.

Thanks,
Chris
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] [PATCH] ptpd: added recipe for v1.1.0.

2011-08-04 Thread Chris Verges 
Signed-off-by: Chris Verges kg4...@gmail.com
---
 meta-oe/recipes-connectivity/ptpd/ptpd_1.1.0.bb |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)
 create mode 100644 meta-oe/recipes-connectivity/ptpd/ptpd_1.1.0.bb

diff --git a/meta-oe/recipes-connectivity/ptpd/ptpd_1.1.0.bb 
b/meta-oe/recipes-connectivity/ptpd/ptpd_1.1.0.bb
new file mode 100644
index 000..87e0a69
--- /dev/null
+++ b/meta-oe/recipes-connectivity/ptpd/ptpd_1.1.0.bb
@@ -0,0 +1,19 @@
+DESCRIPTION = Precision Time Protocol (PTP) as defined by the IEEE 1588 
standard
+HOMEPAGE = http://sourceforge.net/projects/ptpd;
+LICENSE = BSD
+SECTION = network
+PR = r1
+
+SRC_URI = ${SOURCEFORGE_MIRROR}/project/ptpd/ptpd/${PV}/ptpd-${PV}.tar.gz 
+
+S = ${WORKDIR}/ptpd-${PV}/src
+
+do_install() {
+install -d ${D}${bindir} ${D}${mandir}/man8
+install -m 4555 ptpd ${D}${bindir}
+install -m 644 ptpd.8 ${D}${mandir}/man8
+}
+
+SRC_URI[md5sum] = faa4823576dd49ccc94b741ff32b03f5
+SRC_URI[sha256sum] = 
a7c6ea83bd53da75ae04a7b7a25fe7c597b4e9ff1f93d46f4502e3fa8a2cb950
+
-- 
1.7.4.1


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

Re: [oe] Kernel load address issue

2011-07-28 Thread Chris Verges 
Apologies for the top posting on this one ...

You can easily generate a zImage.  If you have devshell enabled, type
bitbake linux -c devshell and browse under arch/*/boot/... to find
your vmlinux image.

Try bootm 0x84A0.  This works on my system.

Chris

On Wed, Jul 27, 2011 at 12:22 PM, Bernard Mentink
bernard_ment...@trimble.com wrote:
 Hi Chris,

 Many thanks for that. However I only have a uImage in my build, no zImage so 
 can't do a diff to find the offset, is there another way to find that out?
 Maybe you or someone else knows what script in openembedded calls the mkimage 
 utility so I can find what parameters are passed ..

 By the way, I set UBOOT_LOADADDRESS and UBOOT_ENTRYPOINT to be the same 
 (0x8040, a bit past u-boot and the environment) in my config file, I am 
 not sure if the entry point should be the same as the load address.

 Cheers,
 Bernie

 --
 I want to die peacefully in my sleep, like my grandfather, not screaming and 
 yelling like the passengers in his car.

 -Original Message-
 From: openembedded-devel-boun...@lists.openembedded.org 
 [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of Chris 
 Verges
 Sent: Thursday, 28 July 2011 2:12 a.m.
 To: openembedded-devel@lists.openembedded.org
 Subject: Re: [oe] Kernel load address issue

 On Wed, Jul 27, 2011 at 06:00:07AM +, Mats Kärrman wrote:
 Starting kernel ...

 And there it hangs ... I don't know who printed out the Starting
 kernel was it uboot or the kernel?  If uboot, how do I pass kernel
 arguments (i.e the console serial params) with this method of booting?

 Hi Bernie,

 I've experienced this before when the UBOOT_LOADADDRESS and UBOOT_ENTRYPOINT 
 values in the machine config file for OpenEmbedded aren't properly set to the 
 correct value.  You may want to double check those values.

 Also, try setting your bootm address just a tag higher in memory than the 
 actual UBOOT_ENTRYPOINT.  I forgot what the exact uboot-mkimage header put on 
 the uImage is, but you can do a hex diff between the zImage and uImage files 
 to figure it out.  That offset can sometimes cause some odd booting problems.

 So if your ENTRYPOINT is 0x830 and the uboot-mkimage offset is 0xC0, for 
 example, you'd need to bootm 0x83000C0.  (Again, double check the 
 uboot-mkimage offset.)

 Good luck,
 Chris


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

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


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

Re: [oe] Kernel load address issue

2011-07-27 Thread Chris Verges 
On Wed, Jul 27, 2011 at 06:00:07AM +, Mats Kärrman wrote:
 Starting kernel ...
 
 And there it hangs ... I don't know who printed out the Starting
 kernel was it uboot or the kernel?  If uboot, how do I pass kernel
 arguments (i.e the console serial params) with this method of booting?

Hi Bernie,

I've experienced this before when the UBOOT_LOADADDRESS and
UBOOT_ENTRYPOINT values in the machine config file for OpenEmbedded
aren't properly set to the correct value.  You may want to double check
those values.

Also, try setting your bootm address just a tag higher in memory than
the actual UBOOT_ENTRYPOINT.  I forgot what the exact uboot-mkimage
header put on the uImage is, but you can do a hex diff between the
zImage and uImage files to figure it out.  That offset can sometimes
cause some odd booting problems.

So if your ENTRYPOINT is 0x830 and the uboot-mkimage offset is
0xC0, for example, you'd need to bootm 0x83000C0.  (Again, double check
the uboot-mkimage offset.)

Good luck,
Chris


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

Re: [oe] [PATCH] gcc: Package libstdc++ gdb python helpers into dev package

2011-07-23 Thread Chris Verges 
On Fri, Jul 22, 2011 at 1:21 PM, Khem Raj raj.k...@gmail.com wrote:
 On (22/07/11 13:24), Philip Balister wrote:
 On 06/09/2011 03:35 PM, Khem Raj wrote:
 People are seeing these errrors from ldconfig
 libstdc++.so.6.0.14-gdb.py is not an ELF file - it has the wrong magic
 bytes at the start.

 No more annoying message when I run ldconfig. Getting this fix in
 will reduce my support emails by a small, but noticeable amount.

 thanks for testing it out. I have installed in in oe.dev/master

Would it be worth a cherry-pick of this into 2011.03-maintenance?
I've been seeing it there with gcc 4.4.4, too, and have the same issue
with questions that pop up about it.

Thanks,
Chris

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

[oe] Problems accessing openembedded.org?

2011-07-18 Thread Chris Verges 
I'm having problems accessing openembedded.org, including both the web
page and GIT repository.  Anyone else seeing the same issue?

Thanks,
Chris

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

Re: [oe] Problems accessing openembedded.org?

2011-07-18 Thread Chris Verges 
On Mon, Jul 18, 2011 at 2:27 PM, George C. Huntington, III
george.huntington...@gmail.com wrote:
 I am having the same problem.

I just checked in on the IRC list.  Looks like melo is having some
hardware fits at the moment.  Sounds like they're working on it.

Chris

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

Re: [oe] bbappend

2011-07-12 Thread Chris Verges 
On Tue, Jul 12, 2011 at 10:42:53AM +0100, Paul Eggleton wrote:
 FILESEXTRAPATHS is only available in oe-core. For classic OE you need
 to use something like:
 
 THISDIR := ${@os.path.dirname(bb.data.getVar('FILE', d, True))}
 FILESPATHBASE_prepend := ${THISDIR}/files:

Hi Paul,

Thanks for clarifying and proposing a workaround.  It looks like PRINC
is similar, where it is only available in oe-core.  It seems like the
code related to incrementing the PR variable is a several-line fix, so
is this something that can be abstracted into a class file in the
local-overlay?

Thanks again,
Chris


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

Re: [oe] bbappend

2011-07-12 Thread Chris Verges 
On Tue, Jul 12, 2011 at 03:18:50PM +0100, Paul Eggleton wrote:
 Possibly, however as a general suggestion I would recommend moving
 things over to being based on oe-core if at all possible. I realise
 this is not going to be practical for everyone in the short term,
 however OE classic will stop being maintained at some point in the
 near future, so the sooner you move the better - plus you get to take
 advantage of the additional features and cleanups in oe-core as well.

I'd love to.  My most recent project is just starting out, so it's a
good time to make the switch.  Are there any good references for
performing a migration?

Thanks,
Chris


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

Re: [oe] Using ${DATE} in PR

2011-07-09 Thread Chris Verges 
Update on this ... it turns out that touching the recipe file (i.e.
updating the last accessed timestamp on the file) is what caused
things to rebuild.  Is there a way to tell bitbake to ignore caching a
recipe and/or always reevaluate the PR value in the recipe itself?

Thanks,
Chris

On Fri, Jul 8, 2011 at 7:55 AM, Chris Verges kg4...@gmail.com wrote:
 Using ${DATE} didn't work, but I was able to use a similar trick to
 get this working:

 BUILD_DATE ?= ${@time.strftime('%Y%m%d', time.gmtime())}
 PR = r5.${BUILD_DATE}.0

 Perhaps because ${DATE} in bitbake.conf is declared without the ${@
 tag this causes a more static interpretation of the variable?

 Hope this helps someone else in the future,
 Chris

 On Fri, Jul 8, 2011 at 7:21 AM, Chris Verges kg4...@gmail.com wrote:
 Hi all,

 I'm attempting to use the ${DATE} variable from
 openembedded/conf/bitbake.conf in the PR value of a local overlay
 recipe.  The idea is to create a recipe that will automatically
 rebuild each day.  (The recipe itself is creates a small text file in
 /etc that tracks the build date.)  BitBake is at 1.12.0, and OE is on
 2011.03-maintenance.

 Unfortunately, the following didn't work as I expected:

 PR = r5.${DATE}.0

 (I use the r5 prefix field to increment in case I make any major
 changes to the PR format, and the 0 suffix field to increment any
 minor changes to the recipe itself.)

 The expected behavior is that the recipe will automatically rebuild
 each day.  The actual behavior is that the recipe does not rebuild.

 Does anyone have any ideas on what I'm overlooking?

 Thanks,
 Chris



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

Re: [oe] Using ${DATE} in PR

2011-07-09 Thread Chris Verges 
On Sat, Jul 09, 2011 at 08:39:22AM -0700, Chris Verges wrote:
 On Fri, Jul 8, 2011 at 7:55 AM, Chris Verges kg4...@gmail.com wrote:
  Using ${DATE} didn't work, but I was able to use a similar trick to
  get this working:
 
  BUILD_DATE ?= ${@time.strftime('%Y%m%d', time.gmtime())}
  PR = r5.${BUILD_DATE}.0

 Update on this ... it turns out that touching the recipe file (i.e.
 updating the last accessed timestamp on the file) is what caused
 things to rebuild.  Is there a way to tell bitbake to ignore caching a
 recipe and/or always reevaluate the PR value in the recipe itself?

Hi list,

Apologies for the top posting before.  The only mail client I had
available was gmail's web interface, which isn't too netiquette
friendly.

I did some more digging into the BitBake sources.  I found the
__BB_DONT_CACHE variable declared in bitbake/lib/bb/cache.py, and have
set it to a value of 1 in the recipe that is using a dynamically
generated PR value.  I'll test tomorrow to see if it truly fixed things.

The recipe so far:

   # Prevent BitBake from caching this recipe
   __BB_DONT_CACHE = 1

   # The PR value is formatted as 'rX.DATE.Y' where 'X' is incremented
   # only if the PR format changes, 'DATE' is dynamically generated by
   # BitBake itself, and 'Y' should be incremented each time the recipe
   # is manually changed.
   PR = r3.${DATE}.7

Hope this helps anyone else looking to do tracking on nightly builds.

Chris

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

[oe] Using ${DATE} in PR

2011-07-08 Thread Chris Verges 
Hi all,

I'm attempting to use the ${DATE} variable from
openembedded/conf/bitbake.conf in the PR value of a local overlay
recipe.  The idea is to create a recipe that will automatically
rebuild each day.  (The recipe itself is creates a small text file in
/etc that tracks the build date.)  BitBake is at 1.12.0, and OE is on
2011.03-maintenance.

Unfortunately, the following didn't work as I expected:

PR = r5.${DATE}.0

(I use the r5 prefix field to increment in case I make any major
changes to the PR format, and the 0 suffix field to increment any
minor changes to the recipe itself.)

The expected behavior is that the recipe will automatically rebuild
each day.  The actual behavior is that the recipe does not rebuild.

Does anyone have any ideas on what I'm overlooking?

Thanks,
Chris

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

Re: [oe] Using ${DATE} in PR

2011-07-08 Thread Chris Verges 
Using ${DATE} didn't work, but I was able to use a similar trick to
get this working:

BUILD_DATE ?= ${@time.strftime('%Y%m%d', time.gmtime())}
PR = r5.${BUILD_DATE}.0

Perhaps because ${DATE} in bitbake.conf is declared without the ${@
tag this causes a more static interpretation of the variable?

Hope this helps someone else in the future,
Chris

On Fri, Jul 8, 2011 at 7:21 AM, Chris Verges kg4...@gmail.com wrote:
 Hi all,

 I'm attempting to use the ${DATE} variable from
 openembedded/conf/bitbake.conf in the PR value of a local overlay
 recipe.  The idea is to create a recipe that will automatically
 rebuild each day.  (The recipe itself is creates a small text file in
 /etc that tracks the build date.)  BitBake is at 1.12.0, and OE is on
 2011.03-maintenance.

 Unfortunately, the following didn't work as I expected:

 PR = r5.${DATE}.0

 (I use the r5 prefix field to increment in case I make any major
 changes to the PR format, and the 0 suffix field to increment any
 minor changes to the recipe itself.)

 The expected behavior is that the recipe will automatically rebuild
 each day.  The actual behavior is that the recipe does not rebuild.

 Does anyone have any ideas on what I'm overlooking?

 Thanks,
 Chris


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

Re: [oe] Cannot compile helloworld-image

2011-07-05 Thread Chris Verges 
Hi Alessandro,

This may be a silly question, but do you have all of the required
dependencies installed for your OS?  Looks like libtool isn't being
found.

http://wiki.openembedded.net/index.php/OEandYourDistro

Chris

On Tue, Jul 5, 2011 at 12:25 AM, Alessandro Sappia
a.sap...@biotechware.com wrote:

 --

 Alessandro Sappia
 CEO

 

 Biotechware srl
 C.so Castelfidardo, 30/A c/o I3P
 10129 Torino (TO) Italy
 Tel: +39 011 0903260
 Fax: +39 011 0905126
 http://www.biotechware.com/

 Il giorno lun, 04/07/2011 alle 22.05 +0200, Enrico ha scritto:

 On Mon, Jul 4, 2011 at 8:20 PM, Alessandro Sappia
 a.sap...@biotechware.com wrote:
  Hi all,
  I just configured OE on my box and I tried to compile helloworld-image
  to check if everything is fine.
  I'm actually unable to complete with success this build because of this
  error:
  -

 Try with:

 BB_NUMBER_THREADS = 1

 and have a look at the thread [oe] gettext-native fails to build of
 some days ago to know where i copied this hint from! (and maybe try
 oe-core branch too).


 [outout cut]
 m4
 -I 
 /home/alessandro/oe/build/tmp/work/x86_64-linux/gettext-native-0.18-r6/gettext-0.18/gettext-tools/m4
  -I 
 /home/alessandro/oe/build/tmp/sysroots/x86_64-linux/usr/share/aclocal-1.11 -I 
 /home/alessandro/oe/build/tmp/sysroots/x86_64-linux/usr/share/aclocal -I 
 /home/alessandro/oe/build/tmp/work/x86_64-linux/gettext-native-0.18-r6/gettext-0.18/gnulib-local/m4/
  -I 
 /home/alessandro/oe/build/tmp/work/x86_64-linux/gettext-native-0.18-r6/gettext-0.18/gettext-runtime/m4
  -I 
 /home/alessandro/oe/build/tmp/work/x86_64-linux/gettext-native-0.18-r6/gettext-0.18/gettext-tools/m4
  -I 
 /home/alessandro/oe/build/tmp/sysroots/x86_64-linux/usr/share/aclocal-1.11 -I 
 /home/alessandro/oe/build/tmp/sysroots/x86_64-linux/usr/share/aclocal --force 
 -I ../../m4 -I ../m4 -I gnulib-m4
 | autoreconf: running: libtoolize --copy --force
 | autoreconf: failed to run libtoolize: No such file or directory
 | autoreconf: libtoolize is needed because this package uses Libtool
 | + oefatal 'autoreconf execution failed.'
 | + echo FATAL: 'autoreconf execution failed.'
 | FATAL: autoreconf execution failed.
 | + exit 1
 NOTE: package gettext-native-0.18-r6: task do_configure: Failed
 ERROR: Task 435
 (virtual:native:/home/alessandro/oe/openembedded/recipes/gettext/gettext_0.18.bb,
  do_configure) failed with exit code '1'
 ERROR:
 'virtual:native:/home/alessandro/oe/openembedded/recipes/gettext/gettext_0.18.bb'
  failed


 It didn't work, but thanks.

 Ciao,

 Alessandro

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



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

[oe] [PATCH] libtinyxml: added recipe for v2.6.2

2011-06-17 Thread Chris Verges 
tinyxml is a small C++ library for parsing XML data on embedded
systems.  Currently, no recipe exists in OE for tinyxml, so this
patch attempts to rectify that.

Signed-off-by: Chris Verges kg4...@gmail.com
---
 recipes/libtinyxml/libtinyxml_2.6.2.bb |   37 
 1 files changed, 37 insertions(+), 0 deletions(-)
 create mode 100644 recipes/libtinyxml/libtinyxml_2.6.2.bb

diff --git a/recipes/libtinyxml/libtinyxml_2.6.2.bb 
b/recipes/libtinyxml/libtinyxml_2.6.2.bb
new file mode 100644
index 000..6693e5c
--- /dev/null
+++ b/recipes/libtinyxml/libtinyxml_2.6.2.bb
@@ -0,0 +1,37 @@
+DESCRIPTION = a simple, small, minimal, C++ XML parser
+HOMEPAGE = http://www.sourceforge.net/projects/tinyxml;
+LICENSE = zlib
+SECTION = libs
+
+PR = r3
+
+SRC_URI = ${SOURCEFORGE_MIRROR}/tinyxml/tinyxml_2_6_2.tar.gz
+
+S = ${WORKDIR}/tinyxml
+
+do_compile() {
+   ${CXX} ${CXXFLAGS} -I${S} -c -o ${S}/tinyxml.o ${S}/tinyxml.cpp
+   ${CXX} ${CXXFLAGS} -I${S} -c -o ${S}/tinyxmlerror.o 
${S}/tinyxmlerror.cpp
+   ${CXX} ${CXXFLAGS} -I${S} -c -o ${S}/tinyxmlparser.o 
${S}/tinyxmlparser.cpp
+   ${CXX} ${CXXFLAGS} \
+   -shared \
+   -Wl,-soname,libtinyxml.so.${PV} \
+   -o ${S}/libtinyxml.so.${PV} \
+   ${LDFLAGS} \
+   ${S}/tinyxml.o \
+   ${S}/tinyxmlparser.o \
+   ${S}/tinyxmlerror.o
+}
+
+do_install() {
+   install -d ${D}${libdir}
+   install -m 0755 ${S}/libtinyxml.so.${PV} ${D}${libdir}
+   ln -sf libtinyxml.so.${PV} ${D}${libdir}/libtinyxml.so
+
+   install -d ${D}${includedir}
+   install -m 0666 ${S}/tinyxml.h ${D}${includedir}
+}
+
+SRC_URI[md5sum] = c1b864c96804a10526540c664ade67f0
+SRC_URI[sha256sum] = 
15bdfdcec58a7da30adc87ac2b078e4417dbe5392f3afb719f9ba6d062645593
+
-- 
1.7.4.1


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

[oe] [PATCH] fakeroot-native: Move from not fetchable 1.9.6 to 1.15.1.

2011-06-05 Thread Chris Verges 
Fakeroot 1.9.6 was not fetchable anymore.  Updating fakeroot-native to 1.15.1.

Signed-off-by: Chris Verges kg4...@gmail.com
---
 conf/distro/chinook-compat.conf|2 +-
 conf/distro/maemo5-compat.conf |2 +-
 .../fakeroot-1.9.6/configure-libtool.patch |   18 -
 recipes/fakeroot/fakeroot-1.9.6/fix-prefix.patch   |   18 -
 recipes/fakeroot/fakeroot-native_1.15.1.bb |   21 
 recipes/fakeroot/fakeroot-native_1.9.6.bb  |   21 
 recipes/fakeroot/fakeroot_1.9.6.bb |   21 
 7 files changed, 23 insertions(+), 80 deletions(-)
 delete mode 100644 recipes/fakeroot/fakeroot-1.9.6/configure-libtool.patch
 delete mode 100644 recipes/fakeroot/fakeroot-1.9.6/fix-prefix.patch
 create mode 100644 recipes/fakeroot/fakeroot-native_1.15.1.bb
 delete mode 100644 recipes/fakeroot/fakeroot-native_1.9.6.bb
 delete mode 100644 recipes/fakeroot/fakeroot_1.9.6.bb

diff --git a/conf/distro/chinook-compat.conf b/conf/distro/chinook-compat.conf
index e9e2e1a..be2d579 100644
--- a/conf/distro/chinook-compat.conf
+++ b/conf/distro/chinook-compat.conf
@@ -198,7 +198,7 @@ PREFERRED_PROVIDER_swt3.4-gtk = swt3.4-gtk-hildon
 PREFERRED_VERSION_swt3.4-gtk-hildon = 3.4
 
 # Does not build with later versions
-PREFERRED_VERSION_fakeroot-native = 1.9.6
+PREFERRED_VERSION_fakeroot-native = 1.15.1
 
 # newer Versions needs newer autotools we cant relay on
 PREFERRED_VERSION_guile-native = 1.8.2
diff --git a/conf/distro/maemo5-compat.conf b/conf/distro/maemo5-compat.conf
index c1f0e4b..30327fc 100644
--- a/conf/distro/maemo5-compat.conf
+++ b/conf/distro/maemo5-compat.conf
@@ -184,7 +184,7 @@ PREFERRED_PROVIDER_swt3.4-gtk = swt3.4-gtk-hildon
 PREFERRED_VERSION_swt3.4-gtk-hildon = 3.4
 
 # Does not build with later versions
-PREFERRED_VERSION_fakeroot-native = 1.9.6
+PREFERRED_VERSION_fakeroot-native = 1.15.1
 
 # newer Versions needs newer autotools we cant relay on
 PREFERRED_VERSION_guile-native = 1.8.2
diff --git a/recipes/fakeroot/fakeroot-1.9.6/configure-libtool.patch 
b/recipes/fakeroot/fakeroot-1.9.6/configure-libtool.patch
deleted file mode 100644
index 8830328..000
--- a/recipes/fakeroot/fakeroot-1.9.6/configure-libtool.patch
+++ /dev/null
@@ -1,18 +0,0 @@
 fakeroot-1.8.3/configure.ac.orig   2007-10-31 00:17:27.0 -0500
-+++ fakeroot-1.8.3/configure.ac2007-10-31 00:18:12.0 -0500
-@@ -1,14 +1,12 @@
- dnl Process this file with autoconf to produce a configure script.
- AC_INIT([fakeroot],[FAKEROOT_VERSION],[sch...@debian.org],[fakeroot])
- AC_PREREQ(2.61)
--LT_PREREQ(2.1a)
- AC_CANONICAL_TARGET
- AM_INIT_AUTOMAKE
- AM_MAINTAINER_MODE
- AC_CONFIG_HEADERS([config.h])
- AC_PROG_MAKE_SET
--LT_INIT
--LT_LANG(C)
-+AC_PROG_LIBTOOL
- 
- AC_ARG_WITH([ipc],
-   AS_HELP_STRING([--with-ipc@:@=IPCTYPE@:@],
diff --git a/recipes/fakeroot/fakeroot-1.9.6/fix-prefix.patch 
b/recipes/fakeroot/fakeroot-1.9.6/fix-prefix.patch
deleted file mode 100644
index 3884aca..000
--- a/recipes/fakeroot/fakeroot-1.9.6/fix-prefix.patch
+++ /dev/null
@@ -1,18 +0,0 @@
-
-#
-# Patch managed by http://www.holgerschurig.de/patcher.html
-#
-
 fakeroot-1.2.13/scripts/fakeroot.in~fix-prefix
-+++ fakeroot-1.2.13/scripts/fakeroot.in
-@@ -15,8 +15,8 @@
- }
- 
- # strip /bin/fakeroot to find install prefix
--PREFIX=@prefix@
--BINDIR=@bindir@
-+BINDIR=`dirname $0`
-+PREFIX=`dirname ${BINDIR}`
- 
- LIB=lib@fakeroot_transformed@.so.0
- PATHS=@libdir@:${PREFIX}/lib64/libfakeroot:${PREFIX}/lib32/libfakeroot
diff --git a/recipes/fakeroot/fakeroot-native_1.15.1.bb 
b/recipes/fakeroot/fakeroot-native_1.15.1.bb
new file mode 100644
index 000..8fb8bce
--- /dev/null
+++ b/recipes/fakeroot/fakeroot-native_1.15.1.bb
@@ -0,0 +1,21 @@
+require fakeroot_${PV}.bb
+
+RDEPENDS_${PN} = util-linux-native
+
+SRC_URI += file://fix-prefix.patch 
+S = ${WORKDIR}/fakeroot-${PV}
+
+inherit native
+
+EXTRA_OECONF =  --program-prefix=
+
+# Compatability for the rare systems not using or having SYSV
+python () {
+if bb.data.getVar('HOST_NONSYSV', d, True) and 
bb.data.getVar('HOST_NONSYSV', d, True) != '0':
+bb.data.setVar('EXTRA_OECONF', ' --with-ipc=tcp --program-prefix= ', d)
+}
+
+do_stage_append () {
+oe_libinstall -so libfakeroot ${STAGING_LIBDIR}/libfakeroot/
+}
+
diff --git a/recipes/fakeroot/fakeroot-native_1.9.6.bb 
b/recipes/fakeroot/fakeroot-native_1.9.6.bb
deleted file mode 100644
index 8fb8bce..000
--- a/recipes/fakeroot/fakeroot-native_1.9.6.bb
+++ /dev/null
@@ -1,21 +0,0 @@
-require fakeroot_${PV}.bb
-
-RDEPENDS_${PN} = util-linux-native
-
-SRC_URI += file://fix-prefix.patch 
-S = ${WORKDIR}/fakeroot-${PV}
-
-inherit native
-
-EXTRA_OECONF =  --program-prefix=
-
-# Compatability for the rare systems not using or having SYSV
-python () {
-if bb.data.getVar('HOST_NONSYSV', d, True) and 
bb.data.getVar('HOST_NONSYSV', d, True) != '0