gcc-cross-sdk (GCC 4.2.3) limits.h woes

gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Chris Conroy]

I've spent a pretty good chunk of time this past week trying to get a
working external toolchain, but I've hit a bit of a wall and can't
figure out how to fix this last problem.

I'm trying to build a gcc-cross-sdk with GCC 4.2.3, and for a while I
faced a chicken-and-egg problem of finding limits.h where the creation
of the cross-sdk would succeed only if the eventual install location
(in /usr/local/path/to/toolchain/ existed). By pulling in the
sdk-libstdc++-includes.patch from poky, I was able to remove this issue
during the creation of gcc-cross-sdk.

Now, chicken and egg fixed (properly?) using the external toolchain
results in cross packages failing to find limits.h (specifically, the
#include_next<limits.h> in ${prefix}/usr/include/limits.h. It's unclear
to me which (if any) limits.h should be installed (and where).

I've run through the gcc-cross-sdk work directory and was unable to find
any obvious choices (all of the copies there also asked for an
include_next).

If I make the assumption that this is just an erroneous include_next, I
can successfully compile and run some packages. However, I cannot build
the kernel because it fails on the assembly inside asm_offsets.c. This
leads me to believe that removing that include_next was not a valid fix
(no surprise there), and perhaps fixing this limits.h issue properly
will be the last step in creating a working external toolchain. I don't
see any obvious choices within gcc, but perhaps I need to pull from
glibc, glibc-initial, or perhaps a particular host file?

Note that this is NOT GCC 4.3.x which moved the fixincludes directory
and made some issues with finding limits.h. Most of the references I've
found to this bug indicate that people had this working before upgrading
to 4.3.x, and therefore I'm a bit surprised to be running into a similar
issue with 4.2.x

(For reference, this is with glibc 2.7 and binutils 2.19 for a
mipsel-linux target building on an x86_64 host)

--Chris Conroy

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Holger Hans Peter Freyther]

On Thursday 13 August 2009 17:19:10 Chris Conroy wrote:
> I've spent a pretty good chunk of time this past week trying to get a
> working external toolchain, but I've hit a bit of a wall and can't
> figure out how to fix this last problem.

I'm a bit hungry so here is just my config:

conf/local.conf
DL_DIR = "${HOME}/source/sources/"
DISTRO = "angstrom-2008.1"
MACHINE="db1200"
IMAGE_FSTYPES += " ext2 "

BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j4"
ENABLE_BINARY_LOCALE_GENERATION="0"
ENTERPRISE_DISTRO = "1"

BBFILES="${HOME}/source/embedded/openembedded/recipes"

$ bitbake meta-toolchain-qte

just passed today (thanks to Graham's work).. on my i686..


     binutils: 2.18
     gcc: 4.3.3
     glibc: 2.9


maybe that is useful?


PS: For gcc4.2.x we need to pass more include dirs... the error with 
#include_next is that it runs out of search paths.... With poky I pushed it a 
bit but didn't manage to build a working version

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Khem Raj]

On (13/08/09 11:19), Chris Conroy wrote:
> I've spent a pretty good chunk of time this past week trying to get a
> working external toolchain, but I've hit a bit of a wall and can't
> figure out how to fix this last problem.
> 
> I'm trying to build a gcc-cross-sdk with GCC 4.2.3, and for a while I
> faced a chicken-and-egg problem of finding limits.h where the creation
> of the cross-sdk would succeed only if the eventual install location
> (in /usr/local/path/to/toolchain/ existed). By pulling in the
> sdk-libstdc++-includes.patch from poky, I was able to remove this issue
> during the creation of gcc-cross-sdk.
> 
> Now, chicken and egg fixed (properly?) using the external toolchain
> results in cross packages failing to find limits.h (specifically, the
> #include_next<limits.h> in ${prefix}/usr/include/limits.h. It's unclear
> to me which (if any) limits.h should be installed (and where).

limits.h should come from glibc. which should include the one provided
by gcc in include-fixed gcc-cross-sdk should have done that.
Deleting include_next is not the correct thing to do.
> 
> I've run through the gcc-cross-sdk work directory and was unable to find
> any obvious choices (all of the copies there also asked for an
> include_next).
> 
> If I make the assumption that this is just an erroneous include_next, I
> can successfully compile and run some packages. However, I cannot build
> the kernel because it fails on the assembly inside asm_offsets.c. This
> leads me to believe that removing that include_next was not a valid fix
> (no surprise there), and perhaps fixing this limits.h issue properly
> will be the last step in creating a working external toolchain. I don't
> see any obvious choices within gcc, but perhaps I need to pull from
> glibc, glibc-initial, or perhaps a particular host file?
> 
> Note that this is NOT GCC 4.3.x which moved the fixincludes directory
> and made some issues with finding limits.h. Most of the references I've
> found to this bug indicate that people had this working before upgrading
> to 4.3.x, and therefore I'm a bit surprised to be running into a similar
> issue with 4.2.x
> 
> (For reference, this is with glibc 2.7 and binutils 2.19 for a
> mipsel-linux target building on an x86_64 host)
> 
> --Chris Conroy
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Chris Conroy]

I was finally able to determine the cause of the problem. Even though I
had wiped my TMPDIR, I had a broken GCC 4.3 sitting in my DEPLOYDIR
which was contaminating the installation. Once removed, I was able to
get the GCC 4.2.3 installation to work.

However, I've run in to a different problem. It seems that Debian
Renaming does not play nicely with the external toolchain. Digging into
the code, it seems that Debian renaming relies on the package being in
the workdir to do its magic, which for any prebuilt SDK packages will
not hold true. Any thoughts on the proper route to fix this aside from
just turning of Debian Renaming?

On Thu, 2009-08-13 at 08:59 -0700, Khem Raj wrote:
> On (13/08/09 11:19), Chris Conroy wrote:
> > I've spent a pretty good chunk of time this past week trying to get a
> > working external toolchain, but I've hit a bit of a wall and can't
> > figure out how to fix this last problem.
> > 
> > I'm trying to build a gcc-cross-sdk with GCC 4.2.3, and for a while I
> > faced a chicken-and-egg problem of finding limits.h where the creation
> > of the cross-sdk would succeed only if the eventual install location
> > (in /usr/local/path/to/toolchain/ existed). By pulling in the
> > sdk-libstdc++-includes.patch from poky, I was able to remove this issue
> > during the creation of gcc-cross-sdk.
> > 
> > Now, chicken and egg fixed (properly?) using the external toolchain
> > results in cross packages failing to find limits.h (specifically, the
> > #include_next<limits.h> in ${prefix}/usr/include/limits.h. It's unclear
> > to me which (if any) limits.h should be installed (and where).
> 
> limits.h should come from glibc. which should include the one provided
> by gcc in include-fixed gcc-cross-sdk should have done that.
> Deleting include_next is not the correct thing to do.
> > 
> > I've run through the gcc-cross-sdk work directory and was unable to find
> > any obvious choices (all of the copies there also asked for an
> > include_next).
> > 
> > If I make the assumption that this is just an erroneous include_next, I
> > can successfully compile and run some packages. However, I cannot build
> > the kernel because it fails on the assembly inside asm_offsets.c. This
> > leads me to believe that removing that include_next was not a valid fix
> > (no surprise there), and perhaps fixing this limits.h issue properly
> > will be the last step in creating a working external toolchain. I don't
> > see any obvious choices within gcc, but perhaps I need to pull from
> > glibc, glibc-initial, or perhaps a particular host file?
> > 
> > Note that this is NOT GCC 4.3.x which moved the fixincludes directory
> > and made some issues with finding limits.h. Most of the references I've
> > found to this bug indicate that people had this working before upgrading
> > to 4.3.x, and therefore I'm a bit surprised to be running into a similar
> > issue with 4.2.x
> > 
> > (For reference, this is with glibc 2.7 and binutils 2.19 for a
> > mipsel-linux target building on an x86_64 host)
> > 
> > --Chris Conroy
> > 
> > 
> > 
> > _______________________________________________
> > 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: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Denys Dmytriyenko]

On Tue, Aug 18, 2009 at 12:27:59PM -0400, Chris Conroy wrote:
> However, I've run in to a different problem. It seems that Debian
> Renaming does not play nicely with the external toolchain. Digging into
> the code, it seems that Debian renaming relies on the package being in
> the workdir to do its magic, which for any prebuilt SDK packages will
> not hold true. Any thoughts on the proper route to fix this aside from
> just turning of Debian Renaming?

Can you please provide more details on the problem? Thanks.

-- 
Denys

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Chris Conroy]

Sorry for not providing more detail at first...

With debian renaming on, glibc, for example, gets renamed to 'libc6' and
packaged as such. Normally, this works because the other packages pick
up the rename at some point along the way. The comment at the top of
debian.bbclass states:

# Debian package renaming only occurs when a package is built
# We therefore have to make sure we build all runtime packages
# before building the current package to make the packages runtime
# depends are correct

So, glibc is packaged as part of my toolchain's sdk. Building
meta-toolchain works just fine. Then, I go to build an image using the
external-toolchain. It fails because opkg cannot satisfy the dependency
for 'glibc (>=2.7)'. This is because the ipkg generated by the debian
rename is named 'libc6_2.7-r9_mipsel.ipk'. During the creation of the
toolchain, all packages picked up this rename. 

Since glibc does not get rebuilt when *using* the external toolchain
(that's sort of the whole point), the debian rename does not occur, and
we have this name mismatch.

This same issue occurs for the other libs in my sdk including libstdc++,
libgcc, etc..

The error went away for me after I turned off Debian Renaming.

On Tue, 2009-08-18 at 13:41 -0400, Denys Dmytriyenko wrote:
> On Tue, Aug 18, 2009 at 12:27:59PM -0400, Chris Conroy wrote:
> > However, I've run in to a different problem. It seems that Debian
> > Renaming does not play nicely with the external toolchain. Digging into
> > the code, it seems that Debian renaming relies on the package being in
> > the workdir to do its magic, which for any prebuilt SDK packages will
> > not hold true. Any thoughts on the proper route to fix this aside from
> > just turning of Debian Renaming?
> 
> Can you please provide more details on the problem? Thanks.
> 

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Tom Rini]

On Tue, Aug 18, 2009 at 02:30:12PM -0400, Chris Conroy wrote:

> Sorry for not providing more detail at first...
> 
> With debian renaming on, glibc, for example, gets renamed to 'libc6' and
> packaged as such. Normally, this works because the other packages pick
> up the rename at some point along the way. The comment at the top of
> debian.bbclass states:
> 
> # Debian package renaming only occurs when a package is built
> # We therefore have to make sure we build all runtime packages
> # before building the current package to make the packages runtime
> # depends are correct
> 
> So, glibc is packaged as part of my toolchain's sdk. Building
> meta-toolchain works just fine. Then, I go to build an image using the
> external-toolchain. It fails because opkg cannot satisfy the dependency

OK, here's the problem, I think.  You're trying to make an image for say
i686-armv6-sdk-linux-gnueabi?  What are you expecting to be in this raw
image however, the contents of say meta-toolchain, extracted and put
into a ext2?  For most people, meta-toolchain, and the resulting tarball
are the output that gets used.

-- 
Tom Rini

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Chris Conroy]

On Tue, 2009-08-18 at 12:50 -0700, Tom Rini wrote:
> 
> OK, here's the problem, I think.  You're trying to make an image for say
> i686-armv6-sdk-linux-gnueabi?  What are you expecting to be in this raw
> image however, the contents of say meta-toolchain, extracted and put
> into a ext2?  For most people, meta-toolchain, and the resulting tarball
> are the output that gets used.
> 

The problem is the dependencies get satisfied during the build because
package X depends on glibc, but external-toolchain.bb chimes in and says
"Hi, I provide virtual/libc." Package X builds and links just fine since
the external-toolchain dropped everything in the right place.

The problem comes whenever opkg needs to deal with dependencies since it
doesn't know about 'virtual/libc'. It sees that Package X wants glibc
and it can't find it since it only knows about the debian-named version
called 'libc6'. Glibc never gets built (since it's already been built)
and thus never gets debian renamed.

I don't see any easy path to change debian.bbclass since it requires
introspection on the TMPDIR which does not exist for users of an
external toolchain.

I hope this is clear. Let me know if there are any points of confusion.

In the meantime, turning off the renaming successfully works around this
bug.

--Chris Conroy

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Phil Blundell]

On Tue, 2009-08-18 at 16:10 -0400, Chris Conroy wrote:
> I don't see any easy path to change debian.bbclass since it requires
> introspection on the TMPDIR which does not exist for users of an
> external toolchain.

There shouldn't be any need to change debian.bbclass; its work is
already done at the point where your problem is occurring.  It sounds
like your external toolchain is simply failing to ship the appropriate
pkgdata files, and/or package.bbclass is failing to read them in for
some reason.

p.

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Khem Raj]

On Tue, Aug 18, 2009 at 1:10 PM, Chris
Conroy<Chris.Conroy@hillcrestlabs.com> wrote:
> On Tue, 2009-08-18 at 12:50 -0700, Tom Rini wrote:
>>
>> OK, here's the problem, I think.  You're trying to make an image for say
>> i686-armv6-sdk-linux-gnueabi?  What are you expecting to be in this raw
>> image however, the contents of say meta-toolchain, extracted and put
>> into a ext2?  For most people, meta-toolchain, and the resulting tarball
>> are the output that gets used.
>>
>
> The problem is the dependencies get satisfied during the build because
> package X depends on glibc, but external-toolchain.bb chimes in and says
> "Hi, I provide virtual/libc." Package X builds and links just fine since
> the external-toolchain dropped everything in the right place.
>
> The problem comes whenever opkg needs to deal with dependencies since it
> doesn't know about 'virtual/libc'. It sees that Package X wants glibc
> and it can't find it since it only knows about the debian-named version
> called 'libc6'. Glibc never gets built (since it's already been built)
> and thus never gets debian renamed.
>
> I don't see any easy path to change debian.bbclass since it requires
> introspection on the TMPDIR which does not exist for users of an
> external toolchain.
>
> I hope this is clear. Let me know if there are any points of confusion.
>
> In the meantime, turning off the renaming successfully works around this
> bug.

Do you have to use glibc built externally ? I would think that use
external compiler
and tools but build everything else that goes on target which is also libc.

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

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Phil Blundell]

On Tue, 2009-08-18 at 14:25 -0700, Khem Raj wrote:
> Do you have to use glibc built externally ? I would think that use
> external compiler
> and tools but build everything else that goes on target which is also libc.

I think that, for most folks, avoiding the epic glibc build process is
probably one of the main attractions of an external toolchain.

In any case, building glibc from source wouldn't actually remove this
problem since you would then just have the same trouble with libgcc,
libobjc and suchlike.

p.

External Toolchains Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Denys Dmytriyenko]

On Tue, Aug 18, 2009 at 10:32:42PM +0100, Phil Blundell wrote:
> On Tue, 2009-08-18 at 14:25 -0700, Khem Raj wrote:
> > Do you have to use glibc built externally ? I would think that use
> > external compiler
> > and tools but build everything else that goes on target which is also libc.
> 
> I think that, for most folks, avoiding the epic glibc build process is
> probably one of the main attractions of an external toolchain.
> 
> In any case, building glibc from source wouldn't actually remove this
> problem since you would then just have the same trouble with libgcc,
> libobjc and suchlike.

Those libraries and their pkgdata have to be provided in the ipk/, pkgdata/ 
and shlibs/ directories of an external toolchain. The external-toolchain.bb 
recipe itself then copies them into the deploy directory and they are then 
used during the image generation process. I've been using it for quite some 
time and see no problems with debian naming, i.e. glibc vs. libc6. Check 
do_stage of external-toolchain.bb to see what it expects.

Please note, that meta-toolchain.bb by default produces an SDK, which can be 
used outside of OE for cross-compiling. It can also be used inside OE for 
compilation by using external-toolchain.bb, but the step which packages ipks 
and pkgdata for libc and libgcc to be installed into the filesystem, is 
missing from the meta-toolchain.bb...

BTW, I'm using external-toolchain.bb in my project for prebuilt binary 
toolchains, like CodeSourcery Lite or old MontaVista Pro. I have their 
libraries packaged into ipks for rootfs to work. One way is to extend 
external-toolchain.bb recipe to do the packaging...

-- 
Denys

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Holger Hans Peter Freyther]

On Tuesday 18 August 2009 20:30:12 Chris Conroy wrote:
> Sorry for not providing more detail at first...
>
> With debian renaming on, glibc, for example, gets renamed to 'libc6' and
> packaged as such. Normally, this works because the other packages pick
> up the rename at some point along the way. The comment at the top of
> debian.bbclass states:
>
> # Debian package renaming only occurs when a package is built
> # We therefore have to make sure we build all runtime packages
> # before building the current package to make the packages runtime
> # depends are correct
>
> So, glibc is packaged as part of my toolchain's sdk. Building
> meta-toolchain works just fine. Then, I go to build an image using the
> external-toolchain. It fails because opkg cannot satisfy the dependency
> for 'glibc (>=2.7)'. This is because the ipkg generated by the debian
> rename is named 'libc6_2.7-r9_mipsel.ipk'. During the creation of the
> toolchain, all packages picked up this rename.

Have you seen this:
   http://docs.openembedded.org/usermanual/html/commonuse_prebuilt_toolchain.html#id388796


does it help in any way? To be honest I'm still missing how you try to create 
the image and if you rebuilt glibc or application or such..

	z.

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Chris Conroy]

On Wed, 2009-08-19 at 05:17 +0200, Holger Hans Peter Freyther wrote:
> Have you seen this:
>    http://docs.openembedded.org/usermanual/html/commonuse_prebuilt_toolchain.html#id388796
> 
> 
> does it help in any way? To be honest I'm still missing how you try to create 
> the image and if you rebuilt glibc or application or such..
> 
> 	z.
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Yes, but I get the sense (perhaps wrongly) that these directions are a
bit out of date since they don't mention the meta-toolchain or
external-toolchain. I'm trying to both build and use a toolchain
entirely within OE.

I have a feeling that Phil's suggestion to look into what's going on
with pkgdata is the right approach since I think a few things were
slightly out of place there when I started to work on this.

--Chris Conroy

Re: gcc-cross-sdk (GCC 4.2.3) limits.h woes

[Holger Hans Peter Freyther]

On Wednesday 19 August 2009 16:26:59 Chris Conroy wrote:
> On Wed, 2009-08-19 at 05:17 +0200, Holger Hans Peter Freyther wrote:
> > Have you seen this:
> >   
> > http://docs.openembedded.org/usermanual/html/commonuse_prebuilt_toolchain
> >.html#id388796
> >
> >
> > does it help in any way? To be honest I'm still missing how you try to
> > create the image and if you rebuilt glibc or application or such..
> >
> > 	z.
> >
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
> Yes, but I get the sense (perhaps wrongly) that these directions are a
> bit out of date since they don't mention the meta-toolchain or
> external-toolchain. I'm trying to both build and use a toolchain
> entirely within OE.

meta-toolchain is a bit irrelevant as this page doesn't care for where the 
toolchain comes from, you are right about the external-toolchain part and the 
documentation needs to be updated. ASSUME_SHLIBS will still help you to hint 
OE which package contains libc6.so

regards
	holger

Is there an easy way to get a minimalist image without I18n libraries?

[Lars Holowko]

Hi there,

I am playing with the minimal-image on this configuration:

MACHINE = "at91sam9g20ek"
DISTRO = "angstrom-2008.1"
ANGSTROMLIBC = "uclibc"

and now I am wondeering if in order to save some flash space there is a
way to build a minimal-image without libiconv, gettext and friends? That
would save me about 2.5MB of flash space!!!

If I check USE_NLS with bitbake -I; getvar USE_NLS reposrts "no". So I
would assume all the NLS would be disabled.

To save even more flash space, is there also a way to disable the
installation of opkg and its dependencies like: libgnutls26, libcurl4?


Regards,

Lars
 
**********************************************************************
This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited.

Re: Is there an easy way to get a minimalist image without I18nLibraries?

[marcin]

Dnia Tue, 18 Aug 2009 14:39:04 -0700 napisano:

> I am playing with the minimal-image on this configuration:

> To save even more flash space, is there also a way to disable the
> installation of opkg
> and its dependencies like: libgnutls26, libcurl4?

# Disable online package management
ONLINE_PACKAGE_MANAGEMENT = "none"

Add this into your image recipe.

Re: Is there an easy way to get a minimalist image without I18nLibraries?

[Lars Holowko]

>> I am playing with the minimal-image on this configuration:
>>
>> To save even more flash space, is there also a way to disable the 
>> installation of opkg and its dependencies like: libgnutls26,
libcurl4?
>
> # Disable online package management
> ONLINE_PACKAGE_MANAGEMENT = "none"
>
> Add this into your image recipe.

Thanks a lot, that got rid off the package management.

If anyone knows how I can get rid off the internationalization stuff,
I'll be compeletly happy..

Lars
 
**********************************************************************
This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited.