[yocto] I hate busybox!

[Paul D. DeRocco]

My embedded system has enough room in it for full-featured command line
tools, instead of the wretched busybox. Does the Yocto meta-data include a
layer that provides such tools? Or does OE? And how would I disable
busybox in order to use the better tools?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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

Re: [yocto] I hate busybox!

[Paul Eggleton]

Hi Paul,

On Tuesday 15 September 2015 01:26:20 Paul D. DeRocco wrote:
> My embedded system has enough room in it for full-featured command line
> tools, instead of the wretched busybox. Does the Yocto meta-data include a
> layer that provides such tools? Or does OE? And how would I disable
> busybox in order to use the better tools?

core-image-full-cmdline (and the packagegroup it uses, packagegroup-core-full-
cmdline) should give you the former, and the full tools will in almost all 
cases take precedence simply by being installed by virtue of the alternatives 
system. In order to actually remove busybox though you'd need to break apart 
packagegroup-core-boot (i.e. include its constituent parts separately into 
your image instead of the packagegroup itself).

Cheers,
Paul

-- 

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

[yocto] Legacy library find.pl will be removed from the Perl core distribution in the next major release

[Neil.Wu]

Hi , all

The version of YP which I using is 1.6.2.  When building  the openssl, it 
appears the problem as following :

ERROR: Function failed: do_configure (log file is located at 
/home/ectrs/poky/cortexta8_build/tmp/work/i686-linux/openssl-native/1.0.1j-r0/temp/log.do_configure.6021)
ERROR: Logfile of failure stored in: 
/home/ectrs/poky/cortexta8_build/tmp/work/i686-linux/openssl-native/1.0.1j-r0/temp/log.do_configure.6021
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function do_configure
| Legacy library find.pl will be removed from the Perl core distribution in the 
next major release. Please install it from the CPAN distribution 
Perl4::CoreLibs. It is being used at perlpath.pl, line 7.
| Usage: Configure [no- ...] [enable- ...] 
[experimental- ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] 
[no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] 
[no-asm] [no-dso] [no-krb5] [sctp] [386] [--prefix=DIR] 
[--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at 
/home/ectrs/poky/cortexta8_build/tmp/work/i686-linux/openssl-native/1.0.1j-r0/temp/log.do_configure.6021)
ERROR: Task 514 
(virtual:native:/home/ectrs/poky/meta/recipes-connectivity/openssl/openssl_1.0.1j.bb,
 do_configure) failed with exit code '1'

How to resolve this problem?  If you know , please tell me .  Thank you very 
much.

Neil

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

[yocto] gcc reports sysroot is /not/exist!

[Chris Simmonds]

Hi,

I am using Yocto fido (1.8) to generate an SDK for a BeaglBone. I
generate the it using the command:

$ bitbake core-image-minimal -c populate_sdk

Having installed the resulting SDK and sourced
/opt/poky/1.8/environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi

I find that the sysroot is not set:

$ arm-poky-linux-gnueabi-gcc -print-sysroot
/not/exist

This used to work fine in 1.7 and earlier. It looks like now I have to
use $CC in place of arm-poky-linux-gnueabi-gcc, but that messes up many
Makefiles which set the compiler with something like

CC=$(CROSS_COMPILE)gcc

What to do? Why is gcc not configured with a sysroot any more?

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

Re: [yocto] gcc reports sysroot is /not/exist!

[Paul Eggleton]

Hi Chris,

On Tuesday 15 September 2015 09:48:34 Chris Simmonds wrote:
> I am using Yocto fido (1.8) to generate an SDK for a BeaglBone. I
> generate the it using the command:
> 
> $ bitbake core-image-minimal -c populate_sdk
> 
> Having installed the resulting SDK and sourced
> /opt/poky/1.8/environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi
> 
> I find that the sysroot is not set:
> 
> $ arm-poky-linux-gnueabi-gcc -print-sysroot
> /not/exist
> 
> This used to work fine in 1.7 and earlier. It looks like now I have to
> use $CC in place of arm-poky-linux-gnueabi-gcc, but that messes up many
> Makefiles which set the compiler with something like
> 
> CC=$(CROSS_COMPILE)gcc
> 
> What to do? Why is gcc not configured with a sysroot any more?

AIUI this had to be done in order to have a per-architecture compiler rather 
than a per-machine one. I believe if you use make -e then variables set in the 
environment will take precedence over those set in the makefile, which will 
allow the CC value set by the SDK's environment setup script to be used.

(If we haven't documented this somewhere, we definitely ought to.)

Cheers,
Paul

-- 

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

Re: [yocto] gcc reports sysroot is /not/exist!

[Chris Simmonds]

On 15/09/15 09:58, Paul Eggleton wrote:
> Hi Chris,
> 
> On Tuesday 15 September 2015 09:48:34 Chris Simmonds wrote:
>> I am using Yocto fido (1.8) to generate an SDK for a BeaglBone. I
>> generate the it using the command:
>>
>> $ bitbake core-image-minimal -c populate_sdk
>>
>> Having installed the resulting SDK and sourced
>> /opt/poky/1.8/environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi
>>
>> I find that the sysroot is not set:
>>
>> $ arm-poky-linux-gnueabi-gcc -print-sysroot
>> /not/exist
>>
>> This used to work fine in 1.7 and earlier. It looks like now I have to
>> use $CC in place of arm-poky-linux-gnueabi-gcc, but that messes up many
>> Makefiles which set the compiler with something like
>>
>> CC=$(CROSS_COMPILE)gcc
>>
>> What to do? Why is gcc not configured with a sysroot any more?
> 
> AIUI this had to be done in order to have a per-architecture compiler rather 
> than a per-machine one. I believe if you use make -e then variables set in 
> the 
> environment will take precedence over those set in the makefile, which will 
> allow the CC value set by the SDK's environment setup script to be used.
> 
> (If we haven't documented this somewhere, we definitely ought to.)
> 
> Cheers,
> Paul
> 

Well, that works as far as it goes, but it also overrides my CFLAGS,
LDFLAGS and so on, so I still have to change my Makefiles, of which
there are many.

Also, I am not convinced this is a step in the right direction. I expect
to be able to compile a simple program using:

$ gcc hello.c -o hello

But with this new cross compiler setup, this happens:

$ arm-poky-linux-gnueabi-gcc hello.c -o hello
hello.c:1:19: fatal error: stdio.h: No such file or directory
 #include 
   ^
compilation terminated.


Which violates the law of least astonishment.
Chris.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] gcc reports sysroot is /not/exist!

[Richard Purdie]

On Tue, 2015-09-15 at 10:20 +0100, Chris Simmonds wrote:
> On 15/09/15 09:58, Paul Eggleton wrote:
> > Hi Chris,
> > 
> > On Tuesday 15 September 2015 09:48:34 Chris Simmonds wrote:
> >> I am using Yocto fido (1.8) to generate an SDK for a BeaglBone. I
> >> generate the it using the command:
> >>
> >> $ bitbake core-image-minimal -c populate_sdk
> >>
> >> Having installed the resulting SDK and sourced
> >> /opt/poky/1.8/environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi
> >>
> >> I find that the sysroot is not set:
> >>
> >> $ arm-poky-linux-gnueabi-gcc -print-sysroot
> >> /not/exist
> >>
> >> This used to work fine in 1.7 and earlier. It looks like now I have to
> >> use $CC in place of arm-poky-linux-gnueabi-gcc, but that messes up many
> >> Makefiles which set the compiler with something like
> >>
> >> CC=$(CROSS_COMPILE)gcc
> >>
> >> What to do? Why is gcc not configured with a sysroot any more?
> > 
> > AIUI this had to be done in order to have a per-architecture compiler 
> > rather 
> > than a per-machine one. I believe if you use make -e then variables set in 
> > the 
> > environment will take precedence over those set in the makefile, which will 
> > allow the CC value set by the SDK's environment setup script to be used.
> > 
> > (If we haven't documented this somewhere, we definitely ought to.)
> > 
> > Cheers,
> > Paul
> > 
> 
> Well, that works as far as it goes, but it also overrides my CFLAGS,
> LDFLAGS and so on, so I still have to change my Makefiles, of which
> there are many.
> 
> Also, I am not convinced this is a step in the right direction. I expect
> to be able to compile a simple program using:
> 
> $ gcc hello.c -o hello
> 
> But with this new cross compiler setup, this happens:
> 
> $ arm-poky-linux-gnueabi-gcc hello.c -o hello
> hello.c:1:19: fatal error: stdio.h: No such file or directory
>  #include 
>^
> compilation terminated.

If we hardcode the path to the sysroot into the compiler, we hit several
issues. Firstly, we rely on the relocation code within gcc to get this
relocated correctly at install time. That doesn't work for the way we
currently build the compilers so the default sysroot only works for the
default installation directory. Yes, that one is fixable with some
jumping through hoops.

However if you don't want to set CFLAGS either, that implies we'd have
to code the flags into the compiler as well. 

So we'd build a compiler per target sysroot and per set of optimisation
flags for said target. That is grossly inefficient.

We've always had the environment file there and we've always set CFLAGS
this way, even in 1.7. If you used a non-default installation directory
in 1.7, it likely didn't work properly without passing the right flags
to gcc so you just go lucky even there. In 1.8, we poisoned the default
sysroot, so we could clearly identify any software which wasn't using
the CC and CFLAGS in ways we didn't expect. We did this to make our core
builds deterministic. We decided to do the same with the SDK.

If you really object to having to configure the compiler, I'd suggest
creating some simple wrapper scripts which simply add in the sysroot and
possibly other compiler flag options you need. The main reason we
accepted doing the change to the defaults is that there is a
comparatively simple workaround available for those that feel as you
do. 

We could even have that code in the main repo, I've just felt so far
that letting people see whats going on is better than hiding it behind
more magic scripts.

Cheers,

Richard

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

Re: [yocto] I hate busybox!

[Burton, Ross]

On 15 September 2015 at 09:45, Paul Eggleton 
wrote:

> core-image-full-cmdline (and the packagegroup it uses,
> packagegroup-core-full-
> cmdline) should give you the former, and the full tools will in almost all
> cases take precedence simply by being installed by virtue of the
> alternatives
> system. In order to actually remove busybox though you'd need to break
> apart
> packagegroup-core-boot (i.e. include its constituent parts separately into
> your image instead of the packagegroup itself).
>

Wind River have started to send patches to enable this, so oe-core 2.0 may
be able to have images without busybox.

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

[yocto] Dumping sysvinit

[Andy Pont]

Hello,

Bit of a newbie question (probably) but what is the easiest way to dump
sysvinit and use Busybox init in a core-image-minimal image?

Thanks,

Andy.


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

Re: [yocto] Dumping sysvinit

[Mark Hatle]

On 9/15/15 6:16 AM, Andy Pont wrote:
> Hello,
> 
> Bit of a newbie question (probably) but what is the easiest way to dump
> sysvinit and use Busybox init in a core-image-minimal image?

It has been a while since I've done this.  But unless things have changed
dramatically.  You will need to define your own custom image.

One that does not include the sysvinit component or base initscripts.  You will
then have to provide your own base initscripts for your system to startup and
function.  (You might be able to copy some from the initscripts, but many expect
the sysvinit [or systemd] to be present on the device.)

You are moving into pure custom boot optimization and implementation at this 
point.

--Mark

> Thanks,
> 
> Andy.
> 
> 

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

Re: [yocto] gcc reports sysroot is /not/exist!

[Chris Simmonds]

Hi Richard,

On 15/09/15 10:45, Richard Purdie wrote:
> On Tue, 2015-09-15 at 10:20 +0100, Chris Simmonds wrote:
>>
>> Also, I am not convinced this is a step in the right direction. I expect
>> to be able to compile a simple program using:
>>
>> $ gcc hello.c -o hello
>>
>> But with this new cross compiler setup, this happens:
>>
>> $ arm-poky-linux-gnueabi-gcc hello.c -o hello
>> hello.c:1:19: fatal error: stdio.h: No such file or directory
>>  #include 
>>^
>> compilation terminated.
> 
> If we hardcode the path to the sysroot into the compiler, we hit several
> issues. Firstly, we rely on the relocation code within gcc to get this
> relocated correctly at install time. That doesn't work for the way we
> currently build the compilers so the default sysroot only works for the
> default installation directory. Yes, that one is fixable with some
> jumping through hoops.
> 
> However if you don't want to set CFLAGS either, that implies we'd have
> to code the flags into the compiler as well. 
> 
> So we'd build a compiler per target sysroot and per set of optimisation
> flags for said target. That is grossly inefficient.

I'll admit that is the model I had in mind. However, I can see that it
does not scale well if you are addressing a range of targets as Yocto
allows you to do. So it looks like it is time for me to update my modus
operandi to match. However, I'll bet that I am not the only one caught out.

> We've always had the environment file there and we've always set CFLAGS
> this way, even in 1.7. If you used a non-default installation directory
> in 1.7, it likely didn't work properly without passing the right flags
> to gcc so you just go lucky even there. In 1.8, we poisoned the default
> sysroot, so we could clearly identify any software which wasn't using
> the CC and CFLAGS in ways we didn't expect. We did this to make our core
> builds deterministic. We decided to do the same with the SDK.
> 
> If you really object to having to configure the compiler, I'd suggest
> creating some simple wrapper scripts which simply add in the sysroot and
> possibly other compiler flag options you need. The main reason we
> accepted doing the change to the defaults is that there is a
> comparatively simple workaround available for those that feel as you
> do. 
> 
> We could even have that code in the main repo, I've just felt so far
> that letting people see whats going on is better than hiding it behind
> more magic scripts.
> 

No, I have no desire to write wrappers, I just wanted to clarify "the
right way to do things". Thank you very much for explaining it.

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

Re: [yocto] I hate busybox!

[Trevor Woerner]

On 09/15/15 04:26, Paul D. DeRocco wrote:
> My embedded system has enough room in it for full-featured command line
> tools, instead of the wretched busybox. Does the Yocto meta-data include a
> layer that provides such tools? Or does OE? And how would I disable
> busybox in order to use the better tools?

+1

...although "hate" is a strong word, I have been tripped up numerous
times in the past by writing a script on my development host only to
find it doesn't work on my target device due to the restrictions of the
various busybox executables. The "embedded" system of today is the
desktop system of only a couple years ago. The only place busybox (and
toybox) are needed today are in the MMU-less-type systems, such as
Cortex-Ms etc.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] I hate busybox!

[Trevor Woerner]

On 09/15/15 10:47, Trevor Woerner wrote:
> The only place busybox (and
> toybox) are needed today are in the MMU-less-type systems, such as
> Cortex-Ms etc.

Actually, the presence or lack of MMU is irrelevant, I meant to single
out those systems with limited on-SoC flash.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] I hate busybox!

[William Mills]

On 09/15/2015 10:53 AM, Trevor Woerner wrote:
> On 09/15/15 10:47, Trevor Woerner wrote:
>> The only place busybox (and
>> toybox) are needed today are in the MMU-less-type systems, such as
>> Cortex-Ms etc.
> 
> Actually, the presence or lack of MMU is irrelevant, I meant to single
> out those systems with limited on-SoC flash.
> 

OE-core is capable of building a system that has no GPLv3.
This capability is still important to some users and busybox is needed
for that as I understand.

(Other users want the capability to build a system w/o proprietary code.
 OE serves both needs.)


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

[yocto] Trouble installing from usb

[Robert D Kocisko]

Hello,

I am attempting to create an image for a fitlet-x computer (AMD A4
Micro-6400T SoC). I followed the instructions for creating a minimal image
and then used Hob to customize the minimal image as follows:

machine: genericx86-64
image recipe: core-image-minimal-dev
recipe edits: added xserver-xorg package

I then built and deployed the image to usb (.iso), and booted up the usb.
I got a grub menu with the options "boot" and "install".  If I select boot,
everything appears to be working as expected (believe it's just running the
image directly from usb).

However, when I select install, the screen goes black (does not disconnect)
and nothing happens even if I leave the system running for multiple minutes.

I've started to dive into the world of bootloaders to see if I can debug
this but it would be great to get some guiding tips from you to help guide
me in that process.

Oh I should mention that the first time I built a genericx86-64 image it
generated a warning while building yocto-kernel.  Unfortunately I didn't
record it anywhere and now it appears that that kernel recipe is cached
because subsequent builds haven't shown the same error.

Thanks in advance,
Bob
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Dumping sysvinit

[Andy Pont]

Mark wrote...

> > Bit of a newbie question (probably) but what is the easiest way to dump
> > sysvinit and use Busybox init in a core-image-minimal image?
> 
> It has been a while since I've done this.  But unless things have changed
> dramatically.  You will need to define your own custom image.

On the basis that sounded like more hard work than I have time for I thought
I would try switching to systemd.  Following the instructions in the dev
manual [1].

If I add the extra variables to build/conf/local.conf then with the machine
type set to genericx86 I get this build error:

ERROR: Function failed: do_configure (log file is located at
X/build/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_configure
.1926)
ERROR: Logfile of failure stored in:
X/build/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_configure
.1926
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing python function autotools_copy_aclocals
| DEBUG: Python function autotools_copy_aclocals finished
| DEBUG: Executing shell function do_configure
| 
| ERROR: User requested feature sdl
|configure was not able to find it.
|Install SDL devel

I'm guessing that this is me being dim and that build/conf/local.conf isn't
what the documentation refers to as "your distribution configuration file".
Can someone point me in the right direction?

Thanks,

Andy.

[1]
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#selecting-an
-initialization-manager

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

Re: [yocto] Dumping sysvinit

[Trevor Woerner]

On 09/15/15 12:03, Andy Pont wrote:
> Mark wrote...
>
>>> Bit of a newbie question (probably) but what is the easiest way to dump
>>> sysvinit and use Busybox init in a core-image-minimal image?
>> It has been a while since I've done this.  But unless things have changed
>> dramatically.  You will need to define your own custom image.
> On the basis that sounded like more hard work than I have time for I thought
> I would try switching to systemd.  Following the instructions in the dev
> manual [1].
>
> If I add the extra variables to build/conf/local.conf then with the machine
> type set to genericx86 I get this build error:
>
> ERROR: Function failed: do_configure (log file is located at
> X/build/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_configure
> .1926)
> ERROR: Logfile of failure stored in:
> X/build/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_configure
> .1926
> Log data follows:
> | DEBUG: Executing python function sysroot_cleansstate
> | DEBUG: Python function sysroot_cleansstate finished
> | DEBUG: Executing shell function autotools_preconfigure
> | DEBUG: Shell function autotools_preconfigure finished
> | DEBUG: Executing python function autotools_copy_aclocals
> | DEBUG: Python function autotools_copy_aclocals finished
> | DEBUG: Executing shell function do_configure
> | 
> | ERROR: User requested feature sdl
> |configure was not able to find it.
> |Install SDL devel
>
> I'm guessing that this is me being dim and that build/conf/local.conf isn't
> what the documentation refers to as "your distribution configuration file".
> Can someone point me in the right direction?

I think the qemu build is looking for your build machine's native SDL
(or SDL-devel) so that the resulting qemu can run. Usually a
conf/local.conf includes the following lines:

PACKAGECONFIG_append_pn-qemu-native = " sdl"
PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
ASSUME_PROVIDED += "libsdl-native"

I think if you remove/comment-out the last of those 3 lines or install
your host's SDL-devel package you'll solve this issue (?)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] I hate busybox!

[Romain Perier]

Hi all,

I disagree,
Unfortunately some embedded devices in the industry are not like most
of the tablets and smartphones in the market (no quad or octo cores
with few GB of ram... and few GB of flash...)   ;)  .For example,
these days, at work, we're designing a board with the SoC zynq-7000
and a quad-spi NOR flash. The NOR only has 16MB... now remove ~2Mb for
u-boot... 4Mb for the bistream (fpga)... I only have 10MB for my
kernel and my rootfs.

Embedded projects like uclibc, musl or busybox are very appreciated in
cases like this one :)

I am not saying that it is a great thing to have busybox built and
enabled by default, but that is a great thing to be able to use it.
In fact, it strongly depends on your needs for the target...

Regards,
Romain

2015-09-15 17:39 GMT+02:00 William Mills :
>
> On 09/15/2015 10:53 AM, Trevor Woerner wrote:
>> On 09/15/15 10:47, Trevor Woerner wrote:
>>> The only place busybox (and
>>> toybox) are needed today are in the MMU-less-type systems, such as
>>> Cortex-Ms etc.
>>
>> Actually, the presence or lack of MMU is irrelevant, I meant to single
>> out those systems with limited on-SoC flash.
>>
>
> OE-core is capable of building a system that has no GPLv3.
> This capability is still important to some users and busybox is needed
> for that as I understand.
>
> (Other users want the capability to build a system w/o proprietary code.
>  OE serves both needs.)
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] gcc reports sysroot is /not/exist!

[Robert Berger]

Hi,

I had a similar problem with you, but was able to fix it by replacing in
some global makefile:

CXX=${CROSS_COMPILE}g++
CC=${CROSS_COMPILE}gcc
LINKER=${CROSS_COMPILE}gcc
LOADER=${CROSS_COMPILE}ldd

with:

#CXX=${CROSS_COMPILE}g++
#CC=${CROSS_COMPILE}gcc
#LINKER=${CROSS_COMPILE}gcc
LINKER=$(CC)
#LOADER=${CROSS_COMPILE}ldd

Regards,

Robert
..."Whereas Europeans generally pronouce my name the right way (Ni-klows
Virt), Americans invariably mangle it into 'Nickle-less Worth'. This is
to say that Europeans call me by name, but Americans call me by value."
-- Niklaus Wirth

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1


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

Re: [yocto] I hate busybox!

[Bob Cochran]

On 09/15/2015 12:38 PM, Romain Perier wrote:

Hi all,

I disagree,
Unfortunately some embedded devices in the industry are not like most
of the tablets and smartphones in the market (no quad or octo cores
with few GB of ram... and few GB of flash...)   ;)  .For example,
these days, at work, we're designing a board with the SoC zynq-7000
and a quad-spi NOR flash. The NOR only has 16MB... now remove ~2Mb for
u-boot... 4Mb for the bistream (fpga)... I only have 10MB for my
kernel and my rootfs.

Embedded projects like uclibc, musl or busybox are very appreciated in
cases like this one :)

I am not saying that it is a great thing to have busybox built and
enabled by default, but that is a great thing to be able to use it.
In fact, it strongly depends on your needs for the target...


Agreed.

I just tack on IMAGE_INSTALL_append = " tar findutils tree etc..." in my 
image recipe when I have the rootfs space, and I want the full tool. 
The build system seems to do a nice job of creating the links properly.





Regards,
Romain

2015-09-15 17:39 GMT+02:00 William Mills :


On 09/15/2015 10:53 AM, Trevor Woerner wrote:

On 09/15/15 10:47, Trevor Woerner wrote:

The only place busybox (and
toybox) are needed today are in the MMU-less-type systems, such as
Cortex-Ms etc.


Actually, the presence or lack of MMU is irrelevant, I meant to single
out those systems with limited on-SoC flash.



OE-core is capable of building a system that has no GPLv3.
This capability is still important to some users and busybox is needed
for that as I understand.

(Other users want the capability to build a system w/o proprietary code.
  OE serves both needs.)


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


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

Re: [yocto] I hate busybox!

[Trevor Woerner]

On 09/15/15 13:01, Bob Cochran wrote:
> On 09/15/2015 12:38 PM, Romain Perier wrote:
>> Hi all,
>>
>> I disagree,
>> Unfortunately some embedded devices in the industry are not like most
>> of the tablets and smartphones in the market (no quad or octo cores
>> with few GB of ram... and few GB of flash...)   ;)  .For example,
>> these days, at work, we're designing a board with the SoC zynq-7000
>> and a quad-spi NOR flash. The NOR only has 16MB... now remove ~2Mb for
>> u-boot... 4Mb for the bistream (fpga)... I only have 10MB for my
>> kernel and my rootfs.
>>
>> Embedded projects like uclibc, musl or busybox are very appreciated in
>> cases like this one :)
>>
>> I am not saying that it is a great thing to have busybox built and
>> enabled by default, but that is a great thing to be able to use it.
>> In fact, it strongly depends on your needs for the target...
>
> Agreed.
>
> I just tack on IMAGE_INSTALL_append = " tar findutils tree etc..." in
> my image recipe when I have the rootfs space, and I want the full
> tool. The build system seems to do a nice job of creating the links
> properly.

This is merely an example of the exception being taken for the norm/default.

You'd be hard-pressed to find many boards that don't have an SD or
microSD slot for your bootloader, kernel, and filesystem image. And
you'd be hard-pressed to buy an SD/microSD card less than 8GB now-a-days.

Even amongst boards that have on-board flash, most of them have 1GB or
more with 4GB being quite common:

   
https://en.wikipedia.org/wiki/Comparison_of_single-board_computers#I.2FO_interfaces_and_ports

In any case, choice in deciding what goes into an image is good. I
simply think that, now-a-days, basing all images on busybox (and having
the option to swap some out) is rather quaint. The problem is: your
image doesn't have "ls", it has "busybox's ls". And your image doesn't
have "ps", it has "busybox's ps"... and those aren't the same. In most
cases I want the "real" utilities (the ones I've spent that last 20
years using) not some crippled version.

Ideally the basic OE images would be based on the real utilities (i.e.
the images that get built by default and tested by the Yocto Project's
QA machinery), and there would be a core-image-minimal-busybox (and
core-image-minimal-toybox) provided in those vanishingly rare cases
where they might be needed. Instead of the current situation where
busybox is the default, and some images swap out some of its components
for the real ones.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] I hate busybox!

[Bob Cochran]

On 09/15/2015 02:22 PM, Trevor Woerner wrote:

On 09/15/15 13:01, Bob Cochran wrote:

On 09/15/2015 12:38 PM, Romain Perier wrote:

Hi all,

I disagree,
Unfortunately some embedded devices in the industry are not like most
of the tablets and smartphones in the market (no quad or octo cores
with few GB of ram... and few GB of flash...)   ;)  .For example,
these days, at work, we're designing a board with the SoC zynq-7000
and a quad-spi NOR flash. The NOR only has 16MB... now remove ~2Mb for
u-boot... 4Mb for the bistream (fpga)... I only have 10MB for my
kernel and my rootfs.

Embedded projects like uclibc, musl or busybox are very appreciated in
cases like this one :)

I am not saying that it is a great thing to have busybox built and
enabled by default, but that is a great thing to be able to use it.
In fact, it strongly depends on your needs for the target...


Agreed.

I just tack on IMAGE_INSTALL_append = " tar findutils tree etc..." in
my image recipe when I have the rootfs space, and I want the full
tool. The build system seems to do a nice job of creating the links
properly.


This is merely an example of the exception being taken for the norm/default.

You'd be hard-pressed to find many boards that don't have an SD or
microSD slot for your bootloader, kernel, and filesystem image. And
you'd be hard-pressed to buy an SD/microSD card less than 8GB now-a-days.

Even amongst boards that have on-board flash, most of them have 1GB or
more with 4GB being quite common:


Right, but I want to use FLASH to store a lot of nonvolatle R/W data, 
not just applications, libraries, and the kernel, so a couple GB doesn't 
go very far.


Do you know offhand how much bigger the rootfs would be if you build 
core-image-base without busybox and instead use the real applications?


Also, how many more packages have to be built / managed?

Thanks






https://en.wikipedia.org/wiki/Comparison_of_single-board_computers#I.2FO_interfaces_and_ports

In any case, choice in deciding what goes into an image is good. I
simply think that, now-a-days, basing all images on busybox (and having
the option to swap some out) is rather quaint. The problem is: your
image doesn't have "ls", it has "busybox's ls". And your image doesn't
have "ps", it has "busybox's ps"... and those aren't the same. In most
cases I want the "real" utilities (the ones I've spent that last 20
years using) not some crippled version.

Ideally the basic OE images would be based on the real utilities (i.e.
the images that get built by default and tested by the Yocto Project's
QA machinery), and there would be a core-image-minimal-busybox (and
core-image-minimal-toybox) provided in those vanishingly rare cases
where they might be needed. Instead of the current situation where
busybox is the default, and some images swap out some of its components
for the real ones.



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

[yocto] Release Candidate Build for yocto-1.8 now available.

[Poky Build User]

-e 
A release candidate build for yocto-1.8 is now available at:

 
http://autobuilder.yoctoproject.org/pub/releases/yocto-1.8_M1+snapshot


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : cea00968b858b60222d68103491f076067d73876 
meta-fsl-arm : 24396b28f0137464cd82b9a19f705c1db180ead2 
meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 
meta-fsl-ppc : afd057b4492beab1f6884b007a0a877e3a673fe9 
poky : ea562de57590c966cd5a75fda8defecd397e6436 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flana...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] I hate busybox!

[Paul D. DeRocco]

> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] 
> 
> core-image-full-cmdline (and the packagegroup it uses, 
> packagegroup-core-full-
> cmdline) should give you the former, and the full tools will 
> in almost all 
> cases take precedence simply by being installed by virtue of 
> the alternatives 
> system. In order to actually remove busybox though you'd need 
> to break apart 
> packagegroup-core-boot (i.e. include its constituent parts 
> separately into 
> your image instead of the packagegroup itself).

That was pretty painless, since I don't actually need to remove busybox.
Thanks.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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

Re: [yocto] I hate busybox!

[Paul D. DeRocco]

> From: Bob Cochran
> 
> Do you know offhand how much bigger the rootfs would be if you build 
> core-image-base without busybox and instead use the real applications?
> 
> Also, how many more packages have to be built / managed?

I just added packagegroup-core-full-cmdline to my image, and it increased
the size by about 36MB. That's on a 32-bit Intel system. I don't know how
many packages are in that group, but all I had to do was add that one word
to my IMAGE_INSTALL, so I don't really care.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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

[yocto] Hanging during kernel boot

[Paul D. DeRocco]

I've been redoing an old Danny project with Fido, running on an Atom mobo.
I created a fresh BSP with yocto-bsp, using a RT kernel, and haven't begun
to fiddle with the kernel configuration yet. It gets part way through the
boot process and hangs at "Switching to clocksource tsc". I've googled
this error, which lots of people have had on lots of systems (Ubuntu,
etc.), and have solved in lots of different ways, none of which seem to
relate to my system. I don't believe it has anything to do with the tsc.

The system doesn't crash. I can bang on the keyboard, and the keys are
echoed. After seven or so presses, I get a "random: nonblocking pool is
initialized" message (something to do with entropy collection, I guess).
So the kernel is running, but it's like systemd (which I've substituted
for sysvinit) has just hung.

Since I haven't gotten to a prompt, I can't do anything. Does anyone have
any ideas how I might diagnose this? Are there any kernel parameters I
might fiddle with on the flash memory? And where does one do such
fiddling, with a syslinux-based live image? Or should I be selectively
removing things from my BSP that were put there by yocto-bsp?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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

Re: [yocto] I hate busybox!

[Khem Raj]

> On Sep 15, 2015, at 7:47 AM, Trevor Woerner  wrote:
> 
> On 09/15/15 04:26, Paul D. DeRocco wrote:
>> My embedded system has enough room in it for full-featured command line
>> tools, instead of the wretched busybox. Does the Yocto meta-data include a
>> layer that provides such tools? Or does OE? And how would I disable
>> busybox in order to use the better tools?
> 
> +1
> 
> ...although "hate" is a strong word, I have been tripped up numerous
> times in the past by writing a script on my development host only to
> find it doesn't work on my target device due to the restrictions of the
> various busybox executables. The "embedded" system of today is the
> desktop system of only a couple years ago. The only place busybox (and
> toybox) are needed today are in the MMU-less-type systems, such as
> Cortex-Ms etc.

I agree on busybox differences but sometimes its not about the utilities they 
are needed for some sundry work.
What would be interesting to know is how much size increase is caused by 
replacing all busybox functionality
with other utilities and also RAM consumption. That can give valuable 
information for someone who is assembling embedded system stack and help 
him/her the decision making. embedded systems of today might have more memory 
and what not, but they are also running more
complex applications than in past, so software bloat has caught up with more 
memory, in the end you still need to be cautious about the footprint and 
equation remains almost same.

I believe once we have a busybox replacement package group we can get the 
information I asked in para 1 which is a good thing.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] I hate busybox!

[Paul D. DeRocco]

> From: Khem Raj [mailto:raj.k...@gmail.com] 
> 
> I agree on busybox differences but sometimes its not about 
> the utilities they are needed for some sundry work.
> What would be interesting to know is how much size increase 
> is caused by replacing all busybox functionality
> with other utilities and also RAM consumption. That can give 
> valuable information for someone who is assembling embedded 
> system stack and help him/her the decision making. embedded 
> systems of today might have more memory and what not, but 
> they are also running more
> complex applications than in past, so software bloat has 
> caught up with more memory, in the end you still need to be 
> cautious about the footprint and equation remains almost same.

As I said in another message, my 32-bit Intel system image increased by
36MB when I added the full utilities. The busybox executable is half a
meg, while individual full-featured commands are generally a few tens of
kilobytes. I don't know if running busybox loads the whole thing into
physical RAM, or if it only allocates the pages that are actually touched;
that would determine the relative RAM use, I suppose.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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

[yocto] Opportunity for Yoto developer (m/f)

[Sarah Hindermann]

Hello Yocto Fans,

I am   looking for a Yocto /   Linux developer (m/w) for a   Project in Germany.

I am interested in permanent employees or contractors who know  Yocto well.



Concerning contractors part time support would also be an option  as  well as 
remote  possibility after a view weeks.

The project is about developing the new product concerning datalogger in  C++.



German language skills are a benefit but not a must. English is sufficient.

 More information at:

 
https://www.xing.com/communities/posts/embedded-linux-entwickler-mit-yocto-w-strich-m-in-darmstadt-asap-remote-mgl-1010137514



 If you have a friend or colleague who might be interested  feel free to  
forward my message.

 Thank you.

 I wish you a wonderful Wednesday!

Sarah


Sarah Hindermann
Recruitment Consultant for Contractors

T: +49  (0) 693 650 650 55
F: +49  (0) 693 650 650 57
M: s.hinderm...@roc-search.de
X: 
www.xing.com/profile/Sarah_Hindermann
H: www.roc-search.de

[Description: Description: Description: Description: Description: Description: 
Description: Description: Description: Description: 
C:\Users\lucy.meddings\Desktop\New logo\ROC_RGB.png]
Roc Search GmbH - Roßmarkt 10 - 60311 Frankfurt am Main

[IIP_LOGO_BLUE_CMYK] [Description: Description: 
C:\Users\lucy.meddings.ROCSEARCH\AppData\Local\Microsoft\Windows\Temporary 
Internet Files\Content.Outlook\10TW11RW\APSCo stacked JPEG for high res 
printing (2) (2).JPG]  [Description: 2012 Fast Track 100 logo (7)] 
[http://www.roc-search.com/File.ashx?path=Root/Images/2013_Fast_Track_100_logo.jpg]

Click Here to check out the 
latest News at Roc Search...

Whether you work with or for us, whether we place you or place people for you, 
at Roc Search our passion is for people and the placements we make. As clients 
and candidates you can be sure we'll take nothing for granted and take the time 
you and we need, to build mutual insight and trust. The smallest new start-ups 
and the largest corporates, the experienced professional and ambitious 
beginner: whoever you are and whatever your story, we believe you deserve a 
flexible, responsive and personal service which delivers the results you need.
At Roc Search we guarantee that's exactly what you can expect.
The information contained in this email may be privileged and is intended for 
the personal and confidential use of the recipient(s) named above. If the 
reader of this message is not the intended recipient or an agent responsible 
for delivering it to the intended recipient, you are hereby notified that you 
have received this email in error and that any review, dissemination or copying 
of this message is strictly prohibited. If you have received this email in 
error, please notify us immediately.
This message and any attachments are believed to be free of any virus or defect 
that might affect any computer system into which it is received and opened. 
However, it is the responsibility of the recipient to ensure that it is virus 
free; therefore, no responsibility is accepted for any loss or damage in any 
way arising from its use
Roc Search Limited. Registered address: The Blade, Abbey Square, Reading, 
Berkshire, RG1 3BE Company Registration number: 06044636.

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