[oe] libxcursor-1.1.12.bbappend

[j]

I just updated hoping it would help with another build issue I am having 
and after the update I can no longer build anything I always get the error.

ERROR: No recipes available for:
  
/home/beagle/OE/setup-scripts/sources/meta-openembedded/meta-oe/recipes-graphics/xorg-lib/libxcursor_1.1.12.bbappend

ERROR: Command execution failed: Exited with 1

Anyone know how to fix this? The append is there but the recipe it is 
appending is not. Either that or I can not find it. I only see 1.1.13.bb 
but not the 1.1.12.bb and both appends are there.


Thanks.

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

Re: [oe] libxcursor-1.1.12.bbappend

[j]

On 04/13/2012 10:23 AM, j wrote:
I just updated hoping it would help with another build issue I am 
having and after the update I can no longer build anything I always 
get the error.

ERROR: No recipes available for:
  
/home/beagle/OE/setup-scripts/sources/meta-openembedded/meta-oe/recipes-graphics/xorg-lib/libxcursor_1.1.12.bbappend

ERROR: Command execution failed: Exited with 1

Anyone know how to fix this? The append is there but the recipe it is 
appending is not. Either that or I can not find it. I only see 
1.1.13.bb but not the 1.1.12.bb and both appends are there.


Thanks.
Just moving the file from the tree made builds continue. Was this recipe 
something that should have been deleted but was missed?


Thanks

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

[oe] ld segfault cant figure it out

[j]

There seems to be a couple of packages when I build that cause ld 
segfaults such as
[ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c error 4 
in libc-2.13.so[73d000+15c000]
[ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc error 4 
in libc-2.13.so[b64000+15c000]


I can not seem to be able to track down the package/packages that are 
causing this. I have tried with a clean build dir and only building nano 
and I get it so it is something in the getting environment ready steps. 
Is there a way I can easily track down the build/builds that are causing 
this? Am I even on the right track in this thinking? Nothing fails to 
build and other than task-native-sdk all result in what seem to be 
working packages.


Any info on what or how to figure it out would be greatly appreciated.
building for bbxm on 11.04(uptodate), build environment setup with 
Angstrom scripts and all is up to date.


Thank you

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

Re: [oe] ld segfault cant figure it out

[j]

On 04/13/2012 03:46 PM, j wrote:
There seems to be a couple of packages when I build that cause ld 
segfaults such as
[ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c error 
4 in libc-2.13.so[73d000+15c000]
[ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc error 
4 in libc-2.13.so[b64000+15c000]


I can not seem to be able to track down the package/packages that are 
causing this. I have tried with a clean build dir and only building 
nano and I get it so it is something in the getting environment ready 
steps. Is there a way I can easily track down the build/builds that 
are causing this? Am I even on the right track in this thinking? 
Nothing fails to build and other than task-native-sdk all result in 
what seem to be working packages.


Any info on what or how to figure it out would be greatly appreciated.
building for bbxm on 11.04(uptodate), build environment setup with 
Angstrom scripts and all is up to date.


Thank you

Sorry forgot the info from qa.log

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path 
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a'
libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path 
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a'
libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path 
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a'
bash-4.2: bash: Found a reference to /usr/ in 
/home/beagle/OE/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug
bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix


Any other places to check, as these I do not think relate to a segfault?

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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/13/2012 03:50 PM, j wrote:

On 04/13/2012 03:46 PM, j wrote:
There seems to be a couple of packages when I build that cause ld 
segfaults such as
[ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c error 
4 in libc-2.13.so[73d000+15c000]
[ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc error 
4 in libc-2.13.so[b64000+15c000]


I can not seem to be able to track down the package/packages that are 
causing this. I have tried with a clean build dir and only building 
nano and I get it so it is something in the getting environment ready 
steps. Is there a way I can easily track down the build/builds that 
are causing this? Am I even on the right track in this thinking? 
Nothing fails to build and other than task-native-sdk all result in 
what seem to be working packages.


Any info on what or how to figure it out would be greatly appreciated.
building for bbxm on 11.04(uptodate), build environment setup with 
Angstrom scripts and all is up to date.


Thank you

Sorry forgot the info from qa.log

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path 
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a'
libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path 
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a'
libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path 
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a'
bash-4.2: bash: Found a reference to /usr/ in 
/home/beagle/OE/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug
bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix


Any other places to check, as these I do not think relate to a segfault?


I have now tried the build on 3 different OS's the most recent being 
Arch. All give the same QA log's and all give me segfaults. That are all 
basically close to the same errors just differing libc versions.


I have tried Ubuntu 10.04 11.04 Fedora 16 and now Arch. What is causing 
the segfaults? Is it what is in the QA log?




Most current
[ 6433.379801] ld[22955]: segfault at 403 ip 7f703ddcc435 sp 
7fffb0bd9f50 error 4 in libc-2.15.so[7f703dd85000+197000]
[ 6444.526227] ld[31806]: segfault at 403 ip 7f0dffc51435 sp 
7fffc0a990d0 error 4 in libc-2.15.so[7f0dffc0a000+197000]


libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path 
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a'
libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path 
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a'
libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path 
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a'
bash-4.2: bash: Found a reference to /usr/ in 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug
bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix



The only reason I am concerned with this and it may be un related is 
that every time I build task-native-sdk it does not build a working sdk 
for my device. BB-xm. Yes I know I can install one from the repo, but I 
want to figure out what is wrong with building one for me.


Does anyone have input, advice something?

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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/16/2012 03:28 PM, Gary Thomas wrote:

On 2012-04-16 16:11, j wrote:

On 04/13/2012 03:50 PM, j wrote:

On 04/13/2012 03:46 PM, j wrote:
There seems to be a couple of packages when I build that cause ld 
segfaults such as
[ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c 
error 4 in libc-2.13.so[73d000+15c000]
[ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc 
error 4 in libc-2.13.so[b64000+15c000]


I can not seem to be able to track down the package/packages that 
are causing this. I have tried with a clean build dir and only 
building nano and I get it so it is something in
the getting environment ready steps. Is there a way I can easily 
track down the build/builds that are causing this? Am I even on the 
right track in this thinking? Nothing fails
to build and other than task-native-sdk all result in what seem to 
be working packages.


Any info on what or how to figure it out would be greatly appreciated.
building for bbxm on 11.04(uptodate), build environment setup with 
Angstrom scripts and all is up to date.


Thank you

Sorry forgot the info from qa.log

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a' 


bash-4.2: bash: Found a reference to /usr/ in
/home/beagle/OE/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug 

bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix


Any other places to check, as these I do not think relate to a 
segfault?


I have now tried the build on 3 different OS's the most recent being 
Arch. All give the same QA log's and all give me segfaults. That are 
all basically close to the same errors

just differing libc versions.

I have tried Ubuntu 10.04 11.04 Fedora 16 and now Arch. What is 
causing the segfaults? Is it what is in the QA log?




Most current
[ 6433.379801] ld[22955]: segfault at 403 ip 7f703ddcc435 sp 
7fffb0bd9f50 error 4 in libc-2.15.so[7f703dd85000+197000]
[ 6444.526227] ld[31806]: segfault at 403 ip 7f0dffc51435 sp 
7fffc0a990d0 error 4 in libc-2.15.so[7f0dffc0a000+197000]


libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a' 


bash-4.2: bash: Found a reference to /usr/ in
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug 

bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix



The only reason I am concerned with this and it may be un related is 
that every time I build task-native-sdk it does not build a working 
sdk for my device. BB-xm. Yes I know I can
install one from the repo, but I want to figure out what is wrong 
with building one for me.


Does anyone have input, advice something?


You've tried different Operating Systems, but one would assume that
this is all on the same hardware?   Have you tried a different build
host (i.e. hardware/box)?

sadly the only other hardware I have is to old to try a build on. Would 
take me weeks to get a complete image.


So this could be a hardware problem on my end? If so any chance you know 
what I could search for in logs or anything like that to try and track 
down what on the hardware side is causing it?


Thanks a bunch for your reply though is not something I took in to 
account, reason being is I can build the gumstix overo chain (oe-classic 
I believe it is) on the same hardware with out running into this issue.


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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/16/2012 03:28 PM, Gary Thomas wrote:

On 2012-04-16 16:11, j wrote:

On 04/13/2012 03:50 PM, j wrote:

On 04/13/2012 03:46 PM, j wrote:
There seems to be a couple of packages when I build that cause ld 
segfaults such as
[ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c 
error 4 in libc-2.13.so[73d000+15c000]
[ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc 
error 4 in libc-2.13.so[b64000+15c000]


I can not seem to be able to track down the package/packages that 
are causing this. I have tried with a clean build dir and only 
building nano and I get it so it is something in
the getting environment ready steps. Is there a way I can easily 
track down the build/builds that are causing this? Am I even on the 
right track in this thinking? Nothing fails
to build and other than task-native-sdk all result in what seem to 
be working packages.


Any info on what or how to figure it out would be greatly appreciated.
building for bbxm on 11.04(uptodate), build environment setup with 
Angstrom scripts and all is up to date.


Thank you

Sorry forgot the info from qa.log

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a' 


bash-4.2: bash: Found a reference to /usr/ in
/home/beagle/OE/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug 

bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix


Any other places to check, as these I do not think relate to a 
segfault?


I have now tried the build on 3 different OS's the most recent being 
Arch. All give the same QA log's and all give me segfaults. That are 
all basically close to the same errors

just differing libc versions.

I have tried Ubuntu 10.04 11.04 Fedora 16 and now Arch. What is 
causing the segfaults? Is it what is in the QA log?




Most current
[ 6433.379801] ld[22955]: segfault at 403 ip 7f703ddcc435 sp 
7fffb0bd9f50 error 4 in libc-2.15.so[7f703dd85000+197000]
[ 6444.526227] ld[31806]: segfault at 403 ip 7f0dffc51435 sp 
7fffc0a990d0 error 4 in libc-2.15.so[7f0dffc0a000+197000]


libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a' 


bash-4.2: bash: Found a reference to /usr/ in
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug 

bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix



The only reason I am concerned with this and it may be un related is 
that every time I build task-native-sdk it does not build a working 
sdk for my device. BB-xm. Yes I know I can
install one from the repo, but I want to figure out what is wrong 
with building one for me.


Does anyone have input, advice something?


You've tried different Operating Systems, but one would assume that
this is all on the same hardware?   Have you tried a different build
host (i.e. hardware/box)?

Also it seems to happen around when bitbake starts building gcc-4.5 from 
a fresh install that is why I posted the QA info about it.


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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/16/2012 03:41 PM, Gary Thomas wrote:

On 2012-04-16 16:32, j wrote:

On 04/16/2012 03:28 PM, Gary Thomas wrote:

On 2012-04-16 16:11, j wrote:

On 04/13/2012 03:50 PM, j wrote:

On 04/13/2012 03:46 PM, j wrote:
There seems to be a couple of packages when I build that cause ld 
segfaults such as
[ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c 
error 4 in libc-2.13.so[73d000+15c000]
[ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc 
error 4 in libc-2.13.so[b64000+15c000]


I can not seem to be able to track down the package/packages that 
are causing this. I have tried with a clean build dir and only 
building nano and I get it so it is something in
the getting environment ready steps. Is there a way I can easily 
track down the build/builds that are causing this? Am I even on 
the right track in this thinking? Nothing fails
to build and other than task-native-sdk all result in what seem 
to be working packages.


Any info on what or how to figure it out would be greatly 
appreciated.
building for bbxm on 11.04(uptodate), build environment setup 
with Angstrom scripts and all is up to date.


Thank you

Sorry forgot the info from qa.log

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a' 


bash-4.2: bash: Found a reference to /usr/ in
/home/beagle/OE/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug 

bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix


Any other places to check, as these I do not think relate to a 
segfault?


I have now tried the build on 3 different OS's the most recent 
being Arch. All give the same QA log's and all give me segfaults. 
That are all basically close to the same errors

just differing libc versions.

I have tried Ubuntu 10.04 11.04 Fedora 16 and now Arch. What is 
causing the segfaults? Is it what is in the QA log?




Most current
[ 6433.379801] ld[22955]: segfault at 403 ip 7f703ddcc435 sp 
7fffb0bd9f50 error 4 in libc-2.15.so[7f703dd85000+197000]
[ 6444.526227] ld[31806]: segfault at 403 ip 7f0dffc51435 sp 
7fffc0a990d0 error 4 in libc-2.15.so[7f0dffc0a000+197000]


libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a' 


bash-4.2: bash: Found a reference to /usr/ in
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug 

bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix



The only reason I am concerned with this and it may be un related 
is that every time I build task-native-sdk it does not build a 
working sdk for my device. BB-xm. Yes I know I can
install one from the repo, but I want to figure out what is wrong 
with building one for me.


Does anyone have input, advice something?


You've tried different Operating Systems, but one would assume that
this is all on the same hardware? Have you tried a different build
host (i.e. hardware/box)?

sadly the only other hardware I have is to old to try a build on. 
Would take me weeks to get a complete image.


So this could be a hardware problem on my end? If so any chance you 
know what I could search for in logs or anything like that to try and 
track down what on the hardware side is

causing it?


Random errors like this always make me question the hardware.  The 
fact that it
can work fine in one setup but not another reinforces that.  It might 
not be the

case, but I think you'll have to check it out.



Thanks a bunch for your reply though is not something I took in to 
account, reason being is I can 

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/16/2012 03:34 PM, j wrote:

On 04/16/2012 03:28 PM, Gary Thomas wrote:

On 2012-04-16 16:11, j wrote:

On 04/13/2012 03:50 PM, j wrote:

On 04/13/2012 03:46 PM, j wrote:
There seems to be a couple of packages when I build that cause ld 
segfaults such as
[ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c 
error 4 in libc-2.13.so[73d000+15c000]
[ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc 
error 4 in libc-2.13.so[b64000+15c000]


I can not seem to be able to track down the package/packages that 
are causing this. I have tried with a clean build dir and only 
building nano and I get it so it is something in
the getting environment ready steps. Is there a way I can easily 
track down the build/builds that are causing this? Am I even on 
the right track in this thinking? Nothing fails
to build and other than task-native-sdk all result in what seem to 
be working packages.


Any info on what or how to figure it out would be greatly 
appreciated.
building for bbxm on 11.04(uptodate), build environment setup with 
Angstrom scripts and all is up to date.


Thank you

Sorry forgot the info from qa.log

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a' 


bash-4.2: bash: Found a reference to /usr/ in
/home/beagle/OE/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug 

bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix


Any other places to check, as these I do not think relate to a 
segfault?


I have now tried the build on 3 different OS's the most recent being 
Arch. All give the same QA log's and all give me segfaults. That are 
all basically close to the same errors

just differing libc versions.

I have tried Ubuntu 10.04 11.04 Fedora 16 and now Arch. What is 
causing the segfaults? Is it what is in the QA log?




Most current
[ 6433.379801] ld[22955]: segfault at 403 ip 7f703ddcc435 sp 
7fffb0bd9f50 error 4 in libc-2.15.so[7f703dd85000+197000]
[ 6444.526227] ld[31806]: segfault at 403 ip 7f0dffc51435 sp 
7fffc0a990d0 error 4 in libc-2.15.so[7f0dffc0a000+197000]


libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a' 

libgcc-4.5: non -staticdev package contains static .a library: 
libgcc-dev path
'/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r48+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a' 


bash-4.2: bash: Found a reference to /usr/ in
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/bash-4.2-r2/packages-split/bash/bin/bashbug 

bash-4.2: Shell scripts in base_bindir and base_sbindir should not 
reference anything in exec_prefix



The only reason I am concerned with this and it may be un related is 
that every time I build task-native-sdk it does not build a working 
sdk for my device. BB-xm. Yes I know I can
install one from the repo, but I want to figure out what is wrong 
with building one for me.


Does anyone have input, advice something?


You've tried different Operating Systems, but one would assume that
this is all on the same hardware?   Have you tried a different build
host (i.e. hardware/box)?

Also it seems to happen around when bitbake starts building gcc-4.5 
from a fresh install that is why I posted the QA info about it.


Well just built systemd-image got some more info from the QA log. seems 
that during the initial build with GCC and libtool it throws the 
segfaults. Then as the rest of build goes others have issues.


I am going to try and rebuild the packages I think are causing this step 
by step and see if something sticks out during the process that might 
lead to a way to sort out the issue. I will start on a fresh boot of the 
system as well to make sure I can catch all the variables hopefully that 
are causing it. I also noticed so

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 09:13 AM, J. L. wrote:





<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel>



I went for a build on the borrowed machine again but this time I did not 
go into X just stayed in RL3. Then ran bitbake perl, on a clean build 
dir. It is just about to finish building a few steps away but where I 
normally get the segfaults, it has not spit those out. There are no QA 
logs being generated either. So looks like it had/has something to do 
with running X, both systems are running nvidia graphics cards. The 
laptop has a new mobile one, borrowed an old one that is nouveau 
compatible. So both open and closed nvidia drivers were tried. But 
something when in the graphical environment is giving the segfault 
issues I have been seeing. I have not yet verified if killing X on the 
laptop builds and eliminates the issues as well.


Will post back once I have built the kernel on both machines with no X 
running.


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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 12:34 PM, Mark Hatle wrote:

On 4/17/12 2:09 PM, j wrote:

On 04/17/2012 09:13 AM, J. L. wrote:




<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel>




I went for a build on the borrowed machine again but this time I did not
go into X just stayed in RL3. Then ran bitbake perl, on a clean build
dir. It is just about to finish building a few steps away but where I
normally get the segfaults, it has not spit those out. There are no QA
logs being generated either. So looks like it had/has something to do
with running X, both systems are running nvidia graphics cards. The
laptop has a new mobile one, borrowed an old one that is nouveau
compatible. So both open and closed nvidia drivers were tried. But
something when in the graphical environment is giving the segfault
issues I have been seeing. I have not yet verified if killing X on the
laptop builds and eliminates the issues as well.

Will post back once I have built the kernel on both machines with no X
running.


There is a known issue w/ nvidia drivers, segfaulting and QEMU.  Is 
something in perl (or elsewhere) trying to run qemu to finish up a task?


--Mark
Not that I can tell, but that does not mean it is not (still learning 
things), but possible one of threads is working on something perl 
related when it happens and I am not seeing it or realizing it. If you 
are willing to post the commands I could run to check, I can post the 
results. But when I do just a bitbake -c compile perl on a clean build 
dir all I would see was the segfault in dmesg and the results in QA log. 
Nothing would show up on the command line that was not in the QA log, 
after doing each step one by one.


But it must be related to this known issue with nvidia. Should be a 
couple hours before both machines finish building the kernel and perl, 
will post the results after. But looks promising for my laptop so far as 
no segfaults yet. Borrowed machine is on to building the kernel now and 
nothing posted yet.


Thank you for your response very appreciated. I will also read more 
about the issue you stated.




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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 12:49 PM, j wrote:

On 04/17/2012 12:34 PM, Mark Hatle wrote:

On 4/17/12 2:09 PM, j wrote:

On 04/17/2012 09:13 AM, J. L. wrote:




<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel> 





I went for a build on the borrowed machine again but this time I did 
not

go into X just stayed in RL3. Then ran bitbake perl, on a clean build
dir. It is just about to finish building a few steps away but where I
normally get the segfaults, it has not spit those out. There are no QA
logs being generated either. So looks like it had/has something to do
with running X, both systems are running nvidia graphics cards. The
laptop has a new mobile one, borrowed an old one that is nouveau
compatible. So both open and closed nvidia drivers were tried. But
something when in the graphical environment is giving the segfault
issues I have been seeing. I have not yet verified if killing X on the
laptop builds and eliminates the issues as well.

Will post back once I have built the kernel on both machines with no X
running.


There is a known issue w/ nvidia drivers, segfaulting and QEMU.  Is 
something in perl (or elsewhere) trying to run qemu to finish up a task?


--Mark
Not that I can tell, but that does not mean it is not (still learning 
things), but possible one of threads is working on something perl 
related when it happens and I am not seeing it or realizing it. If you 
are willing to post the commands I could run to check, I can post the 
results. But when I do just a bitbake -c compile perl on a clean build 
dir all I would see was the segfault in dmesg and the results in QA 
log. Nothing would show up on the command line that was not in the QA 
log, after doing each step one by one.


But it must be related to this known issue with nvidia. Should be a 
couple hours before both machines finish building the kernel and perl, 
will post the results after. But looks promising for my laptop so far 
as no segfaults yet. Borrowed machine is on to building the kernel now 
and nothing posted yet.


Thank you for your response very appreciated. I will also read more 
about the issue you stated.



From what I am reading about this is its related to libgl. But on the 
machine I borrowed I used nouveau driver's which uses the libgl that is 
expected not the nvidia's supplied version. So maybe that is not fully 
it. But still all seems related to being in an X environment for me when 
building. Which is at least easy to work around.


Will post if it segfaults again on either machine once they are done.

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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 01:17 PM, j wrote:

On 04/17/2012 12:49 PM, j wrote:

On 04/17/2012 12:34 PM, Mark Hatle wrote:

On 4/17/12 2:09 PM, j wrote:

On 04/17/2012 09:13 AM, J. L. wrote:




<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel> 





I went for a build on the borrowed machine again but this time I 
did not

go into X just stayed in RL3. Then ran bitbake perl, on a clean build
dir. It is just about to finish building a few steps away but where I
normally get the segfaults, it has not spit those out. There are no QA
logs being generated either. So looks like it had/has something to do
with running X, both systems are running nvidia graphics cards. The
laptop has a new mobile one, borrowed an old one that is nouveau
compatible. So both open and closed nvidia drivers were tried. But
something when in the graphical environment is giving the segfault
issues I have been seeing. I have not yet verified if killing X on the
laptop builds and eliminates the issues as well.

Will post back once I have built the kernel on both machines with no X
running.


There is a known issue w/ nvidia drivers, segfaulting and QEMU.  Is 
something in perl (or elsewhere) trying to run qemu to finish up a 
task?


--Mark
Not that I can tell, but that does not mean it is not (still learning 
things), but possible one of threads is working on something perl 
related when it happens and I am not seeing it or realizing it. If 
you are willing to post the commands I could run to check, I can post 
the results. But when I do just a bitbake -c compile perl on a clean 
build dir all I would see was the segfault in dmesg and the results 
in QA log. Nothing would show up on the command line that was not in 
the QA log, after doing each step one by one.


But it must be related to this known issue with nvidia. Should be a 
couple hours before both machines finish building the kernel and 
perl, will post the results after. But looks promising for my laptop 
so far as no segfaults yet. Borrowed machine is on to building the 
kernel now and nothing posted yet.


Thank you for your response very appreciated. I will also read more 
about the issue you stated.



From what I am reading about this is its related to libgl. But on the 
machine I borrowed I used nouveau driver's which uses the libgl that 
is expected not the nvidia's supplied version. So maybe that is not 
fully it. But still all seems related to being in an X environment for 
me when building. Which is at least easy to work around.


Will post if it segfaults again on either machine once they are done.


My borrowed machine segfaulted while finishing building perl. So I guess 
that had nothing to do with the segfault issues. I ended up with the 
same qa.log output and same type of output on dmesg relating to libc and 
ld again.


Laptop no X on that segfaulted in the normal places

Should I try installing Ubuntu 10.04 on the borrowed machine and seeing 
if the OS works on that machine? I am still lost as nothing seems to 
really be telling me what is segfaulting. The rest of the logs basically 
look the same as the series I posted earlier.



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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 02:16 PM, j wrote:

On 04/17/2012 01:17 PM, j wrote:

On 04/17/2012 12:49 PM, j wrote:

On 04/17/2012 12:34 PM, Mark Hatle wrote:

On 4/17/12 2:09 PM, j wrote:

On 04/17/2012 09:13 AM, J. L. wrote:




<http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel> 





I went for a build on the borrowed machine again but this time I 
did not

go into X just stayed in RL3. Then ran bitbake perl, on a clean build
dir. It is just about to finish building a few steps away but where I
normally get the segfaults, it has not spit those out. There are 
no QA

logs being generated either. So looks like it had/has something to do
with running X, both systems are running nvidia graphics cards. The
laptop has a new mobile one, borrowed an old one that is nouveau
compatible. So both open and closed nvidia drivers were tried. But
something when in the graphical environment is giving the segfault
issues I have been seeing. I have not yet verified if killing X on 
the

laptop builds and eliminates the issues as well.

Will post back once I have built the kernel on both machines with 
no X

running.


There is a known issue w/ nvidia drivers, segfaulting and QEMU.  Is 
something in perl (or elsewhere) trying to run qemu to finish up a 
task?


--Mark
Not that I can tell, but that does not mean it is not (still 
learning things), but possible one of threads is working on 
something perl related when it happens and I am not seeing it or 
realizing it. If you are willing to post the commands I could run to 
check, I can post the results. But when I do just a bitbake -c 
compile perl on a clean build dir all I would see was the segfault 
in dmesg and the results in QA log. Nothing would show up on the 
command line that was not in the QA log, after doing each step one 
by one.


But it must be related to this known issue with nvidia. Should be a 
couple hours before both machines finish building the kernel and 
perl, will post the results after. But looks promising for my laptop 
so far as no segfaults yet. Borrowed machine is on to building the 
kernel now and nothing posted yet.


Thank you for your response very appreciated. I will also read more 
about the issue you stated.



From what I am reading about this is its related to libgl. But on the 
machine I borrowed I used nouveau driver's which uses the libgl that 
is expected not the nvidia's supplied version. So maybe that is not 
fully it. But still all seems related to being in an X environment 
for me when building. Which is at least easy to work around.


Will post if it segfaults again on either machine once they are done.


My borrowed machine segfaulted while finishing building perl. So I 
guess that had nothing to do with the segfault issues. I ended up with 
the same qa.log output and same type of output on dmesg relating to 
libc and ld again.


Laptop no X on that segfaulted in the normal places

Should I try installing Ubuntu 10.04 on the borrowed machine and 
seeing if the OS works on that machine? I am still lost as nothing 
seems to really be telling me what is segfaulting. The rest of the 
logs basically look the same as the series I posted earlier.




Well finally caught what I think is the package the segfault kicks on 
expat. Though not sure what I should look for to be able to sort it out 
but will see where I get.


Though I still get the gcc and bash messages in the QA log. If anyone is 
willing to share some info on what or how I can figure out how to find 
what causes the segfault in the recipe or if I am even catching the 
correct one.


Thank you

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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/17/2012 10:30 PM, Khem Raj wrote:

On Tue, Apr 17, 2012 at 5:37 PM, j  wrote:

Well finally caught what I think is the package the segfault kicks on expat.
Though not sure what I should look for to be able to sort it out but will
see where I get.

Though I still get the gcc and bash messages in the QA log. If anyone is
willing to share some info on what or how I can figure out how to find what
causes the segfault in the recipe or if I am even catching the correct one.


you are not giving out enough information. Looking at dmesg is not
going to give much info
if ld segfaults which I assume is cross ld here then the corresponding
recipe should fail
and then you should look in the build of that package and the commands
causing the segfaults
should be in log.do_compile or log.do_install.

Thanks
-Khem

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
See thats the thing no recipe is failing but the system segfaults. The 
resulting images have had quirks which is what led me to trying to sort 
out the segfault issue.


Sorry to sound so dumb but if there is no recipe failing and 2 separate 
systems are segfaulting in similar manners and both result with not 
fully functioning images/packages where else can I look for info? I 
posted all the logs to one of the builds, and the QA log seems to be the 
only thing really spitting out anything. I am open to trying and or 
sharing any and all relevant info to help sort it out or get me on track 
to sorting it out.


Thank you for all the continued effort.

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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/18/2012 03:00 PM, Khem Raj wrote:

On Tue, Apr 17, 2012 at 10:40 PM, j  wrote:

Sorry to sound so dumb but if there is no recipe failing and 2 separate
systems are segfaulting in similar manners and both result with not fully
functioning images/packages where else can I look for info? I posted all the
logs to one of the builds, and the QA log seems to be the only thing really
spitting out anything. I am open to trying and or sharing any and all
relevant info to help sort it out or get me on track to sorting it out.

what I am hearing is that your build succeeds despite these ld
segfaults. Am I right ?
but then when you run the resulting images then the images dont
function correctly
on your target
First off thank you all for your time and information, and putting up 
with me learning and trying to get things working!!
Yes you are correct. Nothing in the images or packages fail, but the 
build machine itself segfaults. Then if I put the image on my BB-XM 
sdcard they boot and "run" but things are not right, such as directories 
that should not be there are, some do not build a fully functioning 
package, such as task-native-sdk.





and you also mentioned that its expat package when being built that
causes the ld
segfaults. Are you sure about that ? You could somehow forge ulimit to unlimited
that will dump
No I am not sure about it. As I am just trying to watch it build and 
look for the build machine to segfault and see what packages it is 
working on. Though after further messing with expat I think you are 
correct in doubting that is the one causing it.


I just did a clean build of perl with no rm_work enabled, and I am 
trying to dig through the logs and info. From your earlier 
advice/mentioning of libtool-cross I do notice some things while it is 
building according to the info. I will post some of what stood out to 
me, which may in turn mean nothing. If I can post anymore of the logs or 
anything please let me know. I did notice today setting things to build 
one at a time, that it does appear that its working on libtool-cross, 
but again I could be wrong.




on ubuntu edit /etc/security/limits.conf on build host and then add
* softcoreunlimited

that should generate core files. After this search for core* files in build tree
and see if there are any then debug them with gdb to diagnose it further

Now I am not sure if those segfaults directly relate to malfunction of image
if thats the case but its likely. You should also try to explore the reasons why
the image fails to behave as expected.
I will do as suggested as well as do a full image build again and see if 
I can find out all that is not working. Thank you for the extra 
debugging info and suggestions. Are there any keywords to search through 
all the files for including the normal log files, it may help me track 
down things even further.




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


I really am not trying to be a pain in the a** and would like to get 
things sorted out and understood on my side. Honestly if the resulting 
images worked and did not get any extra folders in their paths I would 
not care about the resulting segfaults on the build machine.


Another side note, I am borrowing another build machine for a few days 
to see, this is a non nvidia machine just in case that is the bad 
variable in both machines.


libtool-cross info::
log.do_configure
/configure: WARNING: unrecognized options: --disable-silent-rules, 
--with-sysroot/


log.do_compile:
help2man is installed on the system, whereis help2man
help2man: /usr/bin/help2man /usr/lib/help2man 
/usr/share/man/man1/help2man.1.gz


/WARNING: `help2man' is missing on your system.  You should only need it if
 you modified a dependency of a manual page.  You may need the
 `Help2man' package in order for those modifications to take
 effect.  You can get `Help2man' from any GNU archive site.
PATH=".:$PATH"; export PATH; /bin/sh 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/libtool-cross-2.4.2-r2.1/libtool-2.4.2/libltdl/config/missing 
--run help2man --output=doc/libtoolize.1 libtoolize

WARNING: `help2man' is missing on your system.  You should only need it if
 you modified a dependency of a manual page.  You may need the
 `Help2man' package in order for those modifications to take
 effect.  You can get `Help2man' from any GNU archive site./

log.do_package
/DEBUG: Preparing tree 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/libtool-cross-2.4.2-r2.1/shlibs 
for packaging at 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/libtool-cross-2.4.2-r2.

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/18/2012 11:24 PM, Khem Raj wrote:

On Wed, Apr 18, 2012 at 8:32 PM, j  wrote:

on ubuntu edit /etc/security/limits.conf on build host and then add
* softcoreunlimited


btw. reboot your machine after this change is made


that should generate core files. After this search for core* files in
build tree
and see if there are any then debug them with gdb to diagnose it further

Now I am not sure if those segfaults directly relate to malfunction of
image
if thats the case but its likely. You should also try to explore the
reasons why
the image fails to behave as expected.

I will do as suggested as well as do a full image build again and see if I
can find out all that is not working. Thank you for the extra debugging info
and suggestions. Are there any keywords to search through all the files for
including the normal log files, it may help me track down things even
further.

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


did the reboot went through the build but yet did not produce any core 
files. But I noticed ulimit was still 0 so changed it to unlimited now 
and building again, hopefully that will get some core dumps. Will post 
back once I have more info and will separate anything by which machine 
as even the 2nd borrowed machine segfaults in the same way.


Thanks again for the help

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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/20/2012 04:13 AM, Gary Thomas wrote:

On 2012-04-19 18:39, j wrote:

On 04/18/2012 11:24 PM, Khem Raj wrote:

On Wed, Apr 18, 2012 at 8:32 PM, j wrote:

on ubuntu edit /etc/security/limits.conf on build host and then add
* soft core unlimited


btw. reboot your machine after this change is made


that should generate core files. After this search for core* files in
build tree
and see if there are any then debug them with gdb to diagnose it 
further


Now I am not sure if those segfaults directly relate to 
malfunction of

image
if thats the case but its likely. You should also try to explore the
reasons why
the image fails to behave as expected.
I will do as suggested as well as do a full image build again and 
see if I
can find out all that is not working. Thank you for the extra 
debugging info
and suggestions. Are there any keywords to search through all the 
files for

including the normal log files, it may help me track down things even
further.

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


did the reboot went through the build but yet did not produce any 
core files. But I noticed ulimit was still 0 so changed it to 
unlimited now and building again, hopefully that
will get some core dumps. Will post back once I have more info and 
will separate anything by which machine as even the 2nd borrowed 
machine segfaults in the same way.


Is your borrowed machine also running ArchLinux?  If so, have
you tried anything else - Ubuntu, Fedora, etc?  As far as I can
tell, you're the only one suffering these problems and also you
seem to be the only one using ArchLinux.


I have installed Ubuntu 10.04 and Fedora 16 on the borrowed machine as 
well. And still failing in the same manner. I am trying to do what Khem 
suggested and get core files but for some reason, even though it is 
saying I have it set to unlimited it is still not spitting anything out.


I have abandoned Arch on the build machines for now as to keep that out 
of the variables.




Note: I tried to duplicate your problems here, but I've never used
ArchLinux and it's so primitive and hard to use (compared to what
I use everyday) that I simply don't have the time to mess with it
any more.

It is not the only OS that does this for me. I am honestly surprised to 
hear Arch is hard, as that is how I see OE and trying to get a 
functioning build machine. :P


I just got my 2nd borrowed machine today and starting to set it up now. 
Installing Ubuntu on it.


If there is a single OS to install and try on all 3 I will happily do it 
again. But this is a non OS dependent thing is my guess since I am on 2 
machines now that have done this.


My QA.log's are still basically the same as well. all relating to LD 
type issues.


I am still working through getting the image built on th1st borrowed 
machine it is slow and starting the


Again OE classic(gumstix branch does not segfault on my machine that 
started all this it only started happening once I started trying to 
build a BBXM image on a new install on the same machine.


If there is a OS and configuration to specifically try then outside of 
what is listed on the Angstrom pages and OE and your Distro pages please 
fill me in and will try. But as it stands now 2 totally different 
machines have gone through 3+ OS changes all have the same issue, all 
relatively the same issues and logs that were posted before. Should I 
attach more logs?


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

Re: [oe] [oe-core] ld segfault cant figure it out

[j]

On 04/20/2012 04:13 AM, Gary Thomas wrote:

On 2012-04-19 18:39, j wrote:

On 04/18/2012 11:24 PM, Khem Raj wrote:

On Wed, Apr 18, 2012 at 8:32 PM, j wrote:

on ubuntu edit /etc/security/limits.conf on build host and then add
* soft core unlimited


btw. reboot your machine after this change is made


that should generate core files. After this search for core* files in
build tree
and see if there are any then debug them with gdb to diagnose it 
further


Now I am not sure if those segfaults directly relate to 
malfunction of

image
if thats the case but its likely. You should also try to explore the
reasons why
the image fails to behave as expected.
I will do as suggested as well as do a full image build again and 
see if I
can find out all that is not working. Thank you for the extra 
debugging info
and suggestions. Are there any keywords to search through all the 
files for

including the normal log files, it may help me track down things even
further.

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


did the reboot went through the build but yet did not produce any 
core files. But I noticed ulimit was still 0 so changed it to 
unlimited now and building again, hopefully that
will get some core dumps. Will post back once I have more info and 
will separate anything by which machine as even the 2nd borrowed 
machine segfaults in the same way.


Is your borrowed machine also running ArchLinux?  If so, have
you tried anything else - Ubuntu, Fedora, etc?  As far as I can
tell, you're the only one suffering these problems and also you
seem to be the only one using ArchLinux.

Note: I tried to duplicate your problems here, but I've never used
ArchLinux and it's so primitive and hard to use (compared to what
I use everyday) that I simply don't have the time to mess with it
any more.

Also though not mentioned in my last email Gary THANK YOU!! 3rd machine 
has started build now. I installed 11.04 i386. This has intel graphics, 
where as the other 2 had nvidia. But this will be another slow build.


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

Re: [oe] [oe-core] 3 build machines all failing in the same manner - was:ld segfault cant figure it out

[j]

OK I have now tried with 3 build machines all varying components the 
last one being a server. All 3 of these machines are segfaulting, all 
saying it is a ld segfault with libc. No packages are actually failing 
and stopping the build. This is the segfault that is showing on each 
machine but of course libc version is dependent on the OS being used.
[47152.769257] ld[22617]: segfault at 403 ip 7f2149cfd435 sp 
7fffb83ccb50 error 4 in libc-2.15.so[7f2149cb6000+197000]
2012-04-18T14:50:08-07:00 localhost kernel: [47163.860996] ld[31096]: 
segfault at 403 ip 7fc2da152435 sp 7fffab491c30 error 4 in 
libc-2.15.so[7fc2da10b000+197000]


My first question is what from these 3 machines can I share with the 
list to help? The qa.log's on all 3 look almost identical just depending 
on if I build a full image or just start fresh and build only perl. I 
have attached one for example. Can anyone explain the qa.log to me? 
Would cooker logs from each machine help? I dont want to just attach a 
bunch of things if they would not be of help.


I have tried enabling core files as per Khem suggestion's but for some 
reason I am not able to either find them or it is not producing any. I 
have set all 3 to unlimited.


My current setup:

My first machine:
Toshiba Qosmio x505-887 nvidia graphics, Have tried with Ubuntu 10.04 
32&64bit and 11.04 64bit, Fedora 16 32bit, ArchLinux,


1st machine borrowed:
Dell xps 400 tower nvidia graphics, Have tried ArchLinux, Ubuntu 10.04 
32bit and 12.04 server beta 32bit


2nd machine borrowed
Dell poweredge 1750, setup with Ubuntu server 12.04 beta and 10.04 
server both 32bit


I will have these borrowed machine for about a week more to help me try 
and figure this out. But I am really at a loss as now 3 machines have 
the same issues how am I this unlucky?


My steps to build
1. Fresh install of OS
2. Update the OS completely
3. reconfigure dash if on Ubuntu
4. Download distro requirements from the OE and your Distro page, then 
reboot

5. clone the angstrom setup scripts
6. setup for BBXM as per Angstrom setup page
7. source my environment
8. bitbake perl

That is what I have done each time, am I missing something? Not doing 
something properly? Again OE classic(gumstix overo) builds on my laptop 
the Toshiba, and has been for awhile. This started once I bought a BBXM 
and went to setup a dedicated install for the BBXM. If this is hardware 
related as mentioned before what hardware could it be since the 
poweredge does not have the nvidia graphics the other 2 did.


Thank you for your time and help.
libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev path '/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r49+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc_eh.a'
libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev path '/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r49+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcc.a'
libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev path '/work/armv7a-angstrom-linux-gnueabi/libgcc-4.5-r49+svnr184907/packages-split/libgcc-dev/usr/lib/arm-angstrom-linux-gnueabi/4.5.4/libgcov.a'
libpam-1.1.5: libpam: /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/armv7a-angstrom-linux-gnueabi/libpam-1.1.5-r3/packages-split/pam-plugin-cracklib/lib/security/pam_cracklib.so links to something under exec_prefix
libpam-1.1.5: ldd reports: 	libpam.so.0 => /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libpam.so.0 (0xdead1000)
	libdl.so.2 => /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libdl.so.2 (0xdead2000)
	libcrack.so.2 => /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libcrack.so.2 (0xdead3000)
	libz.so.1 => /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libz.so.1 (0xdead4000)
	libcrypt.so.1 => /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libcrypt.so.1 (0xdead5000)
	libc.so.6 => /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libc.so.6 (0xdead6000)
	/lib/ld-linux.so.3 => /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/ld-linux.so.3 (0xdead7000)

udev-182: udev: /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/armv7a-angstrom-linux-gnueabi/udev-182-r0/packages-split/libgudev/lib/libgudev-1.0.so.0.1.1 links to something under exec_prefix
udev-182: ldd reports: 	libudev.so.0 => /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libudev.so.0 (0xdead1000)
	libgobject-2.0.so.0 => /home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012

Re: [oe] [oe-core] 3 build machines all failing in the same manner - was:ld segfault cant figure it out

[j]

On 04/21/2012 02:47 PM, j wrote:



Thank you for your time and help.


really I am the only person who is this unlucky with 3 build machines 
all having the same issue ? This makes no sense to me. Is there anything 
I stated in my steps following or the guides I stated that it is not 
giving me a working build machine on 3 different setups all with the 
same issue? I have tried Ubuntu on every machine so it has nothing to do 
with me trying Arch initially. 10.04 11.04 and 12.04.


So the qa.log I attached previously is meaningless? The 
warnings/messages mean nothing? To me the ld segfault is the reason most 
of qa.log has messages. Also why would oe-classic build on my laptop and 
one of the borrowed machines with no segfaults and no issues with the 
completed images, but then doing the new setup and version used gives me 
the build issues on multiple machines. I also do not understand why if 
while building, the build machine segfaults while building some package 
but the "offending" package does not fail.


But since I obviously do not get what I should be supplying to the list 
for help and I am obviously the only person who has this issue and do 
not get working images in the end, this will go unsolved unless I just 
get lucky.


I am cleaning each machine again and going to try one last time on each 
one with Ubuntu 10.04 following the steps I listed above and the guides 
I stated, if all 3 fail again and with no more info than I get now I 
will just have to call it broken, and only works for specific hardware. 
Again I am willing to share any specific info that I have not already 
throughout this thread, but I do not feel like flooding anymore if there 
is no interest in this and will have to go to a different OS and build 
methods for the BBXM. The only different thing I am going to do this 
time is let it re-download all the sources over again just in case that 
is the cause, though doubt it is.


Do not mean to sound rude or ungrateful with the help recieved so far 
but this is very frustrating and I seem to be able to easily reproduce 
this on multiple hardware configurations, which is part of why I do not 
get how I am the only one.


Thank you for your time.

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

Re: [oe] [oe-core] 3 build machines all failing in the same manner - was:ld segfault cant figure it out

[j]

On 04/24/2012 01:44 PM, Phil Blundell wrote:

On Tue, 2012-04-24 at 13:39 -0700, j wrote:

So the qa.log I attached previously is meaningless? The
warnings/messages mean nothing? To me the ld segfault is the reason most
of qa.log has messages. Also why would oe-classic build on my laptop and
one of the borrowed machines with no segfaults and no issues with the
completed images, but then doing the new setup and version used gives me
the build issues on multiple machines. I also do not understand why if
while building, the build machine segfaults while building some package
but the "offending" package does not fail.

What exactly do you mean by "the build machine segfaults"?  What
precisely is the problem that you're having, and which particular
messages in qa.log do you think are associated with "the ld segfault"?

p.



___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
The build machines all give messages like this just vary on libc version 
listed


[47152.769257] ld[22617]: segfault at 403 ip 7f2149cfd435 sp 
7fffb83ccb50 error 4 in libc-2.15.so[7f2149cb6000+197000]
2012-04-18T14:50:08-07:00 localhost kernel: [47163.860996] ld[31096]: 
segfault at 403 ip 7fc2da152435 sp 7fffab491c30 error 4 in 
libc-2.15.so[7fc2da10b000+197000]


qa.log has more than these messages but every machines logs are the same 
like this


udev-182: udev: 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/armv7a-angstrom-linux-gnueabi/udev-182-r0/packages-split/libgudev/lib/libgudev-1.0.so.0.1.1 
links to something under exec_prefix
udev-182: ldd reports: libudev.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libudev.so.0 
(0xdead1000)
libgobject-2.0.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libgobject-2.0.so.0 
(0xdead2000)
libffi.so.5 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libffi.so.5 
(0xdead3000)
libgthread-2.0.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libgthread-2.0.so.0 
(0xdead4000)
libpthread.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libpthread.so.0 
(0xdead5000)
libglib-2.0.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libglib-2.0.so.0 
(0xdead6000)
librt.so.1 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/librt.so.1 
(0xdead7000)
libc.so.6 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libc.so.6 
(0xdead8000)
libgcc_s.so.1 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libgcc_s.so.1 
(0xdead9000)
/lib/ld-linux.so.3 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/ld-linux.so.3 
(0xdeada000)


udev-182: udev: 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/armv7a-angstrom-linux-gnueabi/udev-182-r0/packages-split/udev/lib/udev/udevd 
links to something under exec_prefix
udev-182: ldd reports: libblkid.so.1 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libblkid.so.1 
(0xdead1000)
libkmod.so.2 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libkmod.so.2 
(0xdead2000)
librt.so.1 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/librt.so.1 
(0xdead3000)
libc.so.6 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libc.so.6 
(0xdead4000)
libuuid.so.1 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libuuid.so.1 
(0xdead5000)
libpthread.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libpthread.so.0 
(0xdead6000)
/lib/ld-linux.so.3 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/ld-linux.so.3 
(0xdead7000)


libcgroup-0.37.1: libcgroup: 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/armv7a-angstrom-linux-gnueabi/libcgroup-0.37.1-r1/packages-split/cgroups-pam-plugin/lib/security/pam_cgroup.so.0.0.0 
links to something under exec_prefix
libcgroup-0.37.1: ldd reports: libcgroup.so.1 => 
/home/gusterso

Re: [oe] [oe-core] 3 build machines all failing in the same manner - was:ld segfault cant figure it out

[j]

On 04/24/2012 01:44 PM, Phil Blundell wrote:

On Tue, 2012-04-24 at 13:39 -0700, j wrote:

So the qa.log I attached previously is meaningless? The
warnings/messages mean nothing? To me the ld segfault is the reason most
of qa.log has messages. Also why would oe-classic build on my laptop and
one of the borrowed machines with no segfaults and no issues with the
completed images, but then doing the new setup and version used gives me
the build issues on multiple machines. I also do not understand why if
while building, the build machine segfaults while building some package
but the "offending" package does not fail.

What exactly do you mean by "the build machine segfaults"?  What
precisely is the problem that you're having, and which particular
messages in qa.log do you think are associated with "the ld segfault"?

p.



___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
The build machines all give messages like this just vary on libc version 
listed


[47152.769257] ld[22617]: segfault at 403 ip 7f2149cfd435 sp 
7fffb83ccb50 error 4 in libc-2.15.so[7f2149cb6000+197000]
2012-04-18T14:50:08-07:00 localhost kernel: [47163.860996] ld[31096]: 
segfault at 403 ip 7fc2da152435 sp 7fffab491c30 error 4 in 
libc-2.15.so[7fc2da10b000+197000]


qa.log has more than these messages but every machines logs are the same 
like this


udev-182: udev: 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/armv7a-angstrom-linux-gnueabi/udev-182-r0/packages-split/libgudev/lib/libgudev-1.0.so.0.1.1 
links to something under exec_prefix
udev-182: ldd reports: libudev.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libudev.so.0 
(0xdead1000)
libgobject-2.0.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libgobject-2.0.so.0 
(0xdead2000)
libffi.so.5 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libffi.so.5 
(0xdead3000)
libgthread-2.0.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libgthread-2.0.so.0 
(0xdead4000)
libpthread.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libpthread.so.0 
(0xdead5000)
libglib-2.0.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libglib-2.0.so.0 
(0xdead6000)
librt.so.1 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/librt.so.1 
(0xdead7000)
libc.so.6 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libc.so.6 
(0xdead8000)
libgcc_s.so.1 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libgcc_s.so.1 
(0xdead9000)
/lib/ld-linux.so.3 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/ld-linux.so.3 
(0xdeada000)


udev-182: udev: 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/armv7a-angstrom-linux-gnueabi/udev-182-r0/packages-split/udev/lib/udev/udevd 
links to something under exec_prefix
udev-182: ldd reports: libblkid.so.1 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libblkid.so.1 
(0xdead1000)
libkmod.so.2 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/usr/lib/libkmod.so.2 
(0xdead2000)
librt.so.1 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/librt.so.1 
(0xdead3000)
libc.so.6 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libc.so.6 
(0xdead4000)
libuuid.so.1 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libuuid.so.1 
(0xdead5000)
libpthread.so.0 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/libpthread.so.0 
(0xdead6000)
/lib/ld-linux.so.3 => 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/sysroots/beagleboard/lib/ld-linux.so.3 
(0xdead7000)


libcgroup-0.37.1: libcgroup: 
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/armv7a-angstrom-linux-gnueabi/libcgroup-0.37.1-r1/packages-split/cgroups-pam-plugin/lib/security/pam_cgroup.so.0.0.0 
links to something under exec_prefix
libcgroup-0.37.1: ldd reports: libcgroup.so.1 => 
/home/gusterso

Re: [oe] [oe-core] 3 build machines all failing in the same manner - was:ld segfault cant figure it out

[j]

On 04/24/2012 02:03 PM, Phil Blundell wrote:

On Tue, 2012-04-24 at 13:57 -0700, j wrote:

The build machines all give messages like this just vary on libc version
listed

[47152.769257] ld[22617]: segfault at 403 ip 7f2149cfd435 sp
7fffb83ccb50 error 4 in libc-2.15.so[7f2149cb6000+197000]
2012-04-18T14:50:08-07:00 localhost kernel: [47163.860996] ld[31096]:
segfault at 403 ip 7fc2da152435 sp 7fffab491c30 error 4 in
libc-2.15.so[7fc2da10b000+197000]

Does this correlate with an actual problem, or did you just see those
messages in the log and think that they were cause for concern?
I was assuming since the machine segfaulted and I could not get working 
images they were related.




If I had to guess I would say that this is probably some autoconf test
which is tickling a bug in ld.  You could probably establish which
package is doing that by looking at the timestamps and correlating them
with the build logs.


I will try this once the machines go through the process again.




qa.log has more than these messages but every machines logs are the same
like this

udev-182: udev:
/home/gusterson/OpenEmbed/setup-scripts/build/tmp-angstrom_v2012_05-eglibc/work/armv7a-angstrom-linux-gnueabi/udev-182-r0/packages-split/libgudev/lib/libgudev-1.0.so.0.1.1
links to something under exec_prefix

That doesn't appear to be related to the ld segfault
.

each one of the machines from a fresh install have this problem. The
resulting image boots but does not fully function. I have issues such as
the native sdk does not install all the packages correctly.
example would be install.
normall you would find it
/usr/bin/install
I end up with
/home/bill/OE/usr/bin/install

... and nor really does this.  This latter problem is almost certainly
just a bug in the SDK packaging and nothing at all to do with your build
host.

p.



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


I will just focus on trying to match timestamps with the segfault and 
trying to sort out all the issues once I have a built image.


I know I do not fully grasp everything here so thank you for your help 
and if I find anything relevant or can post further info on this I will 
share. Unless there are more suggestions.


Thank you

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

Re: [oe] [oe-core] 3 build machines all failing in the same manner - was:ld segfault cant figure it out

[j]

On 04/24/2012 02:15 PM, j wrote:



Thank you


After updating all build machines again last night to the most recent OE 
and letting each download new source files. none segfaulted in the 
resulting build, qa.log has a few similar entries and some new ones, but 
all appears to be good. Testing first image now, first quick run through 
shows even the SDK installed properly this time.


Thanks for whatever the fix was and for putting up with and helping me 
with suggestions and information.


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

Re: [oe] Package selection

[j]

On 06/18/2012 05:32 PM, Ciprian Ciubotariu wrote:

On Monday 18 June 2012 11:57:01 Dallas Clement wrote:

Lastly, it is possible to avoid the repeated fetching of source
packages?  In other words, can the source URI's point to packages in a
local file system repository?

I have extracted some minimal code from the old OE srctree.bbclass file that
allows us to do minimal rebuilds when developing:

S="/path/to/your/sources/"
SRC_URI=""

def remove_tasks(deltasks, d):
 for task in filter(lambda k: d.getVarFlag(k, "task"), d.keys()):
 deps = d.getVarFlag(task, "deps")
 for preptask in deltasks:
 if preptask in deps:
 deps.remove(preptask)
 d.setVarFlag(task, "deps", deps)

#addtask configure after do_setscene

python () {
 remove_tasks(["do_patch", "do_unpack", "do_fetch"], d)
}


Note that setting S there makes bitbake treat this as the work folder, so
you'll get oe-core build artifacts there.

Also, you need to bitbake -c cleanall  to make bitbake forget it


Isnt bitbake -c cleansstate  a better method of cleaning a 
build you want to do again?


If not does anyone know what the actual difference is?

has already built your package, and next bitbake  to perform the
minimal build.


Thanks much,

Dallas

___
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] Package selection

[j]

On 06/18/2012 09:40 PM, Khem Raj wrote:

On Mon, Jun 18, 2012 at 9:34 PM, j  wrote:

Also, you need to bitbake -c cleanall  to make bitbake
forget it


Isnt bitbake -c cleansstate  a better method of cleaning a
build you want to do again?

If not does anyone know what the actual difference is?

clean - cleans the builddir
cleansstate - cleans builddir as well as shared state copy of this
package if any
cleanall - clean builddir, shared state and the downloaded src tar
file from DL_DIR

you usually only should need clean in general. cleansstate should be seldom used
but its preferred to see why cleansstate is needed and if there is
anything wrong
with sstate we would like to know.

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Thanks Khem, been wondering that info just had not looked into it as of 
yet. Makes perfect sense now.



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

Re: [oe] having issues with libprelude and libpam

[j]

On 03/18/2012 05:06 PM, j wrote:
I am trying to get libpam to build which fails due to not finding the 
header from the libprelude build, which currently also fails to build 
for me. I am hoping someone knows of a fix or can point me to the 
right place to dig for a solution, I do not see any listed fixes or 
workarounds from my digging online. I have attached the build logs for 
each as well, since they were long if the preferred method is 
different, sorry and please let me know how to post those. In the 
libprelude error its saying there are files that seem to have moved, 
but they actually exsist in the location it says it does not.


I am running on Ubuntu 11.04 32bit (up to date). Bitbake branch 1.12, 
OE branch overo-2011.03 (both up to date). I know this is not your 
guys branch but have not gotten any feed back on gumstix in relation 
to issues building these packages, so checked them verse what I 
believe was the master branch and they had no diff. If I can give more 
info on system specs or anything like that please let me know. I 
believe I know the "issues" just not sure how to go about solving 
them, as libprelude seems like a more serious error. These are the 
only two packages that fail to build for image that do not rely on 
these lib's. I also have both of these installed on the build machine 
itself, I also built everything each rely on for the build, at least I 
believe I did none failed.


Thanks a ton for any help or info.


Well switching to the mainline branch but still bitbake 1.12 both still 
fail to build for me in the same manner. Does anyone have any ideas for 
libprelude that I can maybe try or try and track down further? As libpam 
should build once libprelude does.


Thanks for any help.

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

Re: [oe] [oe-core] ld segfault cant figure it out

[J. L.]

OS - Arch Linux i686 fully up to date, Kernel's tried 3.3.1 3.0.27

Build machines: 1. Toshiba qosmio x505-887 laptop
2. Dell XPS tower
I can give exact hardware specs if needed.

Setup how Angstrom site says to for their build environment setup secripts.
Packages installed are all on OE and your distro plus I was also missing
cpio.

OE Build Configuration:
BB_VERSION= "1.15.1"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "beagleboard"
DISTRO= "angstrom"
DISTRO_VERSION= "v2012.04-core"
TUNE_FEATURES = "armv7a vfp neon cortexa8"
TARGET_FPU= "vfp-neon"

Once the environment is setup, I source my environment file then I just run
bitbake perl
or
bitbake virtual/kernel

both give the segfaults. It appears the segfaults happen during teh build
tools setup. Right around when bitbake pulls gcc into the line up to start
building.

That is all I have done each time.

If there is more info you need please let me know and I will gladly reply
with it.

I thank you emensly for your continued help with this Gary!!

JL

On Tue, Apr 17, 2012 at 8:54 AM, Gary Thomas  wrote:

> On 2012-04-17 09:41, J. L. wrote:
>
>> Well I borrowed a tower from a friend setup everything on a fresh install
>> for both OS and build environment. Well I am still getting the same issue
>> so it must not be an actual hardware issue. The first was trying to be
>> built on my laptop, now trying this tower I get the same results just
>> starting from scratch and building perl.
>>
>
> What are your exact details - OS & Angstrom (versions, etc).  I'll try
> and run the same process here if you'll send enough details to reproduce
> exactly what you've done (which should be straight forward to provide since
> you just [re]did it yourself).
>
>
>> I tried building just gcc and bash and well after cleaning them and I am
>> not seeing anything that sticks out to me. Other than the errors and what
>> not.
>>
>> Can anyone help me figure this out. Since it is now for sure not a
>> hardware
>> issue, die to same results on 2 machines. I have attached the cooker logs
>> and qalogs incase they could be of any use in helping figure out the
>> issue.
>>
>> Thank your for your time and help
>>
>>
>> QALOG
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcc_eh.a'
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcov.a'
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcc.a'
>> bash-4.2: bash: Found a reference to /usr/ in
>> /home/gooms/OE/setup-scripts/**build/tmp-angstrom_2010_x-**
>> eglibc/work/armv7a-angstrom-**linux-gnueabi/bash-4.2-r2/**
>> packages-split/bash/bin/**bashbug
>> bash-4.2: Shell scripts in base_bindir and base_sbindir should not
>> reference anything in exec_prefix
>>
>>
>> SEGFAULT
>> [10582.729446] ld[24926]: segfault at 8 ip b75ba427 sp bff61970 error 4 in
>> libc-2.15.so[b7576000+19b000]
>> [10596.912141] ld[30317]: segfault at 8 ip b758e427 sp bfbac350 error 4 in
>> libc-2.15.so[b754a000+19b000]
>>
>>
>> On Mon, Apr 16, 2012 at 6:43 PM, j  wrote:
>>
>>  On 04/16/2012 03:34 PM, j wrote:
>>>
>>>  On 04/16/2012 03:28 PM, Gary Thomas wrote:
>>>>
>>>>  On 2012-04-16 16:11, j wrote:
>>>>>
>>>>>  On 04/13/2012 03:50 PM, j wrote:
>>>>>>
>>>>>>  On 04/13/2012 03:46 PM, j wrote:
>>>>>>>
>>>>>>>  There seems to be a couple of packages when I build that cause ld
>>>>>>>> segfaults such as
>>>>>>>> [ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c
>>>>>>>> error
>>>>>>>> 4 in libc-2.13.so[73d000+15c000]
>>>>>>>> [ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc
>>>>>>>> error
>>>>>>>> 4 in libc-2.13.so

Re: [oe] [oe-core] ld segfault cant figure it out

[J. L.]

I forgot to note angstrom version being used
DISTRO   = "angstrom-2010.x"


On Tue, Apr 17, 2012 at 8:54 AM, Gary Thomas  wrote:

> On 2012-04-17 09:41, J. L. wrote:
>
>> Well I borrowed a tower from a friend setup everything on a fresh install
>> for both OS and build environment. Well I am still getting the same issue
>> so it must not be an actual hardware issue. The first was trying to be
>> built on my laptop, now trying this tower I get the same results just
>> starting from scratch and building perl.
>>
>
> What are your exact details - OS & Angstrom (versions, etc).  I'll try
> and run the same process here if you'll send enough details to reproduce
> exactly what you've done (which should be straight forward to provide since
> you just [re]did it yourself).
>
>
>> I tried building just gcc and bash and well after cleaning them and I am
>> not seeing anything that sticks out to me. Other than the errors and what
>> not.
>>
>> Can anyone help me figure this out. Since it is now for sure not a
>> hardware
>> issue, die to same results on 2 machines. I have attached the cooker logs
>> and qalogs incase they could be of any use in helping figure out the
>> issue.
>>
>> Thank your for your time and help
>>
>>
>> QALOG
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcc_eh.a'
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcov.a'
>> libgcc-4.5: non -staticdev package contains static .a library: libgcc-dev
>> path
>> '/work/armv7a-angstrom-linux-**gnueabi/libgcc-4.5-r48+**
>> svnr184907/packages-split/**libgcc-dev/usr/lib/arm-**
>> angstrom-linux-gnueabi/4.5.4/**libgcc.a'
>> bash-4.2: bash: Found a reference to /usr/ in
>> /home/gooms/OE/setup-scripts/**build/tmp-angstrom_2010_x-**
>> eglibc/work/armv7a-angstrom-**linux-gnueabi/bash-4.2-r2/**
>> packages-split/bash/bin/**bashbug
>> bash-4.2: Shell scripts in base_bindir and base_sbindir should not
>> reference anything in exec_prefix
>>
>>
>> SEGFAULT
>> [10582.729446] ld[24926]: segfault at 8 ip b75ba427 sp bff61970 error 4 in
>> libc-2.15.so[b7576000+19b000]
>> [10596.912141] ld[30317]: segfault at 8 ip b758e427 sp bfbac350 error 4 in
>> libc-2.15.so[b754a000+19b000]
>>
>>
>> On Mon, Apr 16, 2012 at 6:43 PM, j  wrote:
>>
>>  On 04/16/2012 03:34 PM, j wrote:
>>>
>>>  On 04/16/2012 03:28 PM, Gary Thomas wrote:
>>>>
>>>>  On 2012-04-16 16:11, j wrote:
>>>>>
>>>>>  On 04/13/2012 03:50 PM, j wrote:
>>>>>>
>>>>>>  On 04/13/2012 03:46 PM, j wrote:
>>>>>>>
>>>>>>>  There seems to be a couple of packages when I build that cause ld
>>>>>>>> segfaults such as
>>>>>>>> [ 6635.846581] ld[14419]: segfault at 8 ip 0077f1bf sp bfbf4a8c
>>>>>>>> error
>>>>>>>> 4 in libc-2.13.so[73d000+15c000]
>>>>>>>> [ 6656.831878] ld[20772]: segfault at 8 ip 00ba61bf sp bfaf1bfc
>>>>>>>> error
>>>>>>>> 4 in libc-2.13.so[b64000+15c000]
>>>>>>>>
>>>>>>>> I can not seem to be able to track down the package/packages that
>>>>>>>> are
>>>>>>>> causing this. I have tried with a clean build dir and only building
>>>>>>>> nano
>>>>>>>> and I get it so it is something in
>>>>>>>> the getting environment ready steps. Is there a way I can easily
>>>>>>>> track down the build/builds that are causing this? Am I even on the
>>>>>>>> right
>>>>>>>> track in this thinking? Nothing fails
>>>>>>>> to build and other than task-native-sdk all result in what seem to
>>>>>>>> be
>>>>>>>> working packages.
>>>>>>>>
>>>>>>>> Any info on what or how to figure it out would be greatly
>>>>>>>> appreciated.
>>>>>>>> building fo

[oe][meta-perl] Update the HOMEPAGE variables that reference http://search.cpan.org

[J. S.]

http://search.cpan.org redirects traffic to https://metacpan.org

Update the HOMEPAGE variable to the newly resolved address.

Signed-off-by: Jason Schonberg 
---
 .../recipes-extended/mime-construct/mime-construct_1.11.bb  | 2 +-
 .../recipes-perl/libalgorithm/libalgorithm-diff-perl_1.15.bb| 2 +-
 meta-perl/recipes-perl/libauthen/libauthen-radius-perl_0.22.bb  | 2 +-
 meta-perl/recipes-perl/libauthen/libauthen-sasl-perl_2.16.bb| 2 +-
 meta-perl/recipes-perl/libcapture/libcapture-tiny-perl_0.48.bb  | 2 +-
 meta-perl/recipes-perl/libcgi/libcgi-perl_4.54.bb   | 2 +-
 meta-perl/recipes-perl/libdata/libdata-hexdump-perl_0.02.bb | 2 +-
 meta-perl/recipes-perl/libdigest/libdigest-hmac-perl_1.03.bb| 2 +-
 meta-perl/recipes-perl/libdigest/libdigest-sha1-perl_2.13.bb| 2 +-
 meta-perl/recipes-perl/libenv/libenv-perl_1.04.bb   | 2 +-
 .../recipes-perl/libextutils/libextutils-config-perl_0.008.bb   | 2 +-
 .../recipes-perl/libextutils/libextutils-cppguess-perl_0.26.bb  | 2 +-
 .../recipes-perl/libextutils/libextutils-helpers-perl_0.026.bb  | 2 +-
 .../libextutils/libextutils-installpaths-perl_0.012.bb  | 2 +-
 meta-perl/recipes-perl/libio/libio-socket-ssl-perl_2.074.bb | 2 +-
 meta-perl/recipes-perl/libipc/libipc-signal-perl_1.00.bb| 2 +-
 meta-perl/recipes-perl/liblocale/liblocale-gettext-perl_1.07.bb | 2 +-
 meta-perl/recipes-perl/libmime/libmime-charset-perl_1.012.2.bb  | 2 +-
 meta-perl/recipes-perl/libmime/libmime-types-perl_2.17.bb   | 2 +-
 .../recipes-perl/libmodule/libmodule-build-tiny-perl_0.039.bb   | 2 +-
 .../recipes-perl/libmodule/libmodule-runtime-perl_0.016.bb  | 2 +-
 meta-perl/recipes-perl/libnet/libnet-libidn-perl_0.12.bb| 2 +-
 meta-perl/recipes-perl/libnet/libnet-ssleay-perl_1.85.bb| 2 +-
 meta-perl/recipes-perl/libnet/libnet-telnet-perl_3.05.bb| 2 +-
 meta-perl/recipes-perl/libproc/libproc-waitstat-perl_1.00.bb| 2 +-
 meta-perl/recipes-perl/libterm/libterm-readkey-perl_2.38.bb | 2 +-
 meta-perl/recipes-perl/libtext/libtext-charwidth-perl_0.04.bb   | 2 +-
 meta-perl/recipes-perl/libtext/libtext-diff-perl_1.41.bb| 2 +-
 meta-perl/recipes-perl/libtext/libtext-wrapi18n-perl_0.06.bb| 2 +-
 .../recipes-perl/libxml/libxml-filter-buffertext-perl_1.01.bb   | 2 +-
 meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0134.bb  | 2 +-
 meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.57.bb| 2 +-
 32 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/meta-perl/recipes-extended/mime-construct/mime-construct_1.11.bb
b/meta-perl/recipes-extended/mime-construct/mime-construct_1.11.bb
index a5d28265d..b8787da74 100644
--- a/meta-perl/recipes-extended/mime-construct/mime-construct_1.11.bb
+++ b/meta-perl/recipes-extended/mime-construct/mime-construct_1.11.bb
@@ -3,7 +3,7 @@ DESCRIPTION = "Constructs and (by default) mails MIME
messages. \
It is entirely driven from the command line, it is \
designed to be used by other programs, or people who act \
like programs."
-HOMEPAGE = "http://search.cpan.org/~rosch/mime-construct/mime-construct";
+HOMEPAGE = 
"https://metacpan.org/release/ROSCH/mime-construct-1.11/view/mime-construct";
 SECTION = "mail"
 LICENSE = "GPL-2.0-or-later"
 LIC_FILES_CHKSUM =
"file://debian/copyright;md5=5e2e5da619ac8ef8c84767ccc4656e96"
diff --git a/meta-perl/recipes-perl/libalgorithm/libalgorithm-diff-perl_1.15.bb
b/meta-perl/recipes-perl/libalgorithm/libalgorithm-diff-perl_1.15.bb
index d87df0974..49c8ecf20 100644
--- a/meta-perl/recipes-perl/libalgorithm/libalgorithm-diff-perl_1.15.bb
+++ b/meta-perl/recipes-perl/libalgorithm/libalgorithm-diff-perl_1.15.bb
@@ -7,7 +7,7 @@ program.   It is guaranteed to find the *smallest
possible* set of \
 differences. \
 "
 SECTION = "libs"
-HOMEPAGE = "http://search.cpan.org/~nedkonz/Algorithm-Diff/";
+HOMEPAGE = "https://metacpan.org/release/NEDKONZ/Algorithm-Diff-${PV}";

 LICENSE = "Artistic-1.0 | GPL-1.0-or-later"
 LIC_FILES_CHKSUM =
"file://lib/Algorithm/Diff.pm;beginline=406;endline=409;md5=d393b8ad3b8994b9d0ae9299b8a8a1ee"
diff --git a/meta-perl/recipes-perl/libauthen/libauthen-radius-perl_0.22.bb
b/meta-perl/recipes-perl/libauthen/libauthen-radius-perl_0.22.bb
index ee7c4d750..be9c7af1c 100644
--- a/meta-perl/recipes-perl/libauthen/libauthen-radius-perl_0.22.bb
+++ b/meta-perl/recipes-perl/libauthen/libauthen-radius-perl_0.22.bb
@@ -4,7 +4,7 @@ DESCRIPTION = "The Authen::Radius module provides a
simple class that \
 Radius server. \
 "

-HOMEPAGE = "http://search.cpan.org/~manowar/RadiusPerl";
+HOMEPAGE = "https://metacpan.org/release/MANOWAR/RadiusPerl-${PV}";
 SECTION = "libs"

 LICENSE = "Artistic-2.0"
diff --git a/meta-perl/recipes-perl/libauthen/libauthen-sasl-perl_2.16.bb
b/meta-perl/recipes-perl/libauthen/libauthen-sasl-perl_2.16.bb
index 8545eb50f..998fcdc71 100644
--- a/meta-perl/recipes-perl/libauthen/libauthen-sasl-perl_2.16.bb
+++ b/meta-perl/re

[oe][meta-perl][master-next] Resend : Update the HOMEPAGE variables that reference http://search.cpan.org

[J. S.]

Patched against meta-openembedded master-next commit
c2fb0bd1ebe04f91e97913e1e15405af0e127078

 http://search.cpan.org redirects traffic to https://metacpan.org

 Update the HOMEPAGE variable to the newly resolved address.

Signed-off-by: Jason Schonberg 
---
 .../recipes-extended/mime-construct/mime-construct_1.11.bb  | 2 +-
 .../recipes-perl/libalgorithm/libalgorithm-diff-perl_1.15.bb| 2 +-
 meta-perl/recipes-perl/libauthen/libauthen-radius-perl_0.22.bb  | 2 +-
 meta-perl/recipes-perl/libauthen/libauthen-sasl-perl_2.16.bb| 2 +-
 meta-perl/recipes-perl/libcapture/libcapture-tiny-perl_0.48.bb  | 2 +-
 meta-perl/recipes-perl/libcgi/libcgi-perl_4.54.bb   | 2 +-
 meta-perl/recipes-perl/libdata/libdata-hexdump-perl_0.02.bb | 2 +-
 meta-perl/recipes-perl/libdigest/libdigest-hmac-perl_1.03.bb| 2 +-
 meta-perl/recipes-perl/libdigest/libdigest-sha1-perl_2.13.bb| 2 +-
 meta-perl/recipes-perl/libenv/libenv-perl_1.04.bb   | 2 +-
 .../recipes-perl/libextutils/libextutils-config-perl_0.008.bb   | 2 +-
 .../recipes-perl/libextutils/libextutils-cppguess-perl_0.26.bb  | 2 +-
 .../recipes-perl/libextutils/libextutils-helpers-perl_0.026.bb  | 2 +-
 .../libextutils/libextutils-installpaths-perl_0.012.bb  | 2 +-
 meta-perl/recipes-perl/libio/libio-socket-ssl-perl_2.074.bb | 2 +-
 meta-perl/recipes-perl/libipc/libipc-signal-perl_1.00.bb| 2 +-
 meta-perl/recipes-perl/liblocale/liblocale-gettext-perl_1.07.bb | 2 +-
 meta-perl/recipes-perl/libmime/libmime-charset-perl_1.012.2.bb  | 2 +-
 meta-perl/recipes-perl/libmime/libmime-types-perl_2.17.bb   | 2 +-
 .../recipes-perl/libmodule/libmodule-build-tiny-perl_0.039.bb   | 2 +-
 .../recipes-perl/libmodule/libmodule-runtime-perl_0.016.bb  | 2 +-
 meta-perl/recipes-perl/libnet/libnet-libidn-perl_0.12.bb| 2 +-
 meta-perl/recipes-perl/libnet/libnet-ssleay-perl_1.85.bb| 2 +-
 meta-perl/recipes-perl/libnet/libnet-telnet-perl_3.05.bb| 2 +-
 meta-perl/recipes-perl/libproc/libproc-waitstat-perl_1.00.bb| 2 +-
 meta-perl/recipes-perl/libterm/libterm-readkey-perl_2.38.bb | 2 +-
 meta-perl/recipes-perl/libtext/libtext-charwidth-perl_0.04.bb   | 2 +-
 meta-perl/recipes-perl/libtext/libtext-diff-perl_1.41.bb| 2 +-
 meta-perl/recipes-perl/libtext/libtext-wrapi18n-perl_0.06.bb| 2 +-
 .../recipes-perl/libxml/libxml-filter-buffertext-perl_1.01.bb   | 2 +-
 meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0134.bb  | 2 +-
 meta-perl/recipes-perl/libxml/libxml-sax-writer-perl_0.57.bb| 2 +-
 32 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/meta-perl/recipes-extended/mime-construct/mime-construct_1.11.bb
b/meta-perl/recipes-extended/mime-construct/mime-construct_1.11.bb
index a5d28265d..b8787da74 100644
--- a/meta-perl/recipes-extended/mime-construct/mime-construct_1.11.bb
+++ b/meta-perl/recipes-extended/mime-construct/mime-construct_1.11.bb
@@ -3,7 +3,7 @@ DESCRIPTION = "Constructs and (by default) mails MIME
messages. \
It is entirely driven from the command line, it is \
designed to be used by other programs, or people who act \
like programs."
-HOMEPAGE = "http://search.cpan.org/~rosch/mime-construct/mime-construct";
+HOMEPAGE = 
"https://metacpan.org/release/ROSCH/mime-construct-1.11/view/mime-construct";
 SECTION = "mail"
 LICENSE = "GPL-2.0-or-later"
 LIC_FILES_CHKSUM =
"file://debian/copyright;md5=5e2e5da619ac8ef8c84767ccc4656e96"
diff --git a/meta-perl/recipes-perl/libalgorithm/libalgorithm-diff-perl_1.15.bb
b/meta-perl/recipes-perl/libalgorithm/libalgorithm-diff-perl_1.15.bb
index d87df0974..49c8ecf20 100644
--- a/meta-perl/recipes-perl/libalgorithm/libalgorithm-diff-perl_1.15.bb
+++ b/meta-perl/recipes-perl/libalgorithm/libalgorithm-diff-perl_1.15.bb
@@ -7,7 +7,7 @@ program.   It is guaranteed to find the *smallest
possible* set of \
 differences. \
 "
 SECTION = "libs"
-HOMEPAGE = "http://search.cpan.org/~nedkonz/Algorithm-Diff/";
+HOMEPAGE = "https://metacpan.org/release/NEDKONZ/Algorithm-Diff-${PV}";

 LICENSE = "Artistic-1.0 | GPL-1.0-or-later"
 LIC_FILES_CHKSUM =
"file://lib/Algorithm/Diff.pm;beginline=406;endline=409;md5=d393b8ad3b8994b9d0ae9299b8a8a1ee"
diff --git a/meta-perl/recipes-perl/libauthen/libauthen-radius-perl_0.22.bb
b/meta-perl/recipes-perl/libauthen/libauthen-radius-perl_0.22.bb
index ee7c4d750..be9c7af1c 100644
--- a/meta-perl/recipes-perl/libauthen/libauthen-radius-perl_0.22.bb
+++ b/meta-perl/recipes-perl/libauthen/libauthen-radius-perl_0.22.bb
@@ -4,7 +4,7 @@ DESCRIPTION = "The Authen::Radius module provides a
simple class that \
 Radius server. \
 "

-HOMEPAGE = "http://search.cpan.org/~manowar/RadiusPerl";
+HOMEPAGE = "https://metacpan.org/release/MANOWAR/RadiusPerl-${PV}";
 SECTION = "libs"

 LICENSE = "Artistic-2.0"
diff --git a/meta-perl/recipes-perl/libauthen/libauthen-sasl-perl_2.16.bb
b/meta-perl/recipes-perl/libauthen/libauthen-sasl-perl_2.16.bb
index 8545eb50f..998fc

[oe][meta-oe][PATCH][master-next] nodejs : upgrade 16.14.2 -> 16.16.0

[J. S.]

>From 337d466bd4433159492b0e18a9f654b6047cc73c Mon Sep 17 00:00:00 2001
From: Jason Schonberg 
Date: Sun, 7 Aug 2022 22:44:49 -0400
Subject: [PATCH] Upgrade Nodejs from 16.14.2 to 16.16.0.  This is the latest
 LTS version of node.

The license file check sum changes because the new license file
mentions undici which is licensed under an MIT license.

This upgrade provides support for openssl 1.1.1q
Additional information about changes since the 16.14.2 release can be
found at 
https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V16.md

The existing 16.14.2 patches applied with fuzz against the 16.16.0
release.  So they have been updated with devtool.

Built against master-next
commit 8dee3f24aafab5574db396770342fd62ebbbad17

Signed-off-by: Jason Schonberg 
---
 ...e-running-gyp-files-for-bundled-deps.patch |  6 +--
 ...-liftoff-Correct-function-signatures.patch | 30 +-
 ...Use-32bit-cast-for-operand-on-mips32.patch |  6 +--
 ...Install-both-binaries-and-use-libdir.patch | 33 ++--
 .../nodejs/0002-Using-native-binaries.patch   | 22 ++-
 .../0004-v8-don-t-override-ARM-CFLAGS.patch   | 12 +++---
 ...5-add-openssl-legacy-provider-option.patch | 30 +++---
 .../nodejs/nodejs/big-endian.patch| 14 ++-
 .../nodejs/nodejs/mips-less-memory.patch  | 39 ---
 .../nodejs/nodejs/system-c-ares.patch | 11 +-
 .../{nodejs_16.14.2.bb => nodejs_16.16.0.bb}  |  4 +-
 11 files changed, 121 insertions(+), 86 deletions(-)
 rename meta-oe/recipes-devtools/nodejs/{nodejs_16.14.2.bb =>
nodejs_16.16.0.bb} (97%)

diff --git 
a/meta-oe/recipes-devtools/nodejs/nodejs/0001-Disable-running-gyp-files-for-bundled-deps.patch
b/meta-oe/recipes-devtools/nodejs/nodejs/0001-Disable-running-gyp-files-for-bundled-deps.patch
index d6e439ba2..d30a4d06b 100644
--- 
a/meta-oe/recipes-devtools/nodejs/nodejs/0001-Disable-running-gyp-files-for-bundled-deps.patch
+++ 
b/meta-oe/recipes-devtools/nodejs/nodejs/0001-Disable-running-gyp-files-for-bundled-deps.patch
@@ -1,4 +1,4 @@
-From 7d94bfe53beeb2d25eb5f2ff6b1d509df7e6ab80 Mon Sep 17 00:00:00 2001
+From 7e9d0939b803c07262d53ba2ea96ead44a4791fa Mon Sep 17 00:00:00 2001
 From: Zuzana Svetlikova 
 Date: Thu, 27 Apr 2017 14:25:42 +0200
 Subject: [PATCH] Disable running gyp on shared deps
@@ -8,10 +8,10 @@ Subject: [PATCH] Disable running gyp on shared deps
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/Makefile b/Makefile
-index 93d63110..79caaec2 100644
+index 3c48653..8b5a93b 100644
 --- a/Makefile
 +++ b/Makefile
-@@ -138,7 +138,7 @@ with-code-cache test-code-cache:
+@@ -147,7 +147,7 @@ with-code-cache test-code-cache:
  $(warning '$@' target is a noop)

  out/Makefile: config.gypi common.gypi node.gyp \
diff --git 
a/meta-oe/recipes-devtools/nodejs/nodejs/0001-liftoff-Correct-function-signatures.patch
b/meta-oe/recipes-devtools/nodejs/nodejs/0001-liftoff-Correct-function-signatures.patch
index d7005ae97..e7f67875f 100644
--- 
a/meta-oe/recipes-devtools/nodejs/nodejs/0001-liftoff-Correct-function-signatures.patch
+++ 
b/meta-oe/recipes-devtools/nodejs/nodejs/0001-liftoff-Correct-function-signatures.patch
@@ -1,7 +1,7 @@
-From dc3652c0abcdf8573fd044907b19d8eda7ca1124 Mon Sep 17 00:00:00 2001
+From 2b6e124f1959a7f20c37dd1589a0794499e4d9e5 Mon Sep 17 00:00:00 2001
 From: Khem Raj 
 Date: Wed, 20 Oct 2021 12:49:58 -0700
-Subject: [PATCH] [liftoff] Correct function signatures
+Subject: [PATCH] Correct function signatures

 Fixes builds on mips where clang reports an error
 ../deps/v8/src/wasm/baseline/mips/liftoff-assembler-mips.h:661:5:
error: no matching member function for call to 'Move'
@@ -10,13 +10,19 @@ Fixes builds on mips where clang reports an error

 Upstream-Status: Submitted
[https://chromium-review.googlesource.com/c/v8/v8/+/3235674]
 Signed-off-by: Khem Raj 
+
 ---
- src/wasm/baseline/liftoff-assembler.h | 6 +++---
- 1 file changed, 3 insertions(+), 3 deletions(-)
+ deps/v8/src/wasm/baseline/liftoff-assembler.h   | 6 +++---
+ deps/v8/src/wasm/baseline/mips/liftoff-assembler-mips.h | 2 +-
+ deps/v8/src/wasm/baseline/mips64/liftoff-assembler-mips64.h | 2 +-
+ .../src/wasm/baseline/riscv64/liftoff-assembler-riscv64.h   | 2 +-
+ 4 files changed, 6 insertions(+), 6 deletions(-)

+diff --git a/deps/v8/src/wasm/baseline/liftoff-assembler.h
b/deps/v8/src/wasm/baseline/liftoff-assembler.h
+index 19611fb..b035154 100644
 --- a/deps/v8/src/wasm/baseline/liftoff-assembler.h
 +++ b/deps/v8/src/wasm/baseline/liftoff-assembler.h
-@@ -613,7 +613,7 @@ class LiftoffAssembler : public TurboAss
+@@ -613,7 +613,7 @@ class LiftoffAssembler : public TurboAssembler {
void FinishCall(const ValueKindSig*, compiler::CallDescriptor*);

// Move {src} into {dst}. {src} and {dst} must be different.
@@ -25,7 +31,7 @@ Signed-off-by: Khem Raj 

// Parallel register move: For a list of tuples , move the
// {src} register of kind {kind} into {dst}. If {src} equals {dst}, ignore

Re: [oe] DISTRO=Angstrom on i686-generic build failure on base-image

[J. L.]

I keep erroring out on the same thing currently.



On Wed, Jun 23, 2010 at 7:29 AM, Arjan  wrote:

> Hello all,
>
> I'm new here, so maybe this is a known issue. But I couln't find the
> solution.
>
> Building  the 'base-image' using:
>
> DISTRO   = "angstrom-2008.1"
> MACHINE ?= "i686-generic"
> this error occurs:
>
>  | checking for cups-config... /usr/bin/cups-config
>> | checking cups/cups.h usability... no
>> | checking cups/cups.h presence... no
>> | checking for cups/cups.h... no
>> | configure: error: *** Sorry, cups-config present but cups/cups.h
>> missing.
>> | ERROR: Function do_configure failed
>> NOTE: package gtk+-native-2.20.0-r8.0: task do_configure: Failed
>> ERROR: TaskFailed event exception, aborting
>> ERROR: Build of
>> virtual:native:/media/disk/prj/alcons/angstrom/sources/openembedded/recipes/gtk+/gtk+_
>> 2.20.0.bb do_configure failed
>> ERROR: Task 2060
>> (virtual:native:/media/disk/prj/alcons/angstrom/sources/openembedded/recipes/gtk+/gtk+_
>> 2.20.0.bb, do_configure) failed with 256
>> ERROR:
>> 'virtual:native:/media/disk/prj/alcons/angstrom/sources/openembedded/recipes/gtk+/gtk+_
>> 2.20.0.bb' failed
>>
>>
>
> Anybody any ideas?
>
> Thanks.
> Arjan
>
> ___
> 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] so ... what's the proper way to report a build failure?

[J. L.]

The wiki link for me had nothing on it, I have been wondering the same
things myself.



On Tue, Jun 29, 2010 at 8:04 AM, John Willis
wrote:

> Hi Robert,
>
> >   given that i like to keep up with the OE dev branch and test build a
> > beagleboard-demo-image as necessary, what is the *encouraged* way to
> > report a new build failure?  on the OE list?  on the angstrom list?
> > tinderbox?
> >
> >   after a "git pull" earlier this morning, "realpath-1.15" fails to
> build.
> what
> > should i do with the error diagnostics?
>
> Pretty sure this has been suggested in the past ;-)
> (
> http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg02
> 876.html)
> but I'll say again, setting up Tinderbox
> (http://tinderbox.openembedded.net/) has to be a pretty good starting
> place
> to collaborate on build issues.
>
> It's really easy to setup
> (
> http://wiki.openembedded.net/index.php/How_do_I_send_automatic_success_and_
> failure_reports) and the classes will automatically deal with uploading of
> your fail logs/build info etc. so you can refer others to it (and for that
> matter, see if others are building the same packages without issue).
>
> Regards,
>
> John
>
>
>
> ___
> 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] so ... what's the proper way to report a build failure?

[J. L.]

Thank you very much for that!

any chance there is a good tutorial or something along those lines for
writing your own recipe for installing a program onto your platform? I have
tried the helloworld tutorials on your site and the gumstix wiki and I am
not having any luck in getting it to work for an actual program, I am trying
to get metasploit to compile for the gumstix overo fire.

On Tue, Jun 29, 2010 at 10:09 AM, John Willis  wrote:

> > The wiki link for me had nothing on it, I have been wondering the same
> > things myself.
>
> http://tinyurl.com/dl2na8 the link gets line-wrapped by my mailer (or the
> lists ;)).
>
> John
>
>
>
> ___
> 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] Does anyone have current recepies for some of these programs:

[J. L.]

I have not had much luck figuring out how to write my own recipies as
of yet I keep getting different errors for each one that I have yet to
understand. So I am hoping someone might have these already writen.
The platform I am using is a gumstix overo if that makes any
difference.

I am looking for the following:

Ruby 1.9.1
nmap 5.21
kismet from the development source
aircrack-ng preferably from dev source or 1.0 or higher
metasploit 3.4
openssl 1.0+
wireshark from dev source
blueprint
snort 2.8.6

Thanks for anyone sharing any of these recipies if you have them.

 Hopefully soon I can sort out what I am not getting in making a bb
file correctly

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

[oe] hping2 recipe failed to build fixed for gumstix overo

[J. L.]

Not sure if this is the correct way but I was able to sort out a
recipe that was failing to build for my gumstix overo. It was hping2
the fixed recipe is as follows. It seems to build now though have not
tested it works properly yet. Though this is not the most current
version of the program. Would be nice if someone knowledgable could
fix the recipe to pull and from the svn source so it would build the
most current version when the recipe runs.  thanks


DESCRIPTION = "hping is a command-line oriented TCP/IP packet \
assembler/analyzer. The interface is inspired to the ping(8) \
unix command, but hping isn't only able to send ICMP echo requests. \
It supports TCP, UDP, ICMP and RAW-IP protocols, has a traceroute \
mode, the ability to send files between a covered channel, and many \
other features."
HOMEPAGE = "http://www.hping.org/";
SECTION = "console/network"
LICENSE = "GPL"
PR = "r1"

SRC_URI = "http://www.hping.org/hping2.0.0-rc3.tar.gz \
   file://hping2_debian.patch \
   file://hping2_configure.patch"
S = "${WORKDIR}/hping2-rc3"

inherit siteinfo


TARGET_CC_ARCH += "${LDFLAGS}"

#
# We've patched configure to accept byte order and ostype as env
# variables Pass those values in to stop it trying to figure it out
# by itself.
# NOTE: The configure script is not an autoconf script.
#
do_configure() {
# Additional flag based on target endiness (see siteinfo.bbclass)
BYTEORDER="$...@base_conditional('SITEINFO_ENDIANESS', 'le',
'__LITTLE_ENDIAN_BITFIELD', '__BIG_ENDIAN_BITFIELD', d)}"
oenote Determined byteorder as: $BYTEORDER
BYTEORDER="${BYTEORDER}" CONFIGOSTYPE="LINUX" ./configure
}

#
# Instead of patching the install we do things manually here
#
do_install() {
install -m 0755 -d ${D}${sbindir} ${D}/${mandir} ${D}${docdir}/hping2
install -m 0755 hping2 ${D}/${sbindir}
install -m 0644 docs/hping2.8 ${D}/${mandir}
install -m 0644 docs/HPING2-HOWTO.txt docs/HPING2-IS-OPEN \
docs/MORE-FUN-WITH-IPID docs/SPOOFED_SCAN.txt \
docs/AS-BACKDOOR docs/APD.txt ${D}${docdir}/hping2
}

SRC_URI[md5sum] = "029bf240f2e0545b664b2f8b9118d9e8"
SRC_URI[sha256sum] =
"f59292de39b9a4010414bd120a494226399767148efa37278bd53d9613167964"

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

Re: [oe] Problem of libpcap

[J. L.]

Mine is building fine here are the files incase you are using a older
pull of OE which it looks like you might be. I attacked all the
patches for it as well. Hope this helps you out. I have noticed there
are a bunch that are not building and or are WAY WAY out of date.


require libpcap.inc

PR = "r6"
SRC_URI = "http://www.tcpdump.org/release/libpcap-${PV}.tar.gz";
SRC_URI += "file://aclocal.patch"
SRC_URI += "file://ieee80215-arphrd.patch"
SRC_URI += "file://ldflags.patch"
SRC_URI += 
"file://0001-Fix-some-problems-that-show-up-in-autoconf-2.64-and-.patch"

do_configure_prepend() {
cat ${S}/aclocal.m4 >>${S}/acinclude.m4
}

do_compile () {
oe_runmake
rm -f *.o
oe_runmake shared
}

do_install () {
install -d ${D}${libdir}
install -d ${D}${bindir}
oe_runmake install DESTDIR=${D}
oe_runmake install-shared DESTDIR=${D}
oe_libinstall -a -so libpcap ${D}${libdir}

install -d ${D}${includedir}/pcap
install -m 0644 pcap/pcap.h ${D}${includedir}/pcap/pcap.h
install -m 0644 pcap/namedb.h ${D}${includedir}/pcap/namedb.h
install -m 0644 pcap/bpf.h ${D}${includedir}/pcap/bpf.h
}



SRC_URI[md5sum] = "9ad1358c5dec48456405eac197a46d3d"
SRC_URI[sha256sum] =
"a214c4e1d7e22a758f66fe1d08f0ce41c3ba801a4c13dd1188e1e38288ac73c0"




DESCRIPTION = "Network Packet Capture Library"
HOMEPAGE = "http://www.tcpdump.org/";
SECTION = "libs/network"
LICENSE = "BSD"
DEPENDS = "bluez-libs flex-native bison-native"

PR = "r3"

# Don't forget to edit shared.patch to have the correct version number inside
SRC_URI = "http://www.tcpdump.org/release/libpcap-${PV}.tar.gz \
   file://shared.patch"

inherit autotools

EXTRA_OECONF = "--with-pcap=linux"

CPPFLAGS_prepend = "-I${S} "
CFLAGS_prepend = "-I${S} "
CXXFLAGS_prepend = "-I${S} "

do_configure_prepend () {
if [ ! -e acinclude.m4 ]; then
cat aclocal.m4 > acinclude.m4
fi
}

do_install_append () {
install -d ${D}${includedir}/net
install -d ${D}${datadir}/aclocal
ln -sf ../pcap-bpf.h ${D}${includedir}/net/bpf.h
install -m 0644 acinclude.m4 ${D}${datadir}/aclocal/libpcap.m4
}






On Fri, Jul 16, 2010 at 8:12 AM, saleh usman  wrote:
>
> I am bitbaking console-iamge but getting error of not building libpcap? I've 
> bitbake libpcap separately but it is also not building. Its bitbake fails 
> during configure. These are shown in following terminal logs. Kindly tell me 
> how to remove this error?
> Saleh
>
> [sa...@localhost ~]$ bitbake console-image
> NOTE: Handling BitBake files: \ (8169/8169) [100 %]
> NOTE: Parsing finished. 7530 cached, 309 parsed, 330 skipped, 0 masked.
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing runqueue
> NOTE: Running task 1774 of 3226 (ID: 1317, 
> /sdr/openembedded/recipes/libpcap/libpcap_1.0.0.bb, do_configure)
> ERROR: function do_configure failed
> ERROR: log data follows 
> (/sdr/build/tmp/work/armv5te-angstrom-linux-gnueabi/libpcap-1.0.0-r6/temp/log.do_configure.2961)
> | cat: 
> /sdr/build/tmp/work/armv5te-angstrom-linux-gnueabi/libpcap-1.0.0-r6/libpcap-1.0.0/aclocal.m4:
>  No such file or directory
> NOTE: Task failed: 
> /sdr/build/tmp/work/armv5te-angstrom-linux-gnueabi/libpcap-1.0.0-r6/temp/log.do_configure.2961
> ERROR: TaskFailed event exception, aborting
> ERROR: Build of /sdr/openembedded/recipes/libpcap/libpcap_1.0.0.bb 
> do_configure failed
> ERROR: Task 1317 (/sdr/openembedded/recipes/libpcap/libpcap_1.0.0.bb, 
> do_configure) failed
> NOTE: Tasks Summary: Attempted 1773 tasks of which 1773 didn't need to be 
> rerun and 1 failed.
> ERROR: '/sdr/openembedded/recipes/libpcap/libpcap_1.0.0.bb' failed
>
>
> [sa...@localhost openembedded]$ bitbake libpcap
> NOTE: Handling BitBake files: \ (8169/8169) [100 %]
> NOTE: Parsing finished. 7530 cached, 309 parsed, 330 skipped, 0 masked.
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing runqueue
> NOTE: Running task 1695 of 2385 (ID: 7, 
> /sdr/openembedded/recipes/libpcap/libpcap_1.0.0.bb, do_configure)
> ERROR: function do_configure failed
> ERROR: log data follows 
> (/sdr/build/tmp/work/armv5te-angstrom-linux-gnueabi/libpcap-1.0.0-r6/temp/log.do_configure.11281)
> | cat: 
> /sdr/build/tmp/work/armv5te-angstrom-linux-gnueabi/libpcap-1.0.0-r6/libpcap-1.0.0/aclocal.m4:
>  No such file or directory
> NOTE: Task failed: 
> /sdr/build/tmp/work/armv5te-angstrom-linux-gnueabi/libpcap-1.0.0-r6/temp/log.do_configure.11281
> ERROR: TaskFailed event exception, aborting
> ERROR: Build of /sdr/openembedded/recipes/libpcap/libpcap_1.0.0.bb 
> do_configure failed
> ERROR: Task 7 (/sdr/openembedded/recipes/libpcap/libpcap_1.0.0.bb, 
> do_configure) failed
> NOTE: Tasks Summary: Attempted 1694 tasks of which 1694 didn't need to be 
> rerun and 1 failed.
> ERROR: '/sdr/openembedded/recipes/libpcap/libpcap_1.0.0.bb' failed
>
>
> _

[oe] spca5xx does not build

[J. L.]

I was trying to build this for my gumstix and first it had a DL
location issue which I fixed and its now downloading the pacakge but
fails on the build with the following errors. Hope someone can make
some sense of this as I have no clue nor does googling help any seems
as though according to posts been unbuildable for a couple years? the
earliest post I found complaining was 06 then 07 a update to file was
done but still did not build correctly then according to the boards. I
also tried gspcav1 as well since its a similar driver and that one
fails as well.



NOTE: Running task 516 of 750 (ID: 9,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/spca5xx/spca5xx_20060501.bb,
do_compile)
ERROR: function do_compile failed
ERROR: log data follows
(/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/spca5xx-20060501-r81/temp/log.do_compile.17684)
| NOTE: make -e MAKEFLAGS=
KERNELDIR=/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel
CC=ccache arm-angstrom-linux-gnueabi-gcc
LD=arm-angstrom-linux-gnueabi-ld
|Building SPCA5XX driver for 2.5/2.6 kernel.
|Remember: you must have read/write access to your kernel source tree.
| make -C 
/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel
SUBDIRS=/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/spca5xx-20060501-r81/spca5xx-20060501
CC="ccache arm-angstrom-linux-gnueabi-gcc " modules
| make[1]: Entering directory
`/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel'
| scripts/Makefile.build:49: *** CFLAGS was changed in
"/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/spca5xx-20060501-r81/spca5xx-20060501/Makefile".
Fix it to use EXTRA_CFLAGS.  Stop.
| make[1]: *** 
[_module_/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/spca5xx-20060501-r81/spca5xx-20060501]
Error 2
| make[1]: Leaving directory
`/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel'
| make: *** [default] Error 2
| FATAL: oe_runmake failed
NOTE: Task failed:
/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/spca5xx-20060501-r81/temp/log.do_compile.17684
ERROR: TaskFailed event exception, aborting
ERROR: Build of
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/spca5xx/spca5xx_20060501.bb
do_compile failed
ERROR: Task 9 
(/home/vdubhack/overo-oe/org.openembedded.dev/recipes/spca5xx/spca5xx_20060501.bb,
do_compile) failed
NOTE: Tasks Summary: Attempted 515 tasks of which 510 didn't need to
be rerun and 1 failed.
ERROR: 
'/home/vdubhack/overo-oe/org.openembedded.dev/recipes/spca5xx/spca5xx_20060501.bb'
failed

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

Re: [oe] spca5xx does not build

[J. L.]

i tried editing the make file its self where it says but when I
rebuilt it it just un tared it again and rewrote my change. Do I need
to figure out how to make it use that in the bb file itself? Sorry for
the basic questions just unsure

On Sat, Jul 17, 2010 at 2:53 AM, Holger Freyther  wrote:
>
>> | make[1]: Entering directory
>> `/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel'
>> | scripts/Makefile.build:49: *** CFLAGS was changed in
>> "/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/spca5xx-20060501-r81/spca5xx-20060501/Makefile".
>> Fix it to use EXTRA_CFLAGS.  Stop.
>>
>
> ___
> 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] spca5xx does not build

[J. L.]

I just tried adding EXTRA_CFLAGS in the bb file and still errors in
the same way. I also cleaned it to make sure before building.

Also there is an error stating an implasibly old time stamp from 1964?



On Sat, Jul 17, 2010 at 2:53 AM, Holger Freyther  wrote:
>
>> | make[1]: Entering directory
>> `/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel'
>> | scripts/Makefile.build:49: *** CFLAGS was changed in
>> "/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/spca5xx-20060501-r81/spca5xx-20060501/Makefile".
>> Fix it to use EXTRA_CFLAGS.  Stop.
>>
>
> ___
> 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] spca5xx does not build

[J. L.]

Can anyone else help me out with this for building? I am at a loss as
to whats up with this.

Thanks



On Sat, Jul 17, 2010 at 1:51 PM, J. L.  wrote:
> I just tried adding EXTRA_CFLAGS in the bb file and still errors in
> the same way. I also cleaned it to make sure before building.
>
> Also there is an error stating an implasibly old time stamp from 1964?
>
>
>
> On Sat, Jul 17, 2010 at 2:53 AM, Holger Freyther  
> wrote:
>>
>>> | make[1]: Entering directory
>>> `/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel'
>>> | scripts/Makefile.build:49: *** CFLAGS was changed in
>>> "/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/spca5xx-20060501-r81/spca5xx-20060501/Makefile".
>>> Fix it to use EXTRA_CFLAGS.  Stop.
>>>
>>
>> ___
>> 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] GPSBABLE -- fixed recipe

[J. L.]

It had bad checksums here is the fixed file, hope this helps


SECTION = "console/utils"
DESCRIPTION = "GPS data converter"
DEPENDS = "expat virtual/libusb0"
HOMEPAGE = "http://www.gpsbabel.org/";
LICENSE = "GPL"

SRC_URI = "http://www.gpsbabel.org/plan9.php?dl=gpsbabel-${PV}.tar.gz \
   file://autotools.patch"

inherit autotools pkgconfig

SRC_URI[md5sum] = "d41d8cd98f00b204e9800998ecf8427e"
SRC_URI[sha256sum] =
"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"

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

Re: [oe] GPSBABLE -- fixed recipe

[J. L.]

On Mon, Jul 19, 2010 at 11:51 PM, Stefan Schmidt
 wrote:
> Hello.
>
> On Mon, 2010-07-19 at 15:12, J. L.  wrote:
>> It had bad checksums here is the fixed file, hope this helps
>
> Did you check what the problem was with the checksum? Like the tarball changes
> upstream but stayed under the same name?

Yes I did check that I believe, it built properly after doing so, but
I am not able to complete my full build as of yet due to other build
issues.


>
>> SECTION = "console/utils"
>> DESCRIPTION = "GPS data converter"
>> DEPENDS = "expat virtual/libusb0"
>> HOMEPAGE = "http://www.gpsbabel.org/";
>> LICENSE = "GPL"
>>
>> SRC_URI = "http://www.gpsbabel.org/plan9.php?dl=gpsbabel-${PV}.tar.gz \
>>            file://autotools.patch"
>>
>> inherit autotools pkgconfig
>>
>> SRC_URI[md5sum] = "d41d8cd98f00b204e9800998ecf8427e"
>> SRC_URI[sha256sum] =
>> "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
>
> Please prepare a git patch that could get applied easily. That would include
> that you fix the recipe as you see fit, commit your changes into git, prepare 
> a
> patch (git format-patch -1) and then send it to the list (with git send-email 
> or
> with your normal mail reader).
>
> This workflow looks like more work in the beginning but it pays off for you 
> and
> us within the first two patches. :)

I am a VERY new beginner in all of this and would love to learn how to
do it all properly as I have found a few recipes that I want to build
but have issues. I will figure out how to do what your saying properly
and send in the patch.

Do I need to put my recipe back to the original in OE first before
making the patch? If this is way off you can just tell me to search on
google. Thanks for taking the time to let me know though I appreciate
it.

regards
Jeremy



>
> regards
> Stefan Schmidt
>
> ___
> 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] Looking for some help on making a recipe -- newbie needing help

[J. L.]

First sorry for the basic questions here,
I am in the process of trying to figure out how to make my own recipe
for a new version of a program than what exists. I am trying to write
a recipe for aircrack-ng 1.1, Where I am now is its failing unable to
find some files. I think this is because i am missing something in my
recipe. I tried looking at the previous versions and patch files but I
do not understand how to put whats in the patch file into my new
recipe so it would build in a similar manner. Is there a way I can
take what they patched to the original recipe and incorporate it into
my recipe? Or is there an easy way to read whats in the patch file and
incorporate it into a new recipe? I have posted both the recipe I
wrote and the patch from the original recipe. I am not looking to get
spoon fed but I am at a total loss here and would really like to get a
grasp on this as there a bunch of existing recipes that I would like
to update to more current versions, and I am sure once I get through
one or two of making my own I will get it better. I have read the OE
manual and also the examples from gumstix. I am running my OE on the
overo branch if that makes any difference. Thanks for your time and
any help you can share with me. Hope to be more useful to the cause
soon. Lastly if any of this didn't make sense let me know so I can try
and clarify it better for everyone.

my aircrack-ng recipe:
DESCRIPTION = "Aircrack-ng is a set of tools for wep key statistical cracking"
HOMEPAGE = "http://www.aircrack-ng.org/";
SECTION = "console/network"
LICENSE = "GPLv2"
DEPENDS = "openssl zlib sqlite3"
PR = "r0"
PN = "aircrack-ngtest"

SRC_URI = "http://download.aircrack-ng.org/aircrack-ng-1.1.tar.gz";

S = "${WORKDIR}"
OETMP = ${OVEROTOP}/tmp

SBINFILES = "airodump-ng aireplay-ng airmon-ng airtun-ng"
BINFILES = "aircrack-ng airdecap-ng packetforge-ng ivstools kstats makeivs"

do_install() {
install -d ${D}/${sbindir}
for i in ${SBINFILES}; do
install -m 0755 $i ${D}/${sbindir}
done

install -d ${D}/${bindir}
for i in ${BINFILES}; do
install -m 0755 $i ${D}/${bindir}
done
}


SRC_URI[md5sum] = "f7a24ed8fad122c4187d06bfd6f998b4"
SRC_URI[sha256sum] =
"b136b549b7d2a2751c21793100075ea43b28de9af4c1969508bb95bcc92224ad"



Here is the patch from the original .9.3  aircrack-ng recipe:
diff -urN aircrack-ng-0.9.3.orig/Makefile aircrack-ng-0.9.3/Makefile
--- aircrack-ng-0.9.3.orig/Makefile 2008-02-24 20:22:35.0 +0100
+++ aircrack-ng-0.9.3/Makefile  2009-04-09 07:53:12.0 +0200
@@ -3,7 +3,7 @@

 CC  = gcc
 CFLAGS  ?= -g -W -Wall -O3
-OPTFLAGS= -D_FILE_OFFSET_BITS=64
+OPTFLAGS= -D_FILE_OFFSET_BITS=64 $(LDFLAGS)

 iCC = /opt/intel/cc/9.0/bin/icc
 iCFLAGS = -w -mcpu=pentiumpro -march=pentiumpro

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

Re: [oe] gcc/gettext isssue ?

[J. L.]

I notice that for a bunch of recipes that build in my image. and its
always a gettext error like that but it doesnt stop the build



On Thu, Jul 22, 2010 at 1:41 PM, Frans Meulenbroeks
 wrote:
> When building gcc I get:
> NOTE: Gettext required but not in DEPENDS for file
> /home/frans/oe/tmp_angstrom/work/nios2-linux/gcc-cross-4.1.2-r23.1/gcc-4.1.2/intl/
> configure.ac.
> Missing inherit gettext?
>
> but gcc-common.inc (which is included indirectly from every gcc recipe)
> says:
> gcc-common.inc:inherit autotools gettext
>
> What is wrong here?
> How can I resolve this?
>
> Frans
> ___
> 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] What to do about the poor bitbake Quality Control?

[J. L.]

I agree with you AJ, its become a serious pain to just get a built
image. I myself have only built once completely and have yet to again
since figuring out the changes I needed to make to that image. I would
like to help myself but someone like me whose not very competent in
this area finds the documentation a tad lacking to properly learn the
ways to help. I still have yet to figure out how to even get my own
program from the net to build with OE as just following the hello
world does not seem to be enough for me to grasp how to do it with an
actual problem. Which runs me into my next issue I can not properly
modify the way some programs build to get the features I want.

I have also noticed on the gumstix boards while most of the time it
seems its the same errors people get, every once in awhile you see
some people with one issue and others with another.

I am sure this wont be of much use as a post but figured I would chime
in from an inexperienced beginner trying to get a footing in here and
to actually be able to use things properly.



On Sat, Aug 14, 2010 at 8:46 AM, AJ ONeal  wrote:
> This is about the 4th time that I've `rm -rf`-d everything and started from
> scratch and never yet got a working `bitbake omap3-console-image`
>
> Every time I `git pull` it's a different set of problems. It's never the
> same package twice, but they never all compile for the basic console image
> anywhere from 4 to 20 hours in.
>
> Fortunately, I do have a machine that did build omap3-console-image a few
> weeks ago at work. But I've never been able to get it on my machine at home
> (same os) to start playing around with.
>
> What needs to happen in order for things to git checked that they work with
> at least a few common meta-tasks before being pushed out?
> And is there anything I can do to help? (Donate some machine time to run
> tests, for example)
>
>
> Obviously, we all have our day jobs and whatnot, but this is becoming really
> frustrating for me and I'd like to see things improve.
>
> AJ ONeal
> ___
> 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] What to do about the poor bitbake Quality Control?

[J. L.]

Right on thanks that does seem to answer a couple questions I have
come across so far especially the devshell. I will give making my
recipe another shot again today and see if I can get further with it
or even crazier get it to build correctly. Thanks again hopefully we
will see some other input to your original statement.



On Sat, Aug 14, 2010 at 10:06 AM, AJ ONeal  wrote:
> I've been compiling some common general issues
> http://fastr.github.com/articles/Troubleshooting-bitbake.html
>
> Here's some quick-n-dirty instructions akin to using devshell:
>
>
>   1. cd ${OVEROTOP}/tmp/work/${ARCH}/${PACKAGE}_${VER}_r${REV}/${BUILD}
>      - ${ARCH} is probably armv7a-angstrom-linux-gnueabi
>      - ${BUILD} is a directory which is not NOT src or temp such as the
>      package name or git or trunk or svn
>      - ${VER} and ${REV} - duh.
>   2. `cp ../temp/run.do_compile.${OLD_PID}
>      - ${OLD_PID} is a number like 3597 or 4352
>      - do_compile could be any task - do_install, etc
>   3. vim run.do_compile.1234
>      1. comment out do_compile() (or whatever)
>      2. add bash --norc
>   4. ./run.do_compile.1234 will put you in an environment with all
>   variables set
>   5. make (or whatever) to try to build, debug issues
>   6. exit (when done to go back to shell without run.do_compile settings)
>
> This is based on the tip on openembedded wiki, but it took me a while to
> understand what theirs meant so I cleaned it up in a fashion which is
> hopefully crystal clear.
>
> AJ ONeal
>
> On Sat, Aug 14, 2010 at 10:16 AM, J. L.  wrote:
>
>> I agree with you AJ, its become a serious pain to just get a built
>> image. I myself have only built once completely and have yet to again
>> since figuring out the changes I needed to make to that image. I would
>> like to help myself but someone like me whose not very competent in
>> this area finds the documentation a tad lacking to properly learn the
>> ways to help. I still have yet to figure out how to even get my own
>> program from the net to build with OE as just following the hello
>> world does not seem to be enough for me to grasp how to do it with an
>> actual problem. Which runs me into my next issue I can not properly
>> modify the way some programs build to get the features I want.
>>
>> I have also noticed on the gumstix boards while most of the time it
>> seems its the same errors people get, every once in awhile you see
>> some people with one issue and others with another.
>>
>> I am sure this wont be of much use as a post but figured I would chime
>> in from an inexperienced beginner trying to get a footing in here and
>> to actually be able to use things properly.
>>
>>
>>
>> On Sat, Aug 14, 2010 at 8:46 AM, AJ ONeal  wrote:
>> > This is about the 4th time that I've `rm -rf`-d everything and started
>> from
>> > scratch and never yet got a working `bitbake omap3-console-image`
>> >
>> > Every time I `git pull` it's a different set of problems. It's never the
>> > same package twice, but they never all compile for the basic console
>> image
>> > anywhere from 4 to 20 hours in.
>> >
>> > Fortunately, I do have a machine that did build omap3-console-image a few
>> > weeks ago at work. But I've never been able to get it on my machine at
>> home
>> > (same os) to start playing around with.
>> >
>> > What needs to happen in order for things to git checked that they work
>> with
>> > at least a few common meta-tasks before being pushed out?
>> > And is there anything I can do to help? (Donate some machine time to run
>> > tests, for example)
>> >
>> >
>> > Obviously, we all have our day jobs and whatnot, but this is becoming
>> really
>> > frustrating for me and I'd like to see things improve.
>> >
>> > AJ ONeal
>> > ___
>> > 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
>

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

Re: [oe] Getting Started with bitbake as a developer?

[J. L.]

I think AJ meant there needs to be another more in depth one. I would
agree with that myself. That one barely touches anything about OE to
me its to simple of an example.



On Sun, Aug 22, 2010 at 1:38 AM, Frans Meulenbroeks
 wrote:
> 2010/8/22 AJ ONeal :
>> http://www.google.com/search?q=openembedded+bitbake
>> http://www.google.com/search?q=bitbake+getting+started
>>
>> Notice that the only useful information for a dev on there is the gumstix
>> link, which is apparently not up to par with the oe standards.
>> http://www.gumstix.net/Setup-and-Programming/view/Build-system-overview/Hello-world-tutorial/111.html
>>
>> May I suggest that someone put up a doc on the oe wiki for this? or if there
>> is one, put keywords on it so it gets a ranking?
>>
>> I would be happy to write one, but I don't know enough yet.
>>
>> AJ ONeal
>
> Can we reuse or refer to the gumstix tut?
> Or could the gumstix tut be an appendix to the bitbake manual?
> http://bitbake.berlios.de/manual/
>
> I feel it is useful to have a getting started doc. The manual on
> itself is too overwhelming.
>
> Frans
>
> ___
> 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] base_files 3.0.14 has dangling symlinks

[J. L.]

While trying to do a new image I came across this error is it anything
to worry about? Or something that needs to be fixed?  Here is the
error:

NOTE: Running task 8590 of 11052 (ID: 251,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/base-files/base-files_3.0.14.bb,
do_package)
NOTE: base-files contains dangling symlink to /media/net
NOTE: base-files contains dangling symlink to /media/card
NOTE: base-files contains dangling symlink to /media/ram
NOTE: base-files contains dangling symlink to /media/cf

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

[oe] Build failing on glib

[J. L.]

I am building for an overo fire and have tried cleaning the recipe
deleting the entire tmp dir and still get stuck on this one file. I
have no clue how to even try to fix this one for myself would
appreciate some help. Here is as much of the error left in the
terminal:

| checking whether to enable garbage collector friendliness... no
| checking whether to disable memory pools... no
| checking for arm-angstrom-linux-gnueabi-gcc... (cached)
arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8
-mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb
| checking whether we are using the GNU C compiler... (cached) yes
| checking whether arm-angstrom-linux-gnueabi-gcc -march=armv7-a
-mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
-mno-thumb accepts -g... (cached) yes
| checking for arm-angstrom-linux-gnueabi-gcc -march=armv7-a
-mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
-mno-thumb option to accept ISO C89... (cached) none needed
| checking dependency style of arm-angstrom-linux-gnueabi-gcc
-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
-mthumb-interwork -mno-thumb... (cached) gcc3
| checking how to run the C preprocessor... arm-angstrom-linux-gnueabi-gcc -E
| checking for arm-angstrom-linux-gnueabi-c++...
arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8
-mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb
| checking whether we are using the GNU C++ compiler... yes
| checking whether arm-angstrom-linux-gnueabi-g++ -march=armv7-a
-mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
-mno-thumb accepts -g... yes
| checking dependency style of arm-angstrom-linux-gnueabi-g++
-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
-mthumb-interwork -mno-thumb... gcc3
| checking for arm-angstrom-linux-gnueabi-gcc... (cached)
arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8
-mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb
| checking whether we are using the GNU C compiler... (cached) yes
| checking whether arm-angstrom-linux-gnueabi-gcc -march=armv7-a
-mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
-mno-thumb accepts -g... (cached) yes
| checking for arm-angstrom-linux-gnueabi-gcc -march=armv7-a
-mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
-mno-thumb option to accept ISO C89... (cached) none needed
| checking dependency style of arm-angstrom-linux-gnueabi-gcc
-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
-mthumb-interwork -mno-thumb... (cached) gcc3
| checking whether arm-angstrom-linux-gnueabi-gcc -march=armv7-a
-mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
-mno-thumb and cc understand -c and -o together... yes
| checking for special C compiler options needed for large files... no
| checking for _FILE_OFFSET_BITS value needed for large files... 64
| checking for pkg-config...
/home/vdubhack/overo-oe/tmp/sysroots/i686-linux/usr/bin/pkg-config
| checking for gawk... (cached) gawk
| checking for perl5... no
| checking for perl... perl
| checking for indent... no
| checking for perl... /usr/bin/perl
| checking for a Python interpreter with version >= 2.4... python
| checking for python...
/home/vdubhack/overo-oe/tmp/sysroots/i686-linux/usr/bin/python
| checking for python version... 2.6
| checking for python platform... linux2
| checking for python script directory... ${prefix}/lib/python2.6/site-packages
| checking for python extension module directory...
${exec_prefix}/lib/python2.6/site-packages
| checking for iconv_open... yes
| checking for grep that handles long lines and -e... /bin/grep
| checking for egrep... /bin/grep -E
| checking whether we are using the GNU C Library 2.1 or newer... yes
| checking Whether to cache iconv descriptors... no
| checking for ANSI C header files... yes
| checking for sys/types.h... yes
| checking for sys/stat.h... yes
| checking for stdlib.h... yes
| checking for string.h... yes
| checking for memory.h... yes
| checking for strings.h... yes
| checking for inttypes.h... yes
| checking for stdint.h... yes
| checking for unistd.h... yes
| checking for inflate in -lz... yes
| checking zlib.h usability... yes
| checking zlib.h presence... yes
| checking for zlib.h... yes
| checking locale.h usability... yes
| checking locale.h presence... yes
| checking for locale.h... yes
| checking for LC_MESSAGES... yes
| checking libintl.h usability... yes
| checking libintl.h presence... yes
| checking for libintl.h... yes
| checking for ngettext in libc... yes
| checking for dgettext in libc... yes
| checking for bind_textdomain_codeset... yes
| checking for msgfmt...
/home/vdubhack/overo-oe/tmp/sysroots/i686-linux/usr/bin/msgfmt
| checking for dcgettext... yes
| checking if msgfmt accepts -c... yes
| checking for gmsgfmt...
/home/vdubhack/overo-oe/tmp/sysroots/i686-linux/usr/bin/msgfmt
| checking for xgettext...
/home/vdubhack/overo-oe/tmp/sysroots/i686-linux/usr/bin/xgettext
| checking for catalogs to be

Re: [oe] Build failing on glib

[J. L.]

Sorry I forgot to try building it on its own before posting but it
built and my image is going on now. Though I find it weird that it
would fail even after deleting the temp file and cleaning. Though now
here is a new message I caught. Saying another package may break
because of glibc and a un matching library.

For the record I am building on a ubuntu 9.10 machine in case that may help.

NOTE: Running task 553 of 813 (ID: 284,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/glibc/glibc_2.9.bb,
do_package)
NOTE: generation of binary locales disabled. this may break i18n!
NOTE: the following files were installed but not shipped in any package:
NOTE:   /etc/rpc
NOTE: Multiple libraries (libnss_nisplus.so.2, libnss_hesiod.so.2,
libnss_nis.so.2) found, but LEAD_SONAME 'libc.so' doesn't match any of
them
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: package glibc-dbg skipped


On Mon, Aug 23, 2010 at 2:52 PM, Steve Sakoman  wrote:
> On Mon, Aug 23, 2010 at 2:37 PM, J. L.  wrote:
>> I am building for an overo fire and have tried cleaning the recipe
>> deleting the entire tmp dir and still get stuck on this one file. I
>> have no clue how to even try to fix this one for myself would
>> appreciate some help.
>
> I've never seen this issue myself, but you might try:
>
> bitbake glib-2.0-native
>
> And then try to build your image.
>
> Let us know if this helps.
>
> Steve
>
> Here is as much of the error left in the
>> terminal:
>>
>> | checking whether to enable garbage collector friendliness... no
>> | checking whether to disable memory pools... no
>> | checking for arm-angstrom-linux-gnueabi-gcc... (cached)
>> arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8
>> -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb
>> | checking whether we are using the GNU C compiler... (cached) yes
>> | checking whether arm-angstrom-linux-gnueabi-gcc -march=armv7-a
>> -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
>> -mno-thumb accepts -g... (cached) yes
>> | checking for arm-angstrom-linux-gnueabi-gcc -march=armv7-a
>> -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
>> -mno-thumb option to accept ISO C89... (cached) none needed
>> | checking dependency style of arm-angstrom-linux-gnueabi-gcc
>> -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
>> -mthumb-interwork -mno-thumb... (cached) gcc3
>> | checking how to run the C preprocessor... arm-angstrom-linux-gnueabi-gcc -E
>> | checking for arm-angstrom-linux-gnueabi-c++...
>> arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mtune=cortex-a8
>> -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb
>> | checking whether we are using the GNU C++ compiler... yes
>> | checking whether arm-angstrom-linux-gnueabi-g++ -march=armv7-a
>> -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
>> -mno-thumb accepts -g... yes
>> | checking dependency style of arm-angstrom-linux-gnueabi-g++
>> -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
>> -mthumb-interwork -mno-thumb... gcc3
>> | checking for arm-angstrom-linux-gnueabi-gcc... (cached)
>> arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8
>> -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb
>> | checking whether we are using the GNU C compiler... (cached) yes
>> | checking whether arm-angstrom-linux-gnueabi-gcc -march=armv7-a
>> -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
>> -mno-thumb accepts -g... (cached) yes
>> | checking for arm-angstrom-linux-gnueabi-gcc -march=armv7-a
>> -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
>> -mno-thumb option to accept ISO C89... (cached) none needed
>> | checking dependency style of arm-angstrom-linux-gnueabi-gcc
>> -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
>> -mthumb-interwork -mno-thumb... (cached) gcc3
>> | checking whether arm-angstrom-linux-gnueabi-gcc -march=armv7-a
>> -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork
>> -mno-thumb and cc understand -c and -o together... yes
>> | checking for special C compiler options needed for large files... no
>> | checking for _FILE_OFFSET_BITS value needed for large files... 64
>> | checking for pkg-config...
>> /home/vdubhack/overo-oe/tmp/sysroots/i686-linux/usr/bin/pkg-config
>> | checking for gawk... (cached) gawk
>> | checking for perl5... no
>> | checking for perl... perl
>> | checking for indent... no
>> | checking for perl... /usr/bin/perl
>> | checking for a Python interpreter with version >= 2.4... python
>> | checking fo

Re: [oe] [PATCH] added a .bb for node.js

[J. L.]

Great write up AJ once again I wasnt even aware of some of those
steps. Probably why a patch I tried to send in a long while ago never
showed up again nor did I hear anything. Thanks for taking the time to
write out those steps and very clearly, hope to see more on your blog
as well about all this. I hope I will get the hang of all this soon,
but I still cant get programs I want to build using BB.



On Mon, Aug 23, 2010 at 4:20 PM, AJ ONeal  wrote:
>>
>> > > Please also remember to update the patch queue [2].
>> > >
>> >
>> > Update it to what?
>> >
>> > That link you gave me is very unclear
>> >
>> > It is desirable to update the state of the patch in the patch queue. This
>> > > could also be added to the script.
>>
>> This sentence addresses the case when your patch is accepted.
>>
>
> I already marked the first two as superseded
>
>
>> > The patch is listed as "new". I'd agree with that state. It certainly
>> isn't
>> > "accepted" - that's someone else's job to put that, right?
>>
>> Reading the reviews your patch got you need to improve it a little bit.
>> So after you send in the next iteration of your patch – v2 in our case –
>> you should update the state to superseded.
>>
>
> If you look at the newest patch I already implemented all of those changes
> excepting that I didn't do the Signed-off-by and the patch includes the [v2]
> in the commit message.
>
> Do you still want me to submit again with just those changes?
>
>>> All I do to add that is --signoff, correct?
>
>> No. Please take a look at the link I gave you [1] and the other patches
>> sent to this list.
>
> Again, I don't think that's very clear
>
> - Include a Signed-off-by: line indicating the change has valid certificate
>
> of origin as per the Linux kernel
>
>
> What is a valid certificate of origin?
>
> How about an example? You correct me where I'm mistaken and then I'll copy
> this to the wiki as reference
>
>
>
>
> Let's say you create a new recipe and you'd like to submit it for inclusion
> (and you've already tested that it works, of course).
>
> Now commit with a good strong helpful message
>
>    git add recipes/nodejs/
>    git commit # don't use the -m option
>
> The message should look like this
>
>    added recipe for node.js
>
>    * added recipe for node.js (bug # - no nodejs recipe)
>    ** patched libev's wscript to not try to execute code
>    ** patched node's wscript to not search in '/usr/include'
>
>    Signed-off-by: AJ ONeal 
>
> Create your patch
>
>    git format-patch -1 # or however many commits are part of this change
>
> If you are submitting a second version also add "--subject-prefix [v2]"
>
>    git send-email
>
> Your patch will be immediately visible on
> http://patchwork.openembedded.org/patch/
> Once your patch has been accepted or rejected, update the status to
> "accepted" or "rejected"
>
> If you get soft-rejected (a lot of feedback), make the changes, submit the
> next version, and update the status of the previous patch to "superseded"
>
> Appendix: Properly configuring git (using tek...@gmail.com as an example
> user)
>
>    sudo apt-get install git-core git-email
>    git config --global user.name "Tekkub"
>    git config --global user.email "tek...@gmail.com"
>    git config --global sendemail.smtpserver smtp.gmail.com
>    git config --global sendemail.smtpserverport 587
>    git config --global sendemail.smtpencryption tls
>    git config --global sendemail.smtpuser tekk...@gmail.com
> ___
> 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] omap3-sgx-modules do_compile failed

[J. L.]

I have been able to build this for awhile with no issues and now its
failing on the do_compile part. Is there something I am missing with
this one? The error is below, and I have tried cleaning the recipe and
rebuilding it separately from my image and still same issues.


NOTE: Running task 891 of 907 (ID: 0,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb,
do_unpack)
NOTE: Unpacking sources/OMAP35x_Graphics_SDK_setuplinux_3_01_00_06.bin
to tmp/work/overo-angstrom-linux-gnueabi/omap3-sgx-modules-1.4.14.2616-r88/

This will install TI OMAP35xx/37xx Graphics SDK on your computer.  Continue?
[n/Y]

This will install TI OMAP35xx/37xx Graphics SDK on your computer.  Continue?
[n/Y]

OMAP3530 / OMAP3515 / AM3517 / AM3715 / DM3730

Graphics Software License Agreement

IMPORTANT - PLEASE READ THE FOLLOWING LICENSE AGREEMENT CAREFULLY.  THIS IS A
LEGALLY BINDING AGREEMENT.  AFTER YOU READ THIS LICENSE AGREEMENT, YOU WILL BE
ASKED WHETHER YOU ACCEPT AND AGREE TO THE TERMS OF THIS LICENSE AGREEMENT.  DO
NOT CLICK "I HAVE READ AND AGREE" UNLESS: (1) YOU ARE AUTHORIZED TO ACCEPT AND
AGREE TO THE TERMS OF THIS LICENSE AGREEMENT ON BEHALF OF YOURSELF AND YOUR
COMPANY; AND (2) YOU INTEND TO ENTER INTO AND TO BE BOUND BY THE TERMS OF THIS
LEGALLY BINDING AGREEMENT ON BEHALF OF YOURSELF AND YOUR COMPANY.




Important - Read carefully:  This OMAP3530 / OMAP3515 / AM3517 / AM3715 / DM3730
Graphics Software License Agreement ("Agreement") is a legal agreement between
you (either an individual or entity) and Texas Instruments Incorporated ("TI").
The "Licensed Materials" subject to this Agreement include the software programs
(in whole or in part) that accompany this Agreement and that TI has granted you
access to download and any "on-line" or electronic documentation (in whole or in
part) associated with these programs, as well as any updates or upgrades to such
-- Press space to continue or 'q' to quit --
software programs and documentation, if any, provided to you at TI's sole
discretion.  The Licensed Materials are specifically designed and licensed for
use solely and exclusively with OMAP3530, OMAP3515, AM3517, AM3715, and DM3730
processing devices manufactured by or for TI ("TI Devices").



By installing, copying or otherwise using the Licensed Materials you agree to
abide by the provisions set forth herein.  If you choose not to accept or agree
with these provisions, do not download or install the Licensed Materials.  If
you have already paid for the Licensed Materials, you may return them for a full
refund.



Note Regarding Access to Open Source Software:  The Licensed Materials are be
bundled with Open Source Software.  "Open Source Software" means any software
licensed under terms requiring that (A) other software ("Proprietary Software")
incorporated, combined or distributed with such software or developed using such
software: (i) be disclosed or distributed in source code form; or (ii) otherwise
be licensed on terms inconsistent with the terms of this Agreement, including
but not limited to permitting use of the Proprietary Software on or with devices
other than TI Devices, or (B) require the owner of Proprietary Software to
-- Press space to continue or 'q' to quit --
Do you agree to the licensing terms [n/Y]

Where do you want to install TI OMAP35xx/37xx Graphics SDK?
[/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/omap3-sgx-modules-1.4.14.2616-r88/OMAP35x_Graphics_SDK_3_01_00_06]
Installing TI OMAP35xx/37xx Graphics SDK...

Installing Program Files...
[===] 100%
Installation complete.
NOTE: Running task 892 of 907 (ID: 1,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb,
do_patch)
NOTE: Running task 893 of 907 (ID: 8,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb,
do_configure)
NOTE: Running task 894 of 907 (ID: 9,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb,
do_qa_configure)
NOTE: Running task 895 of 907 (ID: 10,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/powervr-drivers/omap3-sgx-modules_1.4.14.2616.bb,
do_compile)
ERROR: function do_compile failed
ERROR: log data follows
(/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/omap3-sgx-modules-1.4.14.2616-r88/temp/log.do_compile.23035)
| NOTE: make -e MAKEFLAGS=
KERNEL_PATH=/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel
KERNEL_SRC=/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel
KDIR=/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel
KERNELDIR=/home/vdubhack/overo-oe/tmp/sysroots/overo-angstrom-linux-gnueabi/kernel
KERNEL_VERSION=2.6.33 CC=arm-angstrom-linux-gnueabi-gcc
-mno-thumb-interwork -mno-thumb LD=arm-angstrom-linux-gnueabi-ld
AR=arm-angstrom-linux-gnueabi-ar  BUIL

Re: [oe] Patch procedure for dummies

[J. L.]

A huge thanks for taking the time AJ keep you the great work, I am
sure your helping tons of people me included!




On Wed, Aug 25, 2010 at 7:43 AM, AJ ONeal  wrote:
> Please give me feedback and I'll post this on the wiki.
>
> A task-oriented guide to creating a patch:
>
>
>
>> Let's say you create a new recipe and you'd like to submit it for inclusion
>> (and you've already tested that it works, of course).
>>
>> 1. Now commit with a good strong helpful message
>>
>>     git add recipes/nodejs/
>>     git commit # don't use the -m option
>>
>> 2. The message should look like this
>>
>>     added recipe for node.js
>>
>>     * added recipe for node.js (bug # - no nodejs recipe)
>>     ** patched libev's wscript to not try to execute code
>>     ** patched node's wscript to not search in '/usr/include'
>>
>>     Signed-off-by: AJ ONeal 
>>
>> 3. Create your patch
>>
>>     git format-patch -1 # or however many commits are part of this change
>>
>> 3++. If you are submitting a second version also add "--subject-prefix
>> [v2]"
>>
>>     git send-email
>>
>> Your patch will be immediately visible on
>> http://patchwork.openembedded.org/patch/
>>
>
>
>> 4. Once your patch has been accepted or rejected, create an account and
>> update the status to "accepted" or "rejected"
>>
>> 4++. If you get soft-rejected (a lot of feedback), make the changes, submit
>> the next version, and update the status of the previous patch to
>> "superseded"
>>
>> Appendix: Properly configuring git (using tek...@gmail.com as an example
>> user)
>>
>>     sudo apt-get install git-core git-email
>>     git config --global user.name "Tekkub"
>>     git config --global user.email "tek...@gmail.com"
>>     git config --global sendemail.smtpserver smtp.gmail.com
>>     git config --global sendemail.smtpserverport 587
>>     git config --global sendemail.smtpencryption tls
>>     git config --global sendemail.smtpuser tekk...@gmail.com
>>
> ___
> 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] Question on apr on what it said during build

[J. L.]

I am building a image and had apr error out while building so I did a
-c clean and rebuilt it which it did fine but, I saw something I had
not noticed before and would like to know if its something to worry
about and if its not what does it mean. The message is below:

NOTE: Running task 749 of 759 (ID: 13,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr_1.3.5.bb,
do_package)
NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/lib/apr.exp
NOTE:   /usr/share/build-1/mkdir.sh
NOTE:   /usr/share/build-1/apr_rules.mk
NOTE:   /usr/share/build-1/make_var_export.awk
NOTE:   /usr/share/build-1/make_exports.awk


thanks for your help

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

[oe] apr-util_1.3.4 does not build

[J. L.]

I am running ubuntu 9.10 with and up to date overo branch of OE and
apr- util will not build gives the following error:

NOTE: Running task 819 of 832 (ID: 9,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb,
do_qa_configure)
ERROR: This autoconf log indicates errors, it looked at host includes.
Rerun configure task after fixing this. The path was
'/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/apr-util-1.3.4-r5/apr-util-1.3.4'
ERROR: Error in executing:
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb
ERROR: Exception: Message:1
ERROR: Printing the environment of the function
ERROR: Build of
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb
do_qa_configure failed
ERROR: Task 9 
(/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb,
do_qa_configure) failed
NOTE: Tasks Summary: Attempted 818 tasks of which 818 didn't need to
be rerun and 1 failed.
ERROR: 
'/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb'
failed


I have tried cleaning the recipe and rebuilding with no luck as well
as trying to build from a fresh tmp directory. Though I think I
understand the error I do not know how to go about fixing it with a
proper patch. I would appreciate any help with this.

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

Re: [oe] apr-util_1.3.4 does not build

[J. L.]

That is the only OS I have setup with a build environment. Should I
just finally upgrade to the 10.04 release? Would clean install be the
best to do or can I just upgrade and not cause issues with the build
environment? I think its an issue for my build OS only as on the
gumstix board steve said it worked for him using the same OS as you
are.

On Sun, Aug 29, 2010 at 2:16 AM, Khem Raj  wrote:
> On Sat, Aug 28, 2010 at 8:11 PM, J. L.  wrote:
>> I am running ubuntu 9.10 with and up to date overo branch of OE and
>> apr- util will not build gives the following error:
>
> I cant reproduce it on ubuntu 10.04. If possible can you retry to
> reproduce it on some
> other build OS than 9.10
>
>>
>> NOTE: Running task 819 of 832 (ID: 9,
>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb,
>> do_qa_configure)
>> ERROR: This autoconf log indicates errors, it looked at host includes.
>> Rerun configure task after fixing this. The path was
>> '/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/apr-util-1.3.4-r5/apr-util-1.3.4'
>> ERROR: Error in executing:
>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb
>> ERROR: Exception: Message:1
>> ERROR: Printing the environment of the function
>> ERROR: Build of
>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb
>> do_qa_configure failed
>> ERROR: Task 9 
>> (/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb,
>> do_qa_configure) failed
>> NOTE: Tasks Summary: Attempted 818 tasks of which 818 didn't need to
>> be rerun and 1 failed.
>> ERROR: 
>> '/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb'
>> failed
>>
>>
>> I have tried cleaning the recipe and rebuilding with no luck as well
>> as trying to build from a fresh tmp directory. Though I think I
>> understand the error I do not know how to go about fixing it with a
>> proper patch. I would appreciate any help with this.
>>
>> ___
>> 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] apr-util_1.3.4 does not build

[J. L.]

if you tell me things to do or try I would be happy to help you figure
it out. I really wouldnt like to have to switch up yet at least. I am
honestly not great with OE at all yet so I would need dumb mans tips
to help you out.


On Sun, Aug 29, 2010 at 2:28 AM, Khem Raj  wrote:
> On Sun, Aug 29, 2010 at 2:23 AM, J. L.  wrote:
>> That is the only OS I have setup with a build environment. Should I
>> just finally upgrade to the 10.04 release? Would clean install be the
>> best to do or can I just upgrade and not cause issues with the build
>> environment? I think its an issue for my build OS only as on the
>> gumstix board steve said it worked for him using the same OS as you
>> are.
>
> You can try and upgrade. if that does not work and reinstall. Your system
> your choice. Though it would be interesting to find why this error
> happens on 9.10
>
>>
>> On Sun, Aug 29, 2010 at 2:16 AM, Khem Raj  wrote:
>>> On Sat, Aug 28, 2010 at 8:11 PM, J. L.  wrote:
>>>> I am running ubuntu 9.10 with and up to date overo branch of OE and
>>>> apr- util will not build gives the following error:
>>>
>>> I cant reproduce it on ubuntu 10.04. If possible can you retry to
>>> reproduce it on some
>>> other build OS than 9.10
>>>
>>>>
>>>> NOTE: Running task 819 of 832 (ID: 9,
>>>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb,
>>>> do_qa_configure)
>>>> ERROR: This autoconf log indicates errors, it looked at host includes.
>>>> Rerun configure task after fixing this. The path was
>>>> '/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/apr-util-1.3.4-r5/apr-util-1.3.4'
>>>> ERROR: Error in executing:
>>>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb
>>>> ERROR: Exception: Message:1
>>>> ERROR: Printing the environment of the function
>>>> ERROR: Build of
>>>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb
>>>> do_qa_configure failed
>>>> ERROR: Task 9 
>>>> (/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb,
>>>> do_qa_configure) failed
>>>> NOTE: Tasks Summary: Attempted 818 tasks of which 818 didn't need to
>>>> be rerun and 1 failed.
>>>> ERROR: 
>>>> '/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb'
>>>> failed
>>>>
>>>>
>>>> I have tried cleaning the recipe and rebuilding with no luck as well
>>>> as trying to build from a fresh tmp directory. Though I think I
>>>> understand the error I do not know how to go about fixing it with a
>>>> proper patch. I would appreciate any help with this.
>>>>
>>>> ___
>>>> 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
>>
>
> ___
> 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] apr-util_1.3.4 does not build

[J. L.]

Another thing I have noticed as well is that there are a bunch of
packages that do not fail to build but while they build they show
messages of not finding shared libraries missing depends and things
like that. Is that things I should post as well?

On Sun, Aug 29, 2010 at 2:44 AM, J. L.  wrote:
> if you tell me things to do or try I would be happy to help you figure
> it out. I really wouldnt like to have to switch up yet at least. I am
> honestly not great with OE at all yet so I would need dumb mans tips
> to help you out.
>
>
> On Sun, Aug 29, 2010 at 2:28 AM, Khem Raj  wrote:
>> On Sun, Aug 29, 2010 at 2:23 AM, J. L.  wrote:
>>> That is the only OS I have setup with a build environment. Should I
>>> just finally upgrade to the 10.04 release? Would clean install be the
>>> best to do or can I just upgrade and not cause issues with the build
>>> environment? I think its an issue for my build OS only as on the
>>> gumstix board steve said it worked for him using the same OS as you
>>> are.
>>
>> You can try and upgrade. if that does not work and reinstall. Your system
>> your choice. Though it would be interesting to find why this error
>> happens on 9.10
>>
>>>
>>> On Sun, Aug 29, 2010 at 2:16 AM, Khem Raj  wrote:
>>>> On Sat, Aug 28, 2010 at 8:11 PM, J. L.  wrote:
>>>>> I am running ubuntu 9.10 with and up to date overo branch of OE and
>>>>> apr- util will not build gives the following error:
>>>>
>>>> I cant reproduce it on ubuntu 10.04. If possible can you retry to
>>>> reproduce it on some
>>>> other build OS than 9.10
>>>>
>>>>>
>>>>> NOTE: Running task 819 of 832 (ID: 9,
>>>>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb,
>>>>> do_qa_configure)
>>>>> ERROR: This autoconf log indicates errors, it looked at host includes.
>>>>> Rerun configure task after fixing this. The path was
>>>>> '/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/apr-util-1.3.4-r5/apr-util-1.3.4'
>>>>> ERROR: Error in executing:
>>>>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb
>>>>> ERROR: Exception: Message:1
>>>>> ERROR: Printing the environment of the function
>>>>> ERROR: Build of
>>>>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb
>>>>> do_qa_configure failed
>>>>> ERROR: Task 9 
>>>>> (/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb,
>>>>> do_qa_configure) failed
>>>>> NOTE: Tasks Summary: Attempted 818 tasks of which 818 didn't need to
>>>>> be rerun and 1 failed.
>>>>> ERROR: 
>>>>> '/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb'
>>>>> failed
>>>>>
>>>>>
>>>>> I have tried cleaning the recipe and rebuilding with no luck as well
>>>>> as trying to build from a fresh tmp directory. Though I think I
>>>>> understand the error I do not know how to go about fixing it with a
>>>>> proper patch. I would appreciate any help with this.
>>>>>
>>>>> ___
>>>>> 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
>>>
>>
>> ___
>> 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] gcc-4.3.3 DEPENDS on gettext

[J. L.]

I notice that message in a bunch of packages that build on my system.

On Sun, Aug 29, 2010 at 7:32 AM, Leon Woestenberg
 wrote:
> Hello,
>
> can others review their logs for similar messages on GCC:
>
> NOTE: Gettext required but not in DEPENDS for file
> /home/leon/sandbox/ccm/topha/openembedded/tmp/work/ppce500v2-angstrom-linux-gnuspe/gcc-cross-initial-4.3.3-r16.1/gcc-4.3.3/intl/configure.ac.
> Missing inherit gettext?
>
>
> Regards,
> --
> Leon
>
> ___
> 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] gpe-package 0.4 does not build

[J. L.]

I have yet another package failing to build its gpe-package .04 comes
with this error message: Can anyone help?

NOTE: Running task 2765 of 2777 (ID: 10,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/gpe-package/gpe-package_0.4.bb,
do_compile)
ERROR: function do_compile failed
ERROR: log data follows
(/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/gpe-package-0.4-r2/temp/log.do_compile.25974)
| NOTE: make -e MAKEFLAGS= PREFIX=/usr
| arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8
-mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb
-isystem/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include
-fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2
-ggdb3 -DENABLE_PCRE
-isystem/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include
-DVERSION=\"0.4\" -DPREFIX=\"/usr\" -D_GNU_SOURCE
-DPACKAGE=\"gpe-package\" -DPACKAGE_LOCALE_DIR=\"/usr/share/locale\"
-DIPKG_LIB  `pkg-config --cflags libipkg` -pthread
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/gtk-2.0
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/gtk-2.0/include
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/atk-1.0
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/cairo
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/pango-1.0
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/glib-2.0
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/glib-2.0/include
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/pixman-1
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/freetype2
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/libpng12
  -pthread 
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/gtk-2.0
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/gtk-2.0/include
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/atk-1.0
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/cairo
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/pango-1.0
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/glib-2.0
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/lib/glib-2.0/include
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/pixman-1
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/freetype2
-I/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include/libpng12
  -MD -Wall   -c main.c -o main.o
| Package libipkg was not found in the pkg-config search path.
| Perhaps you should add the directory containing `libipkg.pc'
| to the PKG_CONFIG_PATH environment variable
| No package 'libipkg' found
| In file included from main.c:28:
| packages.h:4:33: error: libipkg.h: No such file or directory
| In file included from main.c:28:
| packages.h:57: error: expected specifier-qualifier-list before
'pkg_state_status_t'
| main.c: In function 'main':
| main.c:46: warning: implicit declaration of function 'exit'
| main.c:46: warning: incompatible implicit declaration of built-in
function 'exit'
| main.c:72: warning: incompatible implicit declaration of built-in
function 'exit'
| make: *** [main.o] Error 1
| FATAL: oe_runmake failed
NOTE: Task failed:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/gpe-package-0.4-r2/temp/log.do_compile.25974
ERROR: TaskFailed event exception, aborting
ERROR: Build of
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/gpe-package/gpe-package_0.4.bb
do_compile failed
ERROR: Task 10 
(/home/vdubhack/overo-oe/org.openembedded.dev/recipes/gpe-package/gpe-package_0.4.bb,
do_compile) failed
NOTE: Tasks Summary: Attempted 2764 tasks of which 2746 didn't need to
be rerun and 1 failed.
ERROR: 
'/home/vdubhack/overo-oe/org.openembedded.dev/recipes/gpe-package/gpe-package_0.4.bb'
failed

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

Re: [oe] linux-omap-psp-2.6.32 breaks iscsi-target

[J. L.]

Why is it bad to expect all packages build for all the machine/distro
? I would think that would be a more "ideal" situation especially if
its a supported machine and distro



On Mon, Aug 30, 2010 at 11:40 AM, Philip Balister  wrote:
> On 08/30/2010 02:35 PM, Frans Meulenbroeks wrote:
>>
>> 2010/8/30 Philip Balister:
>>>
>>> On 08/30/2010 01:47 PM, Frans Meulenbroeks wrote:

 The current beagleboard angstrom and minimal distro's (and maybe
 others) use the linux-omap-psp_2.6.32.bb recipe to build the kernel.
>>>
>>> What is iscsi and why would I need it on the Beagleboard?
>>
>> http://stgt.sourceforge.net/
>>
>> the pacakge is from
>> http://iscsitarget.sourceforge.net/
>> It is used by tgt (http://stgt.sourceforge.net/)
>>
>> with it you can e.g. mount an iscsi disk.
>> iscsi is for instance also supported by windows 7 and by various NAS-es.
>> Its throughput is better than Samba or NFS.
>>
>> So for beagle it could act as mechanism to e.g. retrieve content from a
>> NAS.
>
> So the trade off is a kernel that has the best chance of fully supporting
> the OMAP3 peripherals, or attaching to a NAS that is windows centric.
>
> The point I am trying to make is we can't expect all packages to build for
> every MACHINE/DISTRO combination. People have to make tradeoffs.
>
> Philip
>
> ___
> 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] linux-omap-psp-2.6.32 breaks iscsi-target

[J. L.]

Got ya thanks for taking the time to explain it.

On Mon, Aug 30, 2010 at 12:23 PM, Philip Balister  wrote:
> On 08/30/2010 02:49 PM, J. L. wrote:
>>
>> Why is it bad to expect all packages build for all the machine/distro
>> ? I would think that would be a more "ideal" situation especially if
>> its a supported machine and distro
>
> It is not bad. But we have a lot of packages and the people maintaining
> stuff have limited time. Hopefully the TI kernel guys can find a way to fix
> the issue Frans pointed out.
>
> Philip
>
>>
>>
>>
>> On Mon, Aug 30, 2010 at 11:40 AM, Philip Balister
>>  wrote:
>>>
>>> On 08/30/2010 02:35 PM, Frans Meulenbroeks wrote:
>>>>
>>>> 2010/8/30 Philip Balister:
>>>>>
>>>>> On 08/30/2010 01:47 PM, Frans Meulenbroeks wrote:
>>>>>>
>>>>>> The current beagleboard angstrom and minimal distro's (and maybe
>>>>>> others) use the linux-omap-psp_2.6.32.bb recipe to build the kernel.
>>>>>
>>>>> What is iscsi and why would I need it on the Beagleboard?
>>>>
>>>> http://stgt.sourceforge.net/
>>>>
>>>> the pacakge is from
>>>> http://iscsitarget.sourceforge.net/
>>>> It is used by tgt (http://stgt.sourceforge.net/)
>>>>
>>>> with it you can e.g. mount an iscsi disk.
>>>> iscsi is for instance also supported by windows 7 and by various NAS-es.
>>>> Its throughput is better than Samba or NFS.
>>>>
>>>> So for beagle it could act as mechanism to e.g. retrieve content from a
>>>> NAS.
>>>
>>> So the trade off is a kernel that has the best chance of fully supporting
>>> the OMAP3 peripherals, or attaching to a NAS that is windows centric.
>>>
>>> The point I am trying to make is we can't expect all packages to build
>>> for
>>> every MACHINE/DISTRO combination. People have to make tradeoffs.
>>>
>>> Philip
>>>
>>> ___
>>> 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
>

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

[oe] coreutils 8.5

[J. L.]

While building my image I am seeing this message coming up building coreutils:

NOTE: Running task 8912 of 10787 (ID: 7139,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/coreutils/coreutils_8.5.bb,
do_package)
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Running task 8913 of 10787 (ID: 7144,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/coreutils/coreutils_8.5.bb,
do_package_write_ipk)
Packaged contents of coreutils-dbg into
/home/vdubhack/overo-oe/tmp/deploy/glibc/ipk/armv7a/coreutils-dbg_8.5-r0.5_armv7a.ipk
Packaged contents of coreutils into
/home/vdubhack/overo-oe/tmp/deploy/glibc/ipk/armv7a/coreutils_8.5-r0.5_armv7a.ipk
Packaged contents of coreutils-doc into
/home/vdubhack/overo-oe/tmp/deploy/glibc/ipk/armv7a/coreutils-doc_8.5-r0.5_armv7a.ipk


Is this something normal and to be expected or is there an error in
the recipe? Thanks for any help and or info on this.

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

[oe] Boost 1.41 seems to have build issues

[J. L.]

When I bummed boost to the 1.41 version I noticed during building it
did not build in the normal manner and displayed a bunch of warning
though did not fail to build. Seems like it should not have so many
errors or inability to find libraries. Could be my inexperience
talking. Hope someone can explain why this isnt bad if it isnt but to
me an error is an error, and would cause other issues once used on the
image possibly. This is not the full message just a clip of it:

NOTE:   /usr/lib/Boost.cmake
NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfig.cmake
NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfigVersion.cmake
NOTE: Multiple libraries (libboost_date_time-mt-d.so.1.41.0,
libboost_date_time-mt.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libboost_filesystem-mt.so.1.41.0,
libboost_filesystem-mt-d.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libboost_graph-mt.so.1.41.0,
libboost_graph-mt-d.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libboost_iostreams-mt-d.so.1.41.0,
libboost_iostreams-mt.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libboost_program_options-mt.so.1.41.0,
libboost_program_options-mt-d.so.1.41.0) found and LEAD_SONAME not
defined
NOTE: Multiple libraries (libboost_python-mt-d.so.1.41.0,
libboost_python-mt.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libboost_regex-mt-d.so.1.41.0,
libboost_regex-mt.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libboost_wserialization-mt-d.so.1.41.0,
libboost_serialization-mt-d.so.1.41.0,
libboost_wserialization-mt.so.1.41.0,
libboost_serialization-mt.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libboost_signals-mt-d.so.1.41.0,
libboost_signals-mt.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libboost_system-mt-d.so.1.41.0,
libboost_system-mt.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libboost_unit_test_framework-mt-d.so.1.41.0,
libboost_unit_test_framework-mt.so.1.41.0) found and LEAD_SONAME not
defined
NOTE: Multiple libraries (libboost_thread-mt.so.1.41.0,
libboost_thread-mt-d.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Multiple libraries (libboost_prg_exec_monitor-mt-d.so.1.41.0,
libboost_wave-mt-d.so.1.41.0, libboost_prg_exec_monitor-mt.so.1.41.0,
libboost_wave-mt.so.1.41.0) found and LEAD_SONAME not defined
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1
NOTE: Couldn't find shared library provider for libstdc++.

Re: [oe] Boost 1.41 seems to have build issues

[J. L.]

overo fire with the psp kernel is what I am building


On Tue, Aug 31, 2010 at 1:20 PM, John Faith  wrote:
> J. L. wrote:
>>
>> When I bummed boost to the 1.41 version I noticed during building it
>> did not build in the normal manner and displayed a bunch of warning
>> though did not fail to build. Seems like it should not have so many
>> errors or inability to find libraries. Could be my inexperience
>> talking. Hope someone can explain why this isnt bad if it isnt but to
>> me an error is an error, and would cause other issues once used on the
>> image possibly. This is not the full message just a clip of it:
>>
>> NOTE:   /usr/lib/Boost.cmake
>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfig.cmake
>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfigVersion.cmake
>> NOTE: Multiple libraries (libboost_date_time-mt-d.so.1.41.0,
>> libboost_date_time-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_filesystem-mt.so.1.41.0,
>> libboost_filesystem-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_graph-mt.so.1.41.0,
>> libboost_graph-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_iostreams-mt-d.so.1.41.0,
>> libboost_iostreams-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_program_options-mt.so.1.41.0,
>> libboost_program_options-mt-d.so.1.41.0) found and LEAD_SONAME not
>> defined
>> NOTE: Multiple libraries (libboost_python-mt-d.so.1.41.0,
>> libboost_python-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_regex-mt-d.so.1.41.0,
>> libboost_regex-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_wserialization-mt-d.so.1.41.0,
>> libboost_serialization-mt-d.so.1.41.0,
>> libboost_wserialization-mt.so.1.41.0,
>> libboost_serialization-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_signals-mt-d.so.1.41.0,
>> libboost_signals-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_system-mt-d.so.1.41.0,
>> libboost_system-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_unit_test_framework-mt-d.so.1.41.0,
>> libboost_unit_test_framework-mt.so.1.41.0) found and LEAD_SONAME not
>> defined
>> NOTE: Multiple libraries (libboost_thread-mt.so.1.41.0,
>> libboost_thread-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_prg_exec_monitor-mt-d.so.1.41.0,
>> libboost_wave-mt-d.so.1.41.0, libboost_prg_exec_monitor-mt.so.1.41.0,
>> libboost_wave-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>
>>
>
> 
>>
>> ERROR: QA Issue with boost-date-time: non -dev package contains
>> symlink .so: boost-date-time path
>>
>> '/work/armv7a-angstrom-linux-gnueabi/boost-1.41.0-r8.1/packages-split/boost-date-time/usr/lib/libboost_date_time-mt.so'
>> ERROR: QA Issue with boost-date-time: non -dev package contains
>> symlink .so: boost-date-time path
>>
>> '/work/armv7a-angstrom-linux-gnueabi/boost-1.41.0-r8.1/packages-split/boost-date-time/usr/lib/libboost_date_time-mt-d.so'
>>
>>
>
> 
>
>
> Which machine are you building for?
>
> Not sure about the errors you saw, but when I tried to build for omap3evm, I
> hit a completely different problem:
>
> cd
> /home/jfaith/oe/arago-tmp/work/armv7a-none-linux-gnueabi/boost-1.41.0-r8.1/boost-1.41.0.cmake0/libs/date_time/src
> && /home/jfaith/oe/arago-tmp/sysroots/i686-linux/usr/bin/cmake -E
> cmake_link_script CMakeFiles/boost_date_time-mt-static.dir/link.txt
> --verbose=1
> CMAKE_AR-NOTFOUND cr ../../../lib/libboost_date_time-mt.a
>  CMakeFiles/boost_date_time-mt-static.dir/gregorian/greg_month.cpp.o
> CMakeFiles/boost_date_time-mt-static.dir/gregorian/greg_weekday.cpp.o
> CMakeFiles/boost_date_time-mt-static.dir/gregorian/date_generators.cpp.o
> Error running link command: No such file or directory
> make[2]: *** [lib/libboost_date_time-mt.a] Error 2
>
> ,
> John
>
>
>
> ___
> 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] Boost 1.41 seems to have build issues

[J. L.]

Going over more of the output on this build I am seeing a bunch of
these messages "NOTE: Couldn't find shared library provider for
libgcc_s.so.1" I have noticed at least just this libgcc file mentioned
in 5 other program builds.

Since the build does not stop does that mean there are no real issues there or?

Thanks



On Tue, Aug 31, 2010 at 1:55 PM, J. L.  wrote:
> overo fire with the psp kernel is what I am building
>
>
> On Tue, Aug 31, 2010 at 1:20 PM, John Faith  wrote:
>> J. L. wrote:
>>>
>>> When I bummed boost to the 1.41 version I noticed during building it
>>> did not build in the normal manner and displayed a bunch of warning
>>> though did not fail to build. Seems like it should not have so many
>>> errors or inability to find libraries. Could be my inexperience
>>> talking. Hope someone can explain why this isnt bad if it isnt but to
>>> me an error is an error, and would cause other issues once used on the
>>> image possibly. This is not the full message just a clip of it:
>>>
>>> NOTE:   /usr/lib/Boost.cmake
>>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfig.cmake
>>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfigVersion.cmake
>>> NOTE: Multiple libraries (libboost_date_time-mt-d.so.1.41.0,
>>> libboost_date_time-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_filesystem-mt.so.1.41.0,
>>> libboost_filesystem-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_graph-mt.so.1.41.0,
>>> libboost_graph-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_iostreams-mt-d.so.1.41.0,
>>> libboost_iostreams-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_program_options-mt.so.1.41.0,
>>> libboost_program_options-mt-d.so.1.41.0) found and LEAD_SONAME not
>>> defined
>>> NOTE: Multiple libraries (libboost_python-mt-d.so.1.41.0,
>>> libboost_python-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_regex-mt-d.so.1.41.0,
>>> libboost_regex-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_wserialization-mt-d.so.1.41.0,
>>> libboost_serialization-mt-d.so.1.41.0,
>>> libboost_wserialization-mt.so.1.41.0,
>>> libboost_serialization-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_signals-mt-d.so.1.41.0,
>>> libboost_signals-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_system-mt-d.so.1.41.0,
>>> libboost_system-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_unit_test_framework-mt-d.so.1.41.0,
>>> libboost_unit_test_framework-mt.so.1.41.0) found and LEAD_SONAME not
>>> defined
>>> NOTE: Multiple libraries (libboost_thread-mt.so.1.41.0,
>>> libboost_thread-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_prg_exec_monitor-mt-d.so.1.41.0,
>>> libboost_wave-mt-d.so.1.41.0, libboost_prg_exec_monitor-mt.so.1.41.0,
>>> libboost_wave-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>>
>>>
>>
>> 
>>>
>>> ERROR: QA Issue with boost-date-time: non -dev package contains
>>> symlink .so: boost-date-time path
>>>
>>> '/work/armv7a-angstrom-linux-gnueabi/boost-1.41.0-r8.1/packages-split/boost-date-time/usr/lib/libboost_date_time-mt.so'
>>> ERROR: QA Issue with boost-date-time: non -dev package contains
>>> symlink .so: boost-date-time path
>>>
>>> '/work/armv7a-angstrom-linux-gnueabi/boost-1.41.0-r8.1/packages-split/boost-date-time/usr/lib/libboost_date_time-mt-d.so'
>>>
>>>
>>
>> 
>>
>>
>> Which machine are you building for?
>>
>> Not sure about the errors you saw, but when I tried to build for omap3evm, I
>> hit a completely different problem:
>>
>> cd
>> /home/jfaith/oe/arago-tmp/work/armv7a-none-linux-gnueabi/boost-1.41.0-r8.1/boost-1.41.0.cmake0/libs/date_time/src
>> && /home/jfaith/oe/arago-tmp/sysroots/i686-linux/usr/bin/cmake -E
>> cmake_link_script CMakeFiles/boost_date_time-mt-static.dir/link.txt
>> --verbose=1
>> CMAKE_AR-NOTFOUND cr ../../../lib/libboost_date_time-mt.a
>>  CMakeFiles/boost_date_time-mt-static

[oe] libxml-namespacesupport-perl stuck in do configure

[J. L.]

I am trying to get this to build and it seems to be stuck on the
do_configure part, I let it run for over 24 hours before killing it
and when I tried to alt C to kill it, it endlessly looped showing
something about selecting the country your in and loops through the
choices endlessly the only way I could kill it fully was to close the
terminal. I noticed in May someone else brought up this or a very
similar issue, what is the work around and or fix for this? Thanks for
any help or tips

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

Re: [oe] libxml-namespacesupport-perl stuck in do configure

[J. L.]

so if i set up CPAN properly on the build machine that should get
through that part? Did I understand that properly? I will try that out
though, thanks a ton for the response. I will post if that works or
doesnt regardless



On Wed, Sep 1, 2010 at 1:08 PM, Frans Meulenbroeks
 wrote:
> 2010/9/1 J. L. :
>> I am trying to get this to build and it seems to be stuck on the
>> do_configure part, I let it run for over 24 hours before killing it
>> and when I tried to alt C to kill it, it endlessly looped showing
>> something about selecting the country your in and loops through the
>> choices endlessly the only way I could kill it fully was to close the
>> terminal. I noticed in May someone else brought up this or a very
>> similar issue, what is the work around and or fix for this? Thanks for
>> any help or tips
>
>
> I think I had this once too.
> Not sure how I solved it, it is quite some time ago.
> However, it could be that I configured cpan manually on the host system
>
> No idea how to fix this permanently.
>
> Frans
>
> ___
> 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] libxml-namespacesupport-perl stuck in do configure

[J. L.]

Thanks Frans that fixed it by setting up CPAN on the build machine :)



On Wed, Sep 1, 2010 at 1:16 PM, J. L.  wrote:
> so if i set up CPAN properly on the build machine that should get
> through that part? Did I understand that properly? I will try that out
> though, thanks a ton for the response. I will post if that works or
> doesnt regardless
>
>
>
> On Wed, Sep 1, 2010 at 1:08 PM, Frans Meulenbroeks
>  wrote:
>> 2010/9/1 J. L. :
>>> I am trying to get this to build and it seems to be stuck on the
>>> do_configure part, I let it run for over 24 hours before killing it
>>> and when I tried to alt C to kill it, it endlessly looped showing
>>> something about selecting the country your in and loops through the
>>> choices endlessly the only way I could kill it fully was to close the
>>> terminal. I noticed in May someone else brought up this or a very
>>> similar issue, what is the work around and or fix for this? Thanks for
>>> any help or tips
>>
>>
>> I think I had this once too.
>> Not sure how I solved it, it is quite some time ago.
>> However, it could be that I configured cpan manually on the host system
>>
>> No idea how to fix this permanently.
>>
>> Frans
>>
>> ___
>> 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] python-m2crypto_0.18.2 fails to build

[J. L.]

I am unable to get this to build, end of the error is below was to
long to post all of it

| SWIG/_m2crypto_wrap.c: In function '_wrap_ssl_get_ciphers':
| SWIG/_m2crypto_wrap.c:16078: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:16078: error: 'result' undeclared (first use
in this function)
| SWIG/_m2crypto_wrap.c:16091: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c: In function '_wrap_sk_ssl_cipher_num':
| SWIG/_m2crypto_wrap.c:16101: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:16101: error: 'arg1' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:16101: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:16112: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:16118: warning: implicit declaration of
function 'sk_ssl_cipher_num'
| SWIG/_m2crypto_wrap.c: In function '_wrap_sk_ssl_cipher_value':
| SWIG/_m2crypto_wrap.c:16131: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:16131: error: 'arg1' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:16131: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:16146: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:16157: warning: implicit declaration of
function 'sk_ssl_cipher_value'
| SWIG/_m2crypto_wrap.c: In function '_wrap_ssl_get_peer_cert_chain':
| SWIG/_m2crypto_wrap.c:16171: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:16171: error: 'result' undeclared (first use
in this function)
| SWIG/_m2crypto_wrap.c:16184: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c: In function '_wrap_sk_x509_num':
| SWIG/_m2crypto_wrap.c:16194: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:16194: error: 'arg1' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:16194: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:16205: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:16211: warning: implicit declaration of
function 'sk_x509_num'
| SWIG/_m2crypto_wrap.c: In function '_wrap_sk_x509_value':
| SWIG/_m2crypto_wrap.c:16224: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:16224: error: 'arg1' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:16224: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:16239: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:16250: warning: implicit declaration of
function 'sk_x509_value'
| SWIG/_m2crypto_wrap.c: In function '_wrap_x509_name_entry_set_data':
| SWIG/_m2crypto_wrap.c:18262: warning: pointer targets in assignment
differ in signedness
| SWIG/_m2crypto_wrap.c: In function '_wrap_x509_store_ctx_get1_chain':
| SWIG/_m2crypto_wrap.c:18850: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:18850: error: 'result' undeclared (first use
in this function)
| SWIG/_m2crypto_wrap.c:18858: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c: In function '_wrap_sk_x509_new_null':
| SWIG/_m2crypto_wrap.c:19663: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:19663: error: 'result' undeclared (first use
in this function)
| SWIG/_m2crypto_wrap.c:19666: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c: In function '_wrap_sk_x509_free':
| SWIG/_m2crypto_wrap.c:19676: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:19676: error: 'arg1' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:19676: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:19686: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:19692: warning: implicit declaration of
function 'sk_x509_free'
| SWIG/_m2crypto_wrap.c: In function '_wrap_sk_x509_push':
| SWIG/_m2crypto_wrap.c:19702: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:19702: error: 'arg1' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:19702: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:19717: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:19733: warning: implicit declaration of
function 'sk_x509_push'
| SWIG/_m2crypto_wrap.c: In function '_wrap_sk_x509_pop':
| SWIG/_m2crypto_wrap.c:19746: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:19746: error: 'arg1' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:19746: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:19757: error: expected expression before ')' token
| SWIG/_m2crypto_wrap.c:19763: warning: implicit declaration of
function 'sk_x509_pop'
| SWIG/_m2crypto_wrap.c: In function '_wrap_x509_req_add_extensions':
| SWIG/_m2crypto_wrap.c:19964: error: 'STACK' undeclared (first use in
this function)
| SWIG/_m2crypto_wrap.c:19964: er

Re: [oe] libxml-namespacesupport-perl stuck in do configure

[J. L.]

I am building on the overo branch and its as updated as can be.

Version number was namespace_1.10

I verified the patch is in there and exactly the same as the one you
linked to. So that means it had to be there before I tried to build
this since I git pull'ed before starting this series of builds.

Build machine is Ubuntu 9.10, I am also running into other issues
installing Perl modules other than this one as well with different
issues but I am sorting through them to make sure as much as possible
its not me to the best of my knowledge causing them before posting
them. Also 3-4 days ago I started doing the tinderbox results on my
builds in case that would help you anymore in seeing more information.
I am willing on anything I post to the board to give as much info and
look for what ever or anything to help out as much as I can until I
can actually be more of a help than an annoyance on here.

Again thanks

On Wed, Sep 1, 2010 at 11:29 PM, Frans Meulenbroeks
 wrote:
> 2010/9/1 Tom Rini :
>> Frans Meulenbroeks wrote:
>>>
>>> 2010/9/1 J. L. :
>>>>
>>>> Thanks Frans that fixed it by setting up CPAN on the build machine :)
>>>
>>> J.L, thanks for reporting this back.
>>>
>>> Actually we do need a real fix for this.
>>> any perl wizards that can take this up?
>>
>> I'm confused since I thought I had done this already with
>> 71a16be679041bb042c02f0f59c56141d963562c
>>
>> --
>> Tom Rini
>> Mentor Graphics Corporation
>
> J.L. what version were you building?
> Did you have this patch? (url:
> http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=71a16be679041bb042c02f0f59c56141d963562c
> )
> I must say I haven't seen the problem recently but once you've
> configured cpan the problem is away. Not sure on how to test/reproduce
> this.
>
> Frans
>
> ___
> 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] [Gumstix-users] Boost 1.41 seems to have build issues

[J. L.]

Now the closer my image gets to being built since bumping this package
to 1.41 its seems to me roughly half the programs and dependencies
build with one or both of these notes in them "NOTE: Couldn't find
shared library provider for libstdc++.so.6
NOTE: Couldn't find shared library provider for libgcc_s.so.1" as it
did with this package. just wanted to post my other observations on
this as well..


On Tue, Aug 31, 2010 at 6:39 PM, Alex Gibson  wrote:
>
> Getting exactly the same messages
>
> Alex
>
>
> On 1/09/2010 5:27 AM, J. L. wrote:
>> When I bummed boost to the 1.41 version I noticed during building it
>> did not build in the normal manner and displayed a bunch of warning
>> though did not fail to build. Seems like it should not have so many
>> errors or inability to find libraries. Could be my inexperience
>> talking. Hope someone can explain why this isnt bad if it isnt but to
>> me an error is an error, and would cause other issues once used on the
>> image possibly. This is not the full message just a clip of it:
>>
>> NOTE:   /usr/lib/Boost.cmake
>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfig.cmake
>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfigVersion.cmake
>> NOTE: Multiple libraries (libboost_date_time-mt-d.so.1.41.0,
>> libboost_date_time-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_filesystem-mt.so.1.41.0,
>> libboost_filesystem-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_graph-mt.so.1.41.0,
>> libboost_graph-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_iostreams-mt-d.so.1.41.0,
>> libboost_iostreams-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_program_options-mt.so.1.41.0,
>> libboost_program_options-mt-d.so.1.41.0) found and LEAD_SONAME not
>> defined
>> NOTE: Multiple libraries (libboost_python-mt-d.so.1.41.0,
>> libboost_python-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_regex-mt-d.so.1.41.0,
>> libboost_regex-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_wserialization-mt-d.so.1.41.0,
>> libboost_serialization-mt-d.so.1.41.0,
>> libboost_wserialization-mt.so.1.41.0,
>> libboost_serialization-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_signals-mt-d.so.1.41.0,
>> libboost_signals-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_system-mt-d.so.1.41.0,
>> libboost_system-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_unit_test_framework-mt-d.so.1.41.0,
>> libboost_unit_test_framework-mt.so.1.41.0) found and LEAD_SONAME not
>> defined
>> NOTE: Multiple libraries (libboost_thread-mt.so.1.41.0,
>> libboost_thread-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Multiple libraries (libboost_prg_exec_monitor-mt-d.so.1.41.0,
>> libboost_wave-mt-d.so.1.41.0, libboost_prg_exec_monitor-mt.so.1.41.0,
>> libboost_wave-mt.so.1.41.0) found and LEAD_SONAME not defined
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>> NOTE: Couldn't find shared library provider for

[oe] Can someone help me understand these errors I got in my build

[J. L.]

When it was going through the final stages in my build I ended up with
some conflict errors and not sure if I understand how to fix this
properly. Do I just remove what its says is why it cant install one
file because another is trying to install the same file ? Or? But I
dont think I am understanding these correctly as I have never gotten
them before. I would really appreciate any help on this one so I can
get my image packaged now that everything is built. Also I can post my
image I am trying to build if that helps its a very bloated desktop
image, here is the error:

also I tried to clean it by doing bitbake -c clean and then bitbake
myimage but still same result.

| Collected errors:
|  * check_data_file_clashes: Package kernel-firmware-down3 wants to
install file 
/home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/lib/firmware/edgeport/down3.bin
|   But that file is already provided by package  * linux-firmware
|  * opkg_install_cmd: Cannot install package task-base-extended.
|  * check_data_file_clashes: Package rt73-firmware wants to install
file /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/lib/firmware/rt73.bin
|   But that file is already provided by package  * linux-firmware
|  * opkg_install_cmd: Cannot install package rt73-firmware.
|  * opkg_install_cmd: Cannot install package libnet.
|  * check_data_file_clashes: Package glproto-dev wants to install
file 
/home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/include/GL/internal/glcore.h
|   But that file is already provided by package  * libgl-dev
|  * opkg_install_cmd: Cannot install package artoolkit-dev.
|  * satisfy_dependencies_for: Cannot satisfy the following
dependencies for task-sdk-native:
|  *libdbd-sqlite-perl *libdbix-simple-perl *
|  * opkg_install_cmd: Cannot install package task-native-sdk.
|  * check_data_file_clashes: Package python-zopeinterface wants to
install file 
/home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/lib/python2.6/site-packages/setuptools.pth
|   But that file is already provided by package  * python-setuptools
|  * check_data_file_clashes: Package python-zopeinterface wants to
install file 
/home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/lib/python2.6/site-packages/site.pyo
|   But that file is already provided by package  * python-setuptools
|  * check_data_file_clashes: Package python-zopeinterface wants to
install file 
/home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/lib/python2.6/site-packages/site.py
|   But that file is already provided by package  * python-setuptools
|  * check_data_file_clashes: Package python-zopeinterface wants to
install file 
/home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/bin/easy_install-2.6
|   But that file is already provided by package  * python-setuptools
|  * check_data_file_clashes: Package python-zopeinterface wants to
install file /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/bin/easy_install
|   But that file is already provided by package  * python-setuptools
|  * opkg_install_cmd: Cannot install package python-twisted.
|  * opkg_install_cmd: Cannot install package gst-plugin-video4linux2.
|  * resolve_conffiles: Existing conffile
/home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/etc/device_table is
different from the conffile in the new package. The new conffile will
be placed at 
/home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/etc/device_table-opkg.
|  * check_data_file_clashes: Package gpe-theme-clearlooks wants to
install file 
/home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/share/themes/Clearlooks/gtk-2.0/gtkrc
|   But that file is already provided by package  * gtk-theme-clearlooks
|  * opkg_install_cmd: Cannot install package gpe-session-scripts.
NOTE: Task failed:
/home/vdubhack/overo-oe/tmp/work/overo-angstrom-linux-gnueabi/UAV-Dimage-1.0-r0/temp/log.do_rootfs.4216
NOTE: oestats: task failed, see
http://tinderbox.openembedded.net/public/logs/task/7541484.txt
ERROR: TaskFailed event exception, aborting
ERROR: Build of
/home/vdubhack/overo-oe/user.collection/recipes/images/UAV-Dimage.bb
do_rootfs failed
ERROR: Task 11 
(/home/vdubhack/overo-oe/user.collection/recipes/images/UAV-Dimage.bb,
do_rootfs) failed
NOTE: Tasks Summary: Attempted 11557 tasks of which 11540 didn't need
to be rerun and 1 failed.
ERROR: '/home/vdubhack/overo-oe/user.collection/recipes/images/UAV-Dimage.bb'
failed
NOTE: oestats: build failed, see http://tinderbox.openembedded.net/builds/85611/


Thanks as always !

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

Re: [oe] Does the OS make a difference?

[J. L.]

I would be interested to know as well I am building on 9.10 and seem
to get more errors than those building on 10.04 or 10.10 with 64 bit



On Thu, Sep 2, 2010 at 8:46 AM, AJ ONeal  wrote:
> The way that I understand it, OE natively compiles everything it needs for
> cross-compiling everything the target needs - perl, python, etc.
>
> However, I hear people using Ubuntu 10.04 say that they don't have problems
> building the same thing that I'm building.
>
> Is that just random happenstance or is there something about the OS that
> would make successful builds more likely?
>
> It would be worth it to upgrade from Ubuntu 8.10 to 10.04 if it really makes
> a difference... but it would take time and disrupt workflow and otherwise
> provide little advantage.
>
> AJ ONeal
> ___
> 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] Perl modules I can not get to build, libdbd-sqlite-perl libversion-perl

[J. L.]

I have cleaned and rebuilt these a few times now while trying to do
what its saying or assuming it should be saying in the errors, the
commands i have run are bitbake -c package then I run bitbake package
again after I try a fix. Build machine is ubuntu9.10, and I am on the
overo branch. I know I really need to learn to grasp the recipes and
patching more but I am slowly working on that while working through
the errors as it sticks better for me this way. I broke up each
failing recipe down so easier to see info for each package.

libdbd-sqlite-perl:
I have read the error and installed what it says is missing as well as
upgraded CPAN and yet still can not build this package for some reason
and I am not sure what to try next. I have installed I think every DBi
related module on the build machine through perl as well as through
apt-get on Ubuntu. I am sure this could be another simple beginner
error but I can not seem to get how to get through the error. Any
chance anyone has seen this or knows what I need to do for a work
around for the time being? Error below:

NOTE: Handling BitBake files: | (7445/7448) [99 %]
NOTE: Parsing finished. 6460 cached, 471 parsed, 517 skipped, 2 masked.
NOTE: oestats: build 85643
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing runqueue
NOTE: Running task 923 of 979 (ID: 45,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libdbd-sqlite-perl_1.29.bb,
do_setscene)
NOTE: Running task 924 of 979 (ID: 43,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libdbd-sqlite-perl_1.29.bb,
do_fetch)
NOTE: Running task 925 of 979 (ID: 38,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libdbd-sqlite-perl_1.29.bb,
do_unpack)
NOTE: Unpacking sources/DBD-SQLite-1.29.tar.gz to
tmp/work/armv7a-angstrom-linux-gnueabi/libdbd-sqlite-perl-1.29-r0/
NOTE: Running task 926 of 979 (ID: 39,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libdbd-sqlite-perl_1.29.bb,
do_patch)
NOTE: Running task 927 of 979 (ID: 46,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libdbd-sqlite-perl_1.29.bb,
do_configure)
ERROR: function do_configure failed
ERROR: log data follows
(/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/libdbd-sqlite-perl-1.29-r0/temp/log.do_configure.31416)
| DBI 1.57 is required to configure this module, please install it or
upgrade your CPAN/CPANPLUS shell
| yes: standard output: Broken pipe
| yes: write error
| sed: can't read Makefile: No such file or directory
NOTE: Task failed:
/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/libdbd-sqlite-perl-1.29-r0/temp/log.do_configure.31416
NOTE: oestats: task failed, see
http://tinderbox.openembedded.net/public/logs/task/7549847.txt
ERROR: TaskFailed event exception, aborting
ERROR: Build of
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libdbd-sqlite-perl_1.29.bb
do_configure failed
ERROR: Task 46 
(/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libdbd-sqlite-perl_1.29.bb,
do_configure) failed
NOTE: Tasks Summary: Attempted 926 tasks of which 922 didn't need to
be rerun and 1 failed.
ERROR: 
'/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libdbd-sqlite-perl_1.29.bb'
failed
NOTE: oestats: build failed, see http://tinderbox.openembedded.net/builds/85643/


libversion-perl:
This one I can not really make any sense of the error so not sure what
to try but what I have done is install the module through cpan and
apt-get on the build machine and still failing.Other than that I am
out of ideas as to what to try. Error below:

NOTE: Handling BitBake files: | (7445/7448) [99 %]
NOTE: Parsing finished. 6460 cached, 471 parsed, 517 skipped, 2 masked.
NOTE: oestats: build 85644
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing runqueue
NOTE: Running task 923 of 960 (ID: 26,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libversion-perl_0.6701.bb,
do_setscene)
NOTE: Running task 924 of 960 (ID: 24,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libversion-perl_0.6701.bb,
do_fetch)
NOTE: Running task 925 of 960 (ID: 19,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libversion-perl_0.6701.bb,
do_unpack)
NOTE: Unpacking sources/version-0.6701.tar.gz to
tmp/work/armv7a-angstrom-linux-gnueabi/libversion-perl-0.6701-r9/
NOTE: Running task 926 of 960 (ID: 20,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libversion-perl_0.6701.bb,
do_patch)
NOTE: Running task 927 of 960 (ID: 27,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libversion-perl_0.6701.bb,
do_configure)
NOTE: Running task 928 of 960 (ID: 28,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libversion-perl_0.6701.bb,
do_qa_configure)
NOTE: Running task 929 of 960 (ID: 29,
/home/vdubhack/overo-oe/org.openembedded.dev/recipes/perl/libversion-perl_0.6701.bb,
do_compile)
ERROR: function do_compile failed
ERROR: log data follows
(/home/vdubhack/overo-oe/tmp/w

Re: [oe] Can someone help me understand these errors I got in my build

[J. L.]

On Thu, Sep 2, 2010 at 4:36 AM, Graham Gower  wrote:
> On 2 September 2010 17:30, J. L.  wrote:
>> When it was going through the final stages in my build I ended up with
>> some conflict errors and not sure if I understand how to fix this
>> properly. Do I just remove what its says is why it cant install one
>> file because another is trying to install the same file ? Or? But I
>> dont think I am understanding these correctly as I have never gotten
>> them before. I would really appreciate any help on this one so I can
>> get my image packaged now that everything is built. Also I can post my
>> image I am trying to build if that helps its a very bloated desktop
>> image, here is the error:
>>
>> also I tried to clean it by doing bitbake -c clean and then bitbake
>> myimage but still same result.
>>
>> | Collected errors:
>> |  * check_data_file_clashes: Package kernel-firmware-down3 wants to
>> install file 
>> /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/lib/firmware/edgeport/down3.bin
>> |       But that file is already provided by package  * linux-firmware
>
> These two packages cannot be installed on the same system. There are
> two possibilities for fixing this: either don't included both packages
> in the same image or remove the file from one of the packages.
>> |  * opkg_install_cmd: Cannot install package task-base-extended.
>
> For whatever reason, the task-base-extended ipk cannot be found in
> your package repository. There are many reasons why this may occur and
> I will not speculate upon it.
>
>> |  * check_data_file_clashes: Package rt73-firmware wants to install
>> file /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/lib/firmware/rt73.bin
>> |       But that file is already provided by package  * linux-firmware
>> |  * opkg_install_cmd: Cannot install package rt73-firmware.
>> |  * opkg_install_cmd: Cannot install package libnet.
>> |  * check_data_file_clashes: Package glproto-dev wants to install
>> file 
>> /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/include/GL/internal/glcore.h
>> |       But that file is already provided by package  * libgl-dev
>> |  * opkg_install_cmd: Cannot install package artoolkit-dev.
>> |  * satisfy_dependencies_for: Cannot satisfy the following
>> dependencies for task-sdk-native:
>> |  *    libdbd-sqlite-perl *    libdbix-simple-perl *
>
> The libdbd-sqlite-perl and libdbix-simple-perl ipks cannot be found in
> your repository.
>
>> |  * opkg_install_cmd: Cannot install package task-native-sdk.
>> |  * check_data_file_clashes: Package python-zopeinterface wants to
>> install file 
>> /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/lib/python2.6/site-packages/setuptools.pth
>> |       But that file is already provided by package  * python-setuptools
>> |  * check_data_file_clashes: Package python-zopeinterface wants to
>> install file 
>> /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/lib/python2.6/site-packages/site.pyo
>> |       But that file is already provided by package  * python-setuptools
>> |  * check_data_file_clashes: Package python-zopeinterface wants to
>> install file 
>> /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/lib/python2.6/site-packages/site.py
>> |       But that file is already provided by package  * python-setuptools
>> |  * check_data_file_clashes: Package python-zopeinterface wants to
>> install file 
>> /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/bin/easy_install-2.6
>> |       But that file is already provided by package  * python-setuptools
>> |  * check_data_file_clashes: Package python-zopeinterface wants to
>> install file 
>> /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/usr/bin/easy_install
>> |       But that file is already provided by package  * python-setuptools
>> |  * opkg_install_cmd: Cannot install package python-twisted.
>> |  * opkg_install_cmd: Cannot install package gst-plugin-video4linux2.
>> |  * resolve_conffiles: Existing conffile
>> /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/etc/device_table is
>> different from the conffile in the new package. The new conffile will
>> be placed at 
>> /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/etc/device_table-opkg.
>
> Two packages both provide the same config file. This should really
> error out, but its only a warning at the moment because it would cause
> too many breakages (the message printing is deferred until the end of
> opkg's processing, like an error).
>
>> |  * check_data_file_clashes: Package gpe-theme-clearlooks wants to
>> install file 
>> /home/vdubhack/overo-oe/tmp/rootfs/UAV-Dimage/

Re: [oe] Perl modules I can not get to build, libdbd-sqlite-perl libversion-perl

[J. L.]

According to gumstix their branch recipes are all recipes identical to
the dev branch except for a very small few, and when I ask for help on
non gumstix related recipes they kept referring me to here so I
started posting here. Most of my fixes so far have just been from my
miss understandings of things, and you guys pointing them out to me
which is has been a tremendous help already. I did verify its the same
recipe that you have in the main dev branch. So what should I do from
here? Not post these issues on the OE board and see where I get or ?

On Thu, Sep 2, 2010 at 1:02 PM, Frans Meulenbroeks
 wrote:
> 2010/9/2 J. L. :
>> I have cleaned and rebuilt these a few times now while trying to do
>> what its saying or assuming it should be saying in the errors, the
>> commands i have run are bitbake -c package then I run bitbake package
>> again after I try a fix. Build machine is ubuntu9.10, and I am on the
>> overo branch. I know I really need to learn to grasp the recipes and
>> patching more but I am slowly working on that while working through
>> the errors as it sticks better for me this way. I broke up each
>> failing recipe down so easier to see info for each package.
>
> You might want to check if the recipe is the same as the OE one.
> Typically the people on this list are working on the main branch of
> the openembedded repository.
> If you are reporting a problem on another repo or branch chances are
> small that people can help you.
>
> Also I see you are reporting quite some problems, but your posts also
> seem to indicate that you make some progress.
> If an item you reported on is resolved it is nice to report back (so
> if someone looks into it, he knows that it is not needed any more)
> And if there is a fix, a patch is always appreciated :-)
>
> But the most important thing is;
> Have fun!
> Frans
>
> ___
> 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] Perl modules I can not get to build, libdbd-sqlite-perl libversion-perl

[J. L.]

Also if it would help I can post the image recipe I have made that I
am trying to build.

In case this explains anymore about the overo branch for you this was
posted by steve sakoman who I believe is the maintainer of the branch
about the difference which to me reads as its just the configuration
files. If I am wrong please correct me.
http://old.nabble.com/Re%3A-Is-Overo-OE-branch-a-fork--p25065128.html

The main reason I posted these recipes was due to the fact that I have
tried everything that has been mentioned to me before about how to
read the errors and from what the errors read I do not understand why
installing the files on the build machine does not help with the one,
and the other is honestly above me at the moment as I do not grasp
using devshell yet and how to work with in there, let alone properly
lay out a program recipe and then patch it to work properly. Once I
grasp things more I hope to be a help and not such a hindrance, I
welcome any tips links or anything to point to how to fix either and I
will try more on more with those pointers and if successful post the
results and maybe a patch or post the failure.

Thanks for all of your time


On Thu, Sep 2, 2010 at 4:22 PM, J. L.  wrote:
> According to gumstix their branch recipes are all recipes identical to
> the dev branch except for a very small few, and when I ask for help on
> non gumstix related recipes they kept referring me to here so I
> started posting here. Most of my fixes so far have just been from my
> miss understandings of things, and you guys pointing them out to me
> which is has been a tremendous help already. I did verify its the same
> recipe that you have in the main dev branch. So what should I do from
> here? Not post these issues on the OE board and see where I get or ?
>
> On Thu, Sep 2, 2010 at 1:02 PM, Frans Meulenbroeks
>  wrote:
>> 2010/9/2 J. L. :
>>> I have cleaned and rebuilt these a few times now while trying to do
>>> what its saying or assuming it should be saying in the errors, the
>>> commands i have run are bitbake -c package then I run bitbake package
>>> again after I try a fix. Build machine is ubuntu9.10, and I am on the
>>> overo branch. I know I really need to learn to grasp the recipes and
>>> patching more but I am slowly working on that while working through
>>> the errors as it sticks better for me this way. I broke up each
>>> failing recipe down so easier to see info for each package.
>>
>> You might want to check if the recipe is the same as the OE one.
>> Typically the people on this list are working on the main branch of
>> the openembedded repository.
>> If you are reporting a problem on another repo or branch chances are
>> small that people can help you.
>>
>> Also I see you are reporting quite some problems, but your posts also
>> seem to indicate that you make some progress.
>> If an item you reported on is resolved it is nice to report back (so
>> if someone looks into it, he knows that it is not needed any more)
>> And if there is a fix, a patch is always appreciated :-)
>>
>> But the most important thing is;
>> Have fun!
>> Frans
>>
>> ___
>> 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] Does the OS make a difference?

[J. L.]

Do you know if doing a standard method of upgrading would be ok or
should I start from a full clean install? Thanks



On Thu, Sep 2, 2010 at 5:59 PM, Douglas Royds
 wrote:
> On 03/09/10 05:19, J. L. wrote:
>>
>> I would be interested to know as well I am building on 9.10 and seem
>> to get more errors than those building on 10.04 or 10.10 with 64 bit
>>
>>
>>
>> On Thu, Sep 2, 2010 at 8:46 AM, AJ ONeal  wrote:
>>
>>>
>>> It would be worth it to upgrade from Ubuntu 8.10 to 10.04 if it really
>>> makes
>>> a difference... but it would take time and disrupt workflow and otherwise
>>> provide little advantage.
>>>
>
> As an aside, you should both be aware that neither 9.10 nor 8.10 are "LTS"
> (long-term support) Ubuntu releases. As such, Ubuntu are no longer
> back-porting security fixes.
>
> I recommend that you both upgrade to 10.04 LTS. Ubuntu will support 10.04
> for 3 years (ie. until April 2013).
>
> Douglas.
>
>
>
>
> ===
> This email, including any attachments, is only for the intended
> addressee.  It is subject to copyright, is confidential and may be
> the subject of legal or other privilege, none of which is waived or
> lost by reason of this transmission.
> If the receiver is not the intended addressee, please accept our
> apologies, notify us by return, delete all copies and perform no
> other act on the email.
> Unfortunately, we cannot warrant that the email has not been
> altered or corrupted during transmission.
> ===
>
>
> ___
> 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] Does the OS make a difference?

[J. L.]

I figured as much but was worth asking :P I hate reinstalls, thanks as
always though.

Side note though I finally got my first recipe to almost work it
creates an ipk and i can install to an existing image but the program
doesnt run right so I messed up configuring it but I am getting closer
to getting a grasp for once. Now if I can just figure out whats giving
me my last couple errors on the image I want and then go back to
figure out how to get the packages that wont build that i need to
build from the existing recipes.




On Thu, Sep 2, 2010 at 10:05 PM, AJ ONeal  wrote:
> As with any operating system, I would recommend a clean install. IME,
> upgrades always leave cruft.
>
> It's easy enough to get a list of installed packages
> http://www.arsgeek.com/2006/09/19/ubuntu-tricks-how-to-generate-a-list-of-installed-packages-and-use-it-to-reinstall-packages/
>
> git rid of any version numbers and diff that against the new clean install
>
> You'll likely want to backup /home, /opt, /usr/local/.
>
> I'm going to go ahead and give it a try on my development box at home and
> see how it goes.
>
>
> Ironically, my goal is to replace my web dev box at home with the gumstix
> and nodejs.
>
> AJ ONeal
>
>
> On Thu, Sep 2, 2010 at 7:58 PM, J. L.  wrote:
>
>> Do you know if doing a standard method of upgrading would be ok or
>> should I start from a full clean install? Thanks
>>
>>
>>
>> On Thu, Sep 2, 2010 at 5:59 PM, Douglas Royds
>>  wrote:
>> > On 03/09/10 05:19, J. L. wrote:
>> >>
>> >> I would be interested to know as well I am building on 9.10 and seem
>> >> to get more errors than those building on 10.04 or 10.10 with 64 bit
>> >>
>> >>
>> >>
>> >> On Thu, Sep 2, 2010 at 8:46 AM, AJ ONeal  wrote:
>> >>
>> >>>
>> >>> It would be worth it to upgrade from Ubuntu 8.10 to 10.04 if it really
>> >>> makes
>> >>> a difference... but it would take time and disrupt workflow and
>> otherwise
>> >>> provide little advantage.
>> >>>
>> >
>> > As an aside, you should both be aware that neither 9.10 nor 8.10 are
>> "LTS"
>> > (long-term support) Ubuntu releases. As such, Ubuntu are no longer
>> > back-porting security fixes.
>> >
>> > I recommend that you both upgrade to 10.04 LTS. Ubuntu will support 10.04
>> > for 3 years (ie. until April 2013).
>> >
>> > Douglas.
>> >
>> >
>> >
>> >
>> > ===
>> > This email, including any attachments, is only for the intended
>> > addressee.  It is subject to copyright, is confidential and may be
>> > the subject of legal or other privilege, none of which is waived or
>> > lost by reason of this transmission.
>> > If the receiver is not the intended addressee, please accept our
>> > apologies, notify us by return, delete all copies and perform no
>> > other act on the email.
>> > Unfortunately, we cannot warrant that the email has not been
>> > altered or corrupted during transmission.
>> > ===
>> >
>> >
>> > ___
>> > 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
>

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

Re: [oe] linux-omap-psp_2.6.32.bb fails at do_compileconfigs

[J. L.]

I have been able to build mine on the last 2 commits though other
issues cause my image to not finish. Have you tried deleting the
source file and having it fetch it again? That would be the only thing
I can think of other than maybe something isnt right in the build
system

On Fri, Sep 3, 2010 at 1:46 AM, Andreas Mueller  wrote:
> I have
>
> * pulled last night 261676fed0818a60a6f5b4dc781235cc6c49ba86
> * deleted tmp dir for fresh build
> * tried baking single packages (round the clutter stuff I posted)
>
> Now I get
>
> ERROR: TaskFailed event exception, aborting
> ERROR: Build of 
> /home/Superandi/OpenEmbedded/gumstix-oe/recipes/linux/linux-omap-psp_2.6.32.bb
>  do_compileconfigs failed
> ERROR: Function do_compileconfigs failed
> NOTE: Task failed: ('function do_compileconfigs
> failed', 
> '/home/Superandi/OpenEmbedded/tmp/work/overo-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r88+gitra6bad4464f985fdd3bed72e1b82dcbfc004d7869/temp/log.do_compileconfigs.12972')
> ERROR: Logfile of failure stored
> in: 
> /home/Superandi/OpenEmbedded/tmp/work/overo-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r88+gitra6bad4464f985fdd3bed72e1b82dcbfc004d7869/temp/log.do_compileconfigs.12972
> Log data follows:
> | Multiple configs found, building those first
> | cp: cannot stat 
> `/home/Superandi/OpenEmbedded/tmp/work/overo-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r88+gitra6bad4464f985fdd3bed72e1b82dcbfc004d7869/configs/*':
>  No such
> file or directory
> | ERROR: Function do_compileconfigs failed
> NOTE: package 
> linux-omap-psp-2.6.32-r88+gitra6bad4464f985fdd3bed72e1b82dcbfc004d7869: task 
> do_compileconfigs: Failed
>
> My last fresh build was based on
>
> 7ec84b10a33241350d53efe50b7ca31bdecb2204
> Date:   Mon Aug 30 14:51:47 2010 -040
>
> I checked for changes within recipes/linux for changes during the time 
> perioud and found nothing helpful for this issue.
>
> But I found several commits at base.bbclass. Is it possible that these are 
> related to the problem?
>
> Andreas
>
> ___
> 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] [Gumstix-users] Boost 1.41 seems to have build issues

[J. L.]

On Thu, Sep 2, 2010 at 12:00 AM, J. L.  wrote:
> Now the closer my image gets to being built since bumping this package
> to 1.41 its seems to me roughly half the programs and dependencies
> build with one or both of these notes in them "NOTE: Couldn't find
> shared library provider for libstdc++.so.6
> NOTE: Couldn't find shared library provider for libgcc_s.so.1" as it
> did with this package. just wanted to post my other observations on
> this as well..
>
>
> On Tue, Aug 31, 2010 at 6:39 PM, Alex Gibson  wrote:
>>
>> Getting exactly the same messages
>>
>> Alex
>>
>>
>> On 1/09/2010 5:27 AM, J. L. wrote:
>>> When I bummed boost to the 1.41 version I noticed during building it
>>> did not build in the normal manner and displayed a bunch of warning
>>> though did not fail to build. Seems like it should not have so many
>>> errors or inability to find libraries. Could be my inexperience
>>> talking. Hope someone can explain why this isnt bad if it isnt but to
>>> me an error is an error, and would cause other issues once used on the
>>> image possibly. This is not the full message just a clip of it:
>>>
>>> NOTE:   /usr/lib/Boost.cmake
>>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfig.cmake
>>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfigVersion.cmake
>>> NOTE: Multiple libraries (libboost_date_time-mt-d.so.1.41.0,
>>> libboost_date_time-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_filesystem-mt.so.1.41.0,
>>> libboost_filesystem-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_graph-mt.so.1.41.0,
>>> libboost_graph-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_iostreams-mt-d.so.1.41.0,
>>> libboost_iostreams-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_program_options-mt.so.1.41.0,
>>> libboost_program_options-mt-d.so.1.41.0) found and LEAD_SONAME not
>>> defined
>>> NOTE: Multiple libraries (libboost_python-mt-d.so.1.41.0,
>>> libboost_python-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_regex-mt-d.so.1.41.0,
>>> libboost_regex-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_wserialization-mt-d.so.1.41.0,
>>> libboost_serialization-mt-d.so.1.41.0,
>>> libboost_wserialization-mt.so.1.41.0,
>>> libboost_serialization-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_signals-mt-d.so.1.41.0,
>>> libboost_signals-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_system-mt-d.so.1.41.0,
>>> libboost_system-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_unit_test_framework-mt-d.so.1.41.0,
>>> libboost_unit_test_framework-mt.so.1.41.0) found and LEAD_SONAME not
>>> defined
>>> NOTE: Multiple libraries (libboost_thread-mt.so.1.41.0,
>>> libboost_thread-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Multiple libraries (libboost_prg_exec_monitor-mt-d.so.1.41.0,
>>> libboost_wave-mt-d.so.1.41.0, libboost_prg_exec_monitor-mt.so.1.41.0,
>>> libboost_wave-mt.so.1.41.0) found and LEAD_SONAME not defined
>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>&

Re: [oe] [Gumstix-users] Boost 1.41 seems to have build issues

[J. L.]

Final verdict at this point for me is the 1.41 adds issues into the
build with not finding libraries and seems to cause other programs to
not build right. With 1.33.1 no errors and the image completed. In
case any one is still reading this one.

branch:overo
build machine: ubuntu 10.04
git: up to date


On Fri, Sep 3, 2010 at 9:14 PM, J. L.  wrote:
> On Thu, Sep 2, 2010 at 12:00 AM, J. L.  wrote:
>> Now the closer my image gets to being built since bumping this package
>> to 1.41 its seems to me roughly half the programs and dependencies
>> build with one or both of these notes in them "NOTE: Couldn't find
>> shared library provider for libstdc++.so.6
>> NOTE: Couldn't find shared library provider for libgcc_s.so.1" as it
>> did with this package. just wanted to post my other observations on
>> this as well..
>>
>>
>> On Tue, Aug 31, 2010 at 6:39 PM, Alex Gibson  wrote:
>>>
>>> Getting exactly the same messages
>>>
>>> Alex
>>>
>>>
>>> On 1/09/2010 5:27 AM, J. L. wrote:
>>>> When I bummed boost to the 1.41 version I noticed during building it
>>>> did not build in the normal manner and displayed a bunch of warning
>>>> though did not fail to build. Seems like it should not have so many
>>>> errors or inability to find libraries. Could be my inexperience
>>>> talking. Hope someone can explain why this isnt bad if it isnt but to
>>>> me an error is an error, and would cause other issues once used on the
>>>> image possibly. This is not the full message just a clip of it:
>>>>
>>>> NOTE:   /usr/lib/Boost.cmake
>>>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfig.cmake
>>>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfigVersion.cmake
>>>> NOTE: Multiple libraries (libboost_date_time-mt-d.so.1.41.0,
>>>> libboost_date_time-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Multiple libraries (libboost_filesystem-mt.so.1.41.0,
>>>> libboost_filesystem-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Multiple libraries (libboost_graph-mt.so.1.41.0,
>>>> libboost_graph-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Multiple libraries (libboost_iostreams-mt-d.so.1.41.0,
>>>> libboost_iostreams-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Multiple libraries (libboost_program_options-mt.so.1.41.0,
>>>> libboost_program_options-mt-d.so.1.41.0) found and LEAD_SONAME not
>>>> defined
>>>> NOTE: Multiple libraries (libboost_python-mt-d.so.1.41.0,
>>>> libboost_python-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Multiple libraries (libboost_regex-mt-d.so.1.41.0,
>>>> libboost_regex-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Multiple libraries (libboost_wserialization-mt-d.so.1.41.0,
>>>> libboost_serialization-mt-d.so.1.41.0,
>>>> libboost_wserialization-mt.so.1.41.0,
>>>> libboost_serialization-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Multiple libraries (libboost_signals-mt-d.so.1.41.0,
>>>> libboost_signals-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Multiple libraries (libboost_system-mt-d.so.1.41.0,
>>>> libboost_system-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Multiple libraries (libboost_unit_test_framework-mt-d.so.1.41.0,
>>>> libboost_unit_test_framework-mt.so.1.41.0) found and LEAD_SONAME not
>>>> defined
>>>> NOTE: Multiple libraries (libboost_thread-mt.so.1.41.0,
>>>> libboost_thread-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Multiple libraries (libboost_prg_exec_monitor-mt-d.so.1.41.0,
>>>> libboost_wave-mt-d.so.1.41.0, libboost_prg_exec_monitor-mt.so.1.41.0,
>>>> libboost_wave-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>>> NOTE: Couldn

Re: [oe] [Gumstix-users] Boost 1.41 seems to have build issues

[J. L.]

On Sat, Sep 4, 2010 at 11:27 AM, J. L.  wrote:
> Final verdict at this point for me is the 1.41 adds issues into the
> build with not finding libraries and seems to cause other programs to
> not build right. With 1.33.1 no errors and the image completed. In
> case any one is still reading this one.
>
> branch:overo
> build machine: ubuntu 10.04
> git: up to date
>
>
> On Fri, Sep 3, 2010 at 9:14 PM, J. L.  wrote:
>> On Thu, Sep 2, 2010 at 12:00 AM, J. L.  wrote:
>>> Now the closer my image gets to being built since bumping this package
>>> to 1.41 its seems to me roughly half the programs and dependencies
>>> build with one or both of these notes in them "NOTE: Couldn't find
>>> shared library provider for libstdc++.so.6
>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1" as it
>>> did with this package. just wanted to post my other observations on
>>> this as well..
>>>
>>>
>>> On Tue, Aug 31, 2010 at 6:39 PM, Alex Gibson  wrote:
>>>>
>>>> Getting exactly the same messages
>>>>
>>>> Alex
>>>>
>>>>
>>>> On 1/09/2010 5:27 AM, J. L. wrote:
>>>>> When I bummed boost to the 1.41 version I noticed during building it
>>>>> did not build in the normal manner and displayed a bunch of warning
>>>>> though did not fail to build. Seems like it should not have so many
>>>>> errors or inability to find libraries. Could be my inexperience
>>>>> talking. Hope someone can explain why this isnt bad if it isnt but to
>>>>> me an error is an error, and would cause other issues once used on the
>>>>> image possibly. This is not the full message just a clip of it:
>>>>>
>>>>> NOTE:   /usr/lib/Boost.cmake
>>>>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfig.cmake
>>>>> NOTE:   /usr/share/boost-1.41.0/cmake/BoostConfigVersion.cmake
>>>>> NOTE: Multiple libraries (libboost_date_time-mt-d.so.1.41.0,
>>>>> libboost_date_time-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Multiple libraries (libboost_filesystem-mt.so.1.41.0,
>>>>> libboost_filesystem-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Multiple libraries (libboost_graph-mt.so.1.41.0,
>>>>> libboost_graph-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Multiple libraries (libboost_iostreams-mt-d.so.1.41.0,
>>>>> libboost_iostreams-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Multiple libraries (libboost_program_options-mt.so.1.41.0,
>>>>> libboost_program_options-mt-d.so.1.41.0) found and LEAD_SONAME not
>>>>> defined
>>>>> NOTE: Multiple libraries (libboost_python-mt-d.so.1.41.0,
>>>>> libboost_python-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Multiple libraries (libboost_regex-mt-d.so.1.41.0,
>>>>> libboost_regex-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Multiple libraries (libboost_wserialization-mt-d.so.1.41.0,
>>>>> libboost_serialization-mt-d.so.1.41.0,
>>>>> libboost_wserialization-mt.so.1.41.0,
>>>>> libboost_serialization-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Multiple libraries (libboost_signals-mt-d.so.1.41.0,
>>>>> libboost_signals-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Multiple libraries (libboost_system-mt-d.so.1.41.0,
>>>>> libboost_system-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Multiple libraries (libboost_unit_test_framework-mt-d.so.1.41.0,
>>>>> libboost_unit_test_framework-mt.so.1.41.0) found and LEAD_SONAME not
>>>>> defined
>>>>> NOTE: Multiple libraries (libboost_thread-mt.so.1.41.0,
>>>>> libboost_thread-mt-d.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Multiple libraries (libboost_prg_exec_monitor-mt-d.so.1.41.0,
>>>>> libboost_wave-mt-d.so.1.41.0, libboost_prg_exec_monitor-mt.so.1.41.0,
>>>>> libboost_wave-mt.so.1.41.0) found and LEAD_SONAME not defined
>>>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>>>> NOTE: Couldn't find shared library provider for libstdc++.so.6
>>>>> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>>>>

Re: [oe] NOTE: Couldn't find shared library provider

[J. L.]

On Mon, Sep 6, 2010 at 1:18 PM, Frans Meulenbroeks
 wrote:
> Anyone an idea on what this means and how to fix it:
>
> NOTE: Couldn't find shared library provider for libstdc++.so.6
> NOTE: Couldn't find shared library provider for libgcc_s.so.1
>
> Today I've seen it with asterisk but I have seen it before.
>

Those were some of the errors I posted about last week or so I think
and have yet to figure out how to get rid of them though I noticed
bringing boost down a level lowered the amount I saw total over the
entire build. But not sure if my info is relevant since I am on the
overo branch of the dev tree ..

JL
> Frans
>
> ___
> 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] Images no longer automatically include libstdc++6

[J. L.]

On Mon, Sep 6, 2010 at 3:21 PM, Steve Sakoman  wrote:
> Using current top of tree to build some of my images I noticed that
> quite a few apps seems to be broken at run time (Firefox, Epiphany,
> Gnome-mplayer, and others).
>
> All were complaining about libstdc++6 being missing.  Manually
> installing the libstdc++6 package fixed the issue.

I have reported this on the gumstix board as well steve and Frans did
a post about this here on OE and the other one libgcc_s.so.1 that
seems to be missing. Thanks for posting your work around I thought I
had tried that on my machine but will try again. here is Frans post
this am [oe] NOTE: Couldn't find shared library provider, also my
boost threads have the errors listed in them as well.

JL


>
> Any idea what changed that introduced this issue?
>
> Steve
>
> ___
> 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] Images no longer automatically include libstdc++6

[J. L.]

On Mon, Sep 6, 2010 at 10:54 PM, Khem Raj  wrote:
> On Mon, Sep 6, 2010 at 3:21 PM, Steve Sakoman  wrote:
>> Using current top of tree to build some of my images I noticed that
>> quite a few apps seems to be broken at run time (Firefox, Epiphany,
>> Gnome-mplayer, and others).
>>
>> All were complaining about libstdc++6 being missing.  Manually
>> installing the libstdc++6 package fixed the issue.
>>
>> Any idea what changed that introduced this issue?
>
> Yes I have been seeing that and spent not so much time on the real cause
> but it seems that the depends get lost when we rename the pkgs in debian way
> may be thats not the real cause I dont know yet. but that something to look at
> even libstdc++-dev ipks miss to have dependencies on libstdc++
>

building hal 0.5.14 is one example that gives off the libgcc that I
mentioned with this one. Though there are many that give both errors
or one or the other.

JL
>>
>> Steve
>>
>> ___
>> 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] Perl modules I can not get to build, libdbd-sqlite-perl libversion-perl

[J. L.]

On Tue, Sep 7, 2010 at 8:24 AM, Tom Rini  wrote:
> Graham Gower wrote:
>>
>> On 3 September 2010 09:13, J. L.  wrote:
>
> [snip]
>>
>>> and the other is honestly above me at the moment as I do not grasp
>>> using devshell yet and how to work with in there, let alone properly
>>> lay out a program recipe and then patch it to work properly. Once I
>>> grasp things more I hope to be a help and not such a hindrance, I
>>> welcome any tips links or anything to point to how to fix either and I
>>> will try more on more with those pointers and if successful post the
>>> results and maybe a patch or post the failure.
>>
>> Read the OE manual. Read the Bitbake manual. Read .bb files. Read
>> .conf files. Read .bbclass files. Read Bitbake sources. Send patches.
>> Add time. Repeat. == expert!
>
> I'd just like to add in that while it's great (really, I mean it), you're
> reporting problems, if you can reproduce them in vanilla OE with something
> like MACHINE=qemuarm and DISTRO=angstrom-2008.1 (or DISTRO=minimal) or
> similar, that will help rule out a lot of concern on our part and give a
> testcase we can all easily try out.
>
> --
> Tom Rini
> Mentor Graphics Corporation
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

OK thanks Tom I will try and read more on how to do that. Have not
done anything with qemu yet. But what I get now and correct if I am
wrong by OE vanilla you mean fresh directly off the dev branch no
other sub tree correct? then modify my .conf to to the settings you
listed above? If I am way off dont worry about taking the time to
explain in detail I will just read about it. I feel I have become an
annoyance on the boards from my lacking knowledge. Would showing the
recipe I build for my gumstix help? Its now building but not with
everything I want and some programs are broken, but its very close the
closest I have gotten so far. Any who thanks for replying and giving
me more info on how to help you guys help me. I do appreciate
everyones help and input a bunch.

JL

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

Re: [oe] [PATCH 1/3] generate-manifest-2.6.py: tune python-modules' RDEPENDS

[J. L.]

On Thu, Sep 9, 2010 at 9:07 AM, Eric Bénard  wrote:
> * python-dev: pulls several dev packages leading to a >256MB image instead
> of a 60MB image without this packages
>
> Signed-off-by: Eric Bénard 
> ---
>  contrib/python/generate-manifest-2.6.py |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/python/generate-manifest-2.6.py 
> b/contrib/python/generate-manifest-2.6.py
> index 1a0f1d3..5ebafb8 100755
> --- a/contrib/python/generate-manifest-2.6.py
> +++ b/contrib/python/generate-manifest-2.6.py
> @@ -12,7 +12,7 @@ import time
>  VERSION = "2.6.4"
>
>  __author__ = "Michael 'Mickey' Lauer "
> -__version__ = "20100711"
> +__version__ = "20100908"
>
>  class MakefileMaker:
>
> @@ -123,7 +123,7 @@ class MakefileMaker:
>         line = 'RDEPENDS_python-modules="'
>
>         for name, data in self.packages.iteritems():
> -            if name != 'python-core-dbg':
> +            if name not in ['python-core-dbg', 'python-dev']:
>                 line += "%s " % name
>
>         self.out( "%s \"" % line )
> @@ -164,7 +164,7 @@ if __name__ == "__main__":
>     m.addPackage( "python-core-dbg", "Python core module debug information", 
> "python-core",
>     "config/.debug lib-dynload/.debug ${bindir}/.debug ${libdir}/.debug" )
>
> -    m.addPackage( "python-devel", "Python Development Package", 
> "python-core",
> +    m.addPackage( "python-dev", "Python Development Package", "python-core",
>     "${includedir} ${libdir}/libpython2.6.so config" ) # package
>
>     m.addPackage( "python-idle", "Python Integrated Development Environment", 
> "python-core python-tkinter",
> --
> 1.6.3.3
>
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Dumb comment time: Wouldnt it be better to make maybe a few different
python module packages installs instead of thining out the
python-module? I know I personally use all the modules for python
available here plus some other modules as well. I know not everyone is
concerned with making their images as small as possible. Probably just
not getting the reasoning or point but just thought I would make the
statement there are those that use python-dev as is

JL

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

Re: [oe] Perl modules I can not get to build, libdbd-sqlite-perl libversion-perl

[J. L.]

On Tue, Sep 7, 2010 at 10:39 AM, Tom Rini  wrote:
> J. L. wrote:
>>
>> On Tue, Sep 7, 2010 at 8:24 AM, Tom Rini  wrote:
>>>
>>> Graham Gower wrote:
>>>>
>>>> On 3 September 2010 09:13, J. L.  wrote:
>>>
>>> [snip]
>>>>>
>>>>> and the other is honestly above me at the moment as I do not grasp
>>>>> using devshell yet and how to work with in there, let alone properly
>>>>> lay out a program recipe and then patch it to work properly. Once I
>>>>> grasp things more I hope to be a help and not such a hindrance, I
>>>>> welcome any tips links or anything to point to how to fix either and I
>>>>> will try more on more with those pointers and if successful post the
>>>>> results and maybe a patch or post the failure.
>>>>
>>>> Read the OE manual. Read the Bitbake manual. Read .bb files. Read
>>>> .conf files. Read .bbclass files. Read Bitbake sources. Send patches.
>>>> Add time. Repeat. == expert!
>>>
>>> I'd just like to add in that while it's great (really, I mean it), you're
>>> reporting problems, if you can reproduce them in vanilla OE with
>>> something
>>> like MACHINE=qemuarm and DISTRO=angstrom-2008.1 (or DISTRO=minimal) or
>>> similar, that will help rule out a lot of concern on our part and give a
>>> testcase we can all easily try out.
>>
>> OK thanks Tom I will try and read more on how to do that. Have not
>> done anything with qemu yet. But what I get now and correct if I am
>> wrong by OE vanilla you mean fresh directly off the dev branch no
>> other sub tree correct? then modify my .conf to to the settings you
>> listed above? If I am way off dont worry about taking the time to
>
> Correct.
>
>> explain in detail I will just read about it. I feel I have become an
>> annoyance on the boards from my lacking knowledge. Would showing the
>> recipe I build for my gumstix help? Its now building but not with
>> everything I want and some programs are broken, but its very close the
>> closest I have gotten so far. Any who thanks for replying and giving
>> me more info on how to help you guys help me. I do appreciate
>> everyones help and input a bunch.
>
> We're happy to have a problem report, really.  It's just that since yes,
> you're working with more than just the vanilla tree we want to be certain
> that the problem is in the vanilla tree and not a conflict in having
> additional overlays and such available.
>
> --
> Tom Rini
> Mentor Graphics Corporation
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Just got done building my image with the vanilla tree as you requested
and I still have basically the same results, the only major difference
is now my gnome image gives a password I have no clue of to root but
my enlightenment image built and worked the same from the overo tree
as the vanilla dev OE tree as well as still failing in the same
manners. The gnome image was the only one that added another issue to
my build. Hope that may help, is there any more I can do to help?
Should I try like once a week building on the overo tree and vanilla
tree and post the differences if any or? Thanks for your time and
pointers

JL

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

Re: [oe] [PATCH 1/3] generate-manifest-2.6.py: tune python-modules' RDEPENDS

[J. L.]

On Thu, Sep 9, 2010 at 10:49 AM, Eric Bénard  wrote:
> Le 09/09/2010 19:34, J. L. a écrit :
>>
>> Dumb comment time: Wouldnt it be better to make maybe a few different
>> python module packages installs instead of thining out the
>> python-module? I know I personally use all the modules for python
>> available here plus some other modules as well. I know not everyone is
>> concerned with making their images as small as possible. Probably just
>> not getting the reasoning or point but just thought I would make the
>> statement there are those that use python-dev as is
>>
> this change doesn't prevent you from using python-dev, you will just have to
> install it manually. This change only allow to install python-modules
> without installing all the dev files they actually pull.
>
> Eric
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Thanks Eric that makes total sense to me now, appreciate the response
and clarification.

JL

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

Re: [oe] Question regarding the staging layout

[J. L.]

On Tue, Sep 21, 2010 at 10:50 AM, Johan Hovold
 wrote:
> On Sat, Sep 18, 2010 at 06:31:08PM +0800, Holger Freyther wrote:
>> I am seeing a lot of messages like:
>>
>> /home/ich/build/arm/xscale/tmp/sysroots/i686-linux/usr/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/bin/ld:
>> warning: libc.so, needed by
>> /home/ich/build/arm/xscale/tmp/sysroots/i686-linux/usr/armv5te/lib/gcc/arm-angstrom-linux-gnueabi/4.3.3/../../../../arm-angstrom-linux-gnueabi/lib/libgcc_s.so,
>> not found (try using -rpath or -rpath-link)
>>
>>
>> is that to be expected?
>
> Same issue here.
>
> See the thread "[oe] several recipes give a link error: libc.so, needed
> by libgcc_s.so, not found" from Mon, 23 Aug 2010 for some discussion on
> this matter.
>
> /Johan
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

I am still seeing this issue as well.

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

Re: [oe] apr-util_1.3.4 does not build

[J. L.]

On Sun, Aug 29, 2010 at 2:49 AM, J. L.  wrote:
> Another thing I have noticed as well is that there are a bunch of
> packages that do not fail to build but while they build they show
> messages of not finding shared libraries missing depends and things
> like that. Is that things I should post as well?
>
> On Sun, Aug 29, 2010 at 2:44 AM, J. L.  wrote:
>> if you tell me things to do or try I would be happy to help you figure
>> it out. I really wouldnt like to have to switch up yet at least. I am
>> honestly not great with OE at all yet so I would need dumb mans tips
>> to help you out.
>>
>>
>> On Sun, Aug 29, 2010 at 2:28 AM, Khem Raj  wrote:
>>> On Sun, Aug 29, 2010 at 2:23 AM, J. L.  wrote:
>>>> That is the only OS I have setup with a build environment. Should I
>>>> just finally upgrade to the 10.04 release? Would clean install be the
>>>> best to do or can I just upgrade and not cause issues with the build
>>>> environment? I think its an issue for my build OS only as on the
>>>> gumstix board steve said it worked for him using the same OS as you
>>>> are.
>>>
>>> You can try and upgrade. if that does not work and reinstall. Your system
>>> your choice. Though it would be interesting to find why this error
>>> happens on 9.10
>>>
>>>>
>>>> On Sun, Aug 29, 2010 at 2:16 AM, Khem Raj  wrote:
>>>>> On Sat, Aug 28, 2010 at 8:11 PM, J. L.  wrote:
>>>>>> I am running ubuntu 9.10 with and up to date overo branch of OE and
>>>>>> apr- util will not build gives the following error:
>>>>>
>>>>> I cant reproduce it on ubuntu 10.04. If possible can you retry to
>>>>> reproduce it on some
>>>>> other build OS than 9.10
>>>>>
>>>>>>
>>>>>> NOTE: Running task 819 of 832 (ID: 9,
>>>>>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb,
>>>>>> do_qa_configure)
>>>>>> ERROR: This autoconf log indicates errors, it looked at host includes.
>>>>>> Rerun configure task after fixing this. The path was
>>>>>> '/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/apr-util-1.3.4-r5/apr-util-1.3.4'
>>>>>> ERROR: Error in executing:
>>>>>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb
>>>>>> ERROR: Exception: Message:1
>>>>>> ERROR: Printing the environment of the function
>>>>>> ERROR: Build of
>>>>>> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb
>>>>>> do_qa_configure failed
>>>>>> ERROR: Task 9 
>>>>>> (/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb,
>>>>>> do_qa_configure) failed
>>>>>> NOTE: Tasks Summary: Attempted 818 tasks of which 818 didn't need to
>>>>>> be rerun and 1 failed.
>>>>>> ERROR: 
>>>>>> '/home/vdubhack/overo-oe/org.openembedded.dev/recipes/apr/apr-util_1.3.4.bb'
>>>>>> failed
>>>>>>
>>>>>>
>>>>>> I have tried cleaning the recipe and rebuilding with no luck as well
>>>>>> as trying to build from a fresh tmp directory. Though I think I
>>>>>> understand the error I do not know how to go about fixing it with a
>>>>>> proper patch. I would appreciate any help with this.
>>>>>>
>>>>>> ___
>>>>>> 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
>>>>
>>>
>>> ___
>>> Openembedded-devel mailing list
>>> Ope

[oe] libgcc-dev.ipk not created Fwd: [Gumstix-users] question about libgcc-dev

[J. L.]

I originally posted this on the gumstix mailing list and was told I
should ask here. I was wondering how come there is no libgcc-dev.ipk
that gets created though its in the work directory? I was trying to
compile a program on my machine and was giving me complaints about
libgcc-dev missing. Is this suppose to happen or? Thanks for any info
or help on this.

JL


-- Forwarded message --
From: Steve Sakoman 
Date: Wed, Sep 29, 2010 at 12:59 PM
Subject: Re: [Gumstix-users] question about libgcc-dev
To: "General mailing list for gumstix users."



On Wed, Sep 29, 2010 at 12:07 PM, J. L.  wrote:
> On Wed, Sep 29, 2010 at 6:54 AM, Steve Sakoman  wrote:
>> On Wed, Sep 29, 2010 at 2:20 AM, J. L.  wrote:
>>> I was trying to install libpcap-dev and libpcre-dev and when I did
>>> they both said that libgcc-dev was an unmet dependency. I have tried
>>> searching and can not seem to figure out what provides that? I am sure
>>> this is a really basic one that I am missing. Thanks if you can let me
>>> know what to build to get that.
>>
>> The gcc recipe provides libgcc-dev
>
> I checked in the tmp and it only builds a libgcc1_4.3.3 which I
> already had on the system when it gave that error. I also dont see
> anything saying its a dev for anything in the gcc tmp build. Am I
> still missing something obvious here?

I found it by searching through the tmp directory:

$ ls -l tmp/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/packages-split/
| grep libgcc-dev

drwxrwxr-x 2 sakoman sakoman 4096 2010-09-17 20:22 libgcc-dev

But you are correct, the recipe doesn't seem to put an ipk in the
deploy directory.  Not sure why!

Might be better to ask this question to the experts on the OE mailing list.

Steve

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
gumstix-users mailing list
gumstix-us...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users

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

Re: [oe] libgcc-dev.ipk not created Fwd: [Gumstix-users] question about libgcc-dev

[J. L.]

On Wed, Sep 29, 2010 at 1:09 PM, J. L.  wrote:
> I originally posted this on the gumstix mailing list and was told I
> should ask here. I was wondering how come there is no libgcc-dev.ipk
> that gets created though its in the work directory? I was trying to
> compile a program on my machine and was giving me complaints about
> libgcc-dev missing. Is this suppose to happen or? Thanks for any info
> or help on this.
>
> JL

Is there an easy way to gcc to build the libgcc-dev package? I am
honestly clueless as to how to even attempt to getting that to be
added into the builds.


>
>
> -- Forwarded message --
> From: Steve Sakoman 
> Date: Wed, Sep 29, 2010 at 12:59 PM
> Subject: Re: [Gumstix-users] question about libgcc-dev
> To: "General mailing list for gumstix users."
> 
>
>
> On Wed, Sep 29, 2010 at 12:07 PM, J. L.  wrote:
>> On Wed, Sep 29, 2010 at 6:54 AM, Steve Sakoman  wrote:
>>> On Wed, Sep 29, 2010 at 2:20 AM, J. L.  wrote:
>>>> I was trying to install libpcap-dev and libpcre-dev and when I did
>>>> they both said that libgcc-dev was an unmet dependency. I have tried
>>>> searching and can not seem to figure out what provides that? I am sure
>>>> this is a really basic one that I am missing. Thanks if you can let me
>>>> know what to build to get that.
>>>
>>> The gcc recipe provides libgcc-dev
>>
>> I checked in the tmp and it only builds a libgcc1_4.3.3 which I
>> already had on the system when it gave that error. I also dont see
>> anything saying its a dev for anything in the gcc tmp build. Am I
>> still missing something obvious here?
>
> I found it by searching through the tmp directory:
>
> $ ls -l tmp/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r17.1/packages-split/
> | grep libgcc-dev
>
> drwxrwxr-x 2 sakoman sakoman 4096 2010-09-17 20:22 libgcc-dev
>
> But you are correct, the recipe doesn't seem to put an ipk in the
> deploy directory.  Not sure why!
>
> Might be better to ask this question to the experts on the OE mailing list.
>
> Steve
>
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> gumstix-users mailing list
> gumstix-us...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

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

Re: [oe] strace 4.5.14 troubles compiling

[J. L.]

On Mon, Oct 4, 2010 at 12:57 AM, J. L.  wrote:
> I cant get strace to build since I moved to angstrom 2010.x with gcc
> 4.5, does any one have any hints? Here is the error message:
>
> NOTE: Running task 782 of 795 (ID: 15,
> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/strace/strace_4.5.14.bb,
> do_compile)
> ERROR: function do_compile failed
> ERROR: log data follows
> (/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/strace-4.5.14-r9/temp/log.do_compile.881)
> | NOTE: make
> | make  all-am
> | make[1]: Entering directory
> `/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/strace-4.5.14-r9/strace-4.5.14'
> | arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8
> -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb
> -DHAVE_CONFIG_H -I. -Ilinux/arm -I./linux/arm -Ilinux -I./linux
> -isystem/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include
> -Wall 
> -isystem/home/vdubhack/overo-oe/tmp/sysroots/armv7a-angstrom-linux-gnueabi/usr/include
> -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2
> -ggdb2 -Os -MT net.o -MD -MP -MF .deps/net.Tpo -c -o net.o net.c
> | net.c: In function 'printsock':
> | net.c:957:22: error: field 'nl' has incomplete type
> | make[1]: *** [net.o] Error 1
> | make[1]: Leaving directory
> `/home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/strace-4.5.14-r9/strace-4.5.14'
> | make: *** [all] Error 2
> | FATAL: oe_runmake failed
> NOTE: Task failed:
> /home/vdubhack/overo-oe/tmp/work/armv7a-angstrom-linux-gnueabi/strace-4.5.14-r9/temp/log.do_compile.881
> ERROR: TaskFailed event exception, aborting
> ERROR: Build of
> /home/vdubhack/overo-oe/org.openembedded.dev/recipes/strace/strace_4.5.14.bb
> do_compile failed
> ERROR: Task 15 
> (/home/vdubhack/overo-oe/org.openembedded.dev/recipes/strace/strace_4.5.14.bb,
> do_compile) failed
> NOTE: Tasks Summary: Attempted 781 tasks of which 781 didn't need to
> be rerun and 1 failed.
> ERROR: 
> '/home/vdubhack/overo-oe/org.openembedded.dev/recipes/strace/strace_4.5.14.bb'
> failed
>

was able to get 4.5.20 to build with no issues so will stick with that
since its the most current version on there..

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

Re: [oe] trouble compiling udev

[J. L.]

On Mon, Oct 4, 2010 at 1:14 AM, Jaap de Jong  wrote:
> Thanks!
> That seems to work!!
> Something to be added to udev recipe...

Any chance you can post your recipe I am not sure if I am getting
where you added that in the recipe. Thanks

>
> On 10/04/2010 09:14 AM, Eric Bénard wrote:
>>
>> Hi,
>>
>> Le 04/10/2010 08:47, Jaap de Jong a écrit :
>>>
>>> a fresh rebuild failed in compiling udev.
>>> Any clues?
>>
>> if you are using gcc 4.5 => add CFLAGS_append = " -Os"
>>  to udev recipe.
>>
>> Eric
>>
>> ___
>> 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