problem building meta-toolchain for arm/uclibc

problem building meta-toolchain for arm/uclibc

[Sergey 'Jin' Bostandzhyan]

Hi everyone,

I keep struggling with meta-toolchain and I hope to get some input on this.

I'm on oe stable, angstrom-2007.1, ARM9, uclibc, EABI

I start with a clean build: bitbake meta-toolchain

Unfortunately gcc-cross-sdk fails to build:
NOTE: package gcc-cross-sdk-4.1.2-r11: task do_compile: failed

And here's the most interesting part:
| /opt/44296fe048e6bdbb2da959e5d681dfdf/etcb/OE/build/angstrom/cross/bin/arm-angstrom-linux-uclibcgnueabi-ld: cannot find libc.so.6
| collect2: ld returned 1 exit status
| make[3]: *** [libgcc_s.so] Error 1

Is it looking for libc.so.6 on a uclibc build?

Here is the full log:
http://www.deadlock.dhs.org/jin/log_do_compile_uclibcgnueabi_gcc_cross_sdk.txt

I started to poke around, looking for differences between the configuration
options of the sdk and non-sdk versions.

Apart of the directories most things are the same, the only other additonal
options were in the gcc-cross-sdk (vs. gcc-cross)  configuration:
--enable-clocale=generic and --disable-nls (the non-sdk gcc-cross did not have
those).

I also looked at binutils-cross and binutils-cross-sdk, here binutils-cross
had two more options: --enable-install-libbfd --disable-werror The rest,
except for the paths was the same.

I also noticed that the sdk variants use the already available tools from
the cross directory, not sure if that can be related to my problem
binutils-cross:
checking for arm-angstrom-linux-uclibcgnueabi-gcc... no

binutils-cross-sdk:
checking for arm-angstrom-linux-uclibcgnueabi-gcc... arm-angstrom-linux-uclibcgnueabi-gcc

At this point I am sort of stuck, so if anyone has an idea or a clue - I'll
be happy to hear about it. Thanks!

Kind regards,
Jin

P.S. I'd submit a bug... but the bugtracker is still down :(

Re: problem building meta-toolchain for arm/uclibc

[Khem Raj]

try running the link step alone manually

/opt/44296fe048e6bdbb2da959e5d681dfdf/etcb/OE/build/angstrom/work/i686-arm-sdk-angstrom-linux-uclibcgnueabi/gcc-cross-sdk-4.1.2-r11/gcc-4.1.2/build.i686-linux.arm-angstrom-linux-uclibcgnueabi/./gcc/xgcc
-B/opt/44296fe048e6bdbb2da959e5d681dfdf/etcb/OE/build/angstrom/work/i686-arm-sdk-angstrom-linux-uclibcgnueabi/gcc-cross-sdk-4.1.2-r11/gcc-4.1.2/build.i686-linux.arm-angstrom-linux-uclibcgnueabi/./gcc/
-B/opt/angstrom/arm/arm-angstrom-linux-uclibcgnueabi/bin/
-B/opt/angstrom/arm/arm-angstrom-linux-uclibcgnueabi/lib/ -isystem
/opt/angstrom/arm/arm-angstrom-linux-uclibcgnueabi/include -isystem
/opt/angstrom/arm/arm-angstrom-linux-uclibcgnueabi/sys-include -O2  -g
-Os -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED  -shared -nodefaultlibs
-Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/./libgcc.map -o
./libgcc_s.so.1.tmp  libgcc/./_udivsi3_s.o libgcc/./_divsi3_s.o
libgcc/./_umodsi3_s.o libgcc/./_modsi3_s.o libgcc/./_bb_init_func_s.o
libgcc/./_call_via_rX_s.o libgcc/./_interwork_call_via_rX_s.o
libgcc/./_lshrdi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_ashldi3_s.o
libgcc/./_negdf2_s.o libgcc/./_addsubdf3_s.o libgcc/./_muldivdf3_s.o
libgcc/./_cmpdf2_s.o libgcc/./_unorddf2_s.o libgcc/./_fixdfsi_s.o
libgcc/./_fixunsdfsi_s.o libgcc/./_truncdfsf2_s.o libgcc/./_negsf2_s.o
libgcc/./_addsubsf3_s.o libgcc/./_muldivsf3_s.o libgcc/./_cmpsf2_s.o
libgcc/./_unordsf2_s.o libgcc/./_fixsfsi_s.o libgcc/./_fixunssfsi_s.o
libgcc/./_floatdidf_s.o libgcc/./_floatdisf_s.o
libgcc/./_aeabi_lcmp_s.o libgcc/./_aeabi_ulcmp_s.o
libgcc/./_aeabi_ldivmod_s.o libgcc/./_aeabi_uldivmod_s.o
libgcc/./_dvmd_lnx_s.o libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o
libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o
libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o
libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o
libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o
libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o
libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o
libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o
libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o
libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o
libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o
libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o
libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o
libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o
libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_fixunsxfsi_s.o
libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_fixdfdi_s.o
libgcc/./_fixunsdfdi_s.o libgcc/./_fixxfdi_s.o
libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_fixtfdi_s.o
libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_divdi3_s.o
libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o
libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./bpabi_s.o
libgcc/./unaligned-funcs_s.o libgcc/./unwind-arm_s.o
libgcc/./libunwind_s.o libgcc/./pr-support_s.o libgcc/./unwind-c_s.o
-lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f
./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv
./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1
./libgcc_s.so


and pass options to generate verbose output. It could be related to binutils.



On Mon, Apr 28, 2008 at 12:26 PM, Sergey 'Jin' Bostandzhyan
<jin@mediatomb.cc> wrote:
> Hi everyone,
>
> I keep struggling with meta-toolchain and I hope to get some input on this.
>
> I'm on oe stable, angstrom-2007.1, ARM9, uclibc, EABI
>
> I start with a clean build: bitbake meta-toolchain
>
> Unfortunately gcc-cross-sdk fails to build:
> NOTE: package gcc-cross-sdk-4.1.2-r11: task do_compile: failed
>
> And here's the most interesting part:
> | /opt/44296fe048e6bdbb2da959e5d681dfdf/etcb/OE/build/angstrom/cross/bin/arm-angstrom-linux-uclibcgnueabi-ld: cannot find libc.so.6
> | collect2: ld returned 1 exit status
> | make[3]: *** [libgcc_s.so] Error 1
>
> Is it looking for libc.so.6 on a uclibc build?
>
> Here is the full log:
> http://www.deadlock.dhs.org/jin/log_do_compile_uclibcgnueabi_gcc_cross_sdk.txt
>
> I started to poke around, looking for differences between the configuration
> options of the sdk and non-sdk versions.
>
> Apart of the directories most things are the same, the only other additonal
> options were in the gcc-cross-sdk (vs. gcc-cross)  configuration:
> --enable-clocale=generic and --disable-nls (the non-sdk gcc-cross did not have
> those).
>
> I also looked at binutils-cross and binutils-cross-sdk, here binutils-cross
> had two more options: --enable-install-libbfd --disable-werror The rest,
> except for the paths was the same.
>
> I also noticed that the sdk variants use the already available tools from
> the cross directory, not sure if that can be related to my problem
> binutils-cross:
> checking for arm-angstrom-linux-uclibcgnueabi-gcc... no
>
> binutils-cross-sdk:
> checking for arm-angstrom-linux-uclibcgnueabi-gcc... arm-angstrom-linux-uclibcgnueabi-gcc
>
> At this point I am sort of stuck, so if anyone has an idea or a clue - I'll
> be happy to hear about it. Thanks!
>
> Kind regards,
> Jin
>
> P.S. I'd submit a bug... but the bugtracker is still down :(
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: problem building meta-toolchain for arm/uclibc

[Sergey 'Jin' Bostandzhyan]

Hi,

On Mon, Apr 28, 2008 at 02:54:34PM -0700, Khem Raj wrote:
> try running the link step alone manually

[...]

did that, -v did not tell anything that seemed useful but then I noticed
one thing:

> libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./bpabi_s.o
> libgcc/./unaligned-funcs_s.o libgcc/./unwind-arm_s.o
> libgcc/./libunwind_s.o libgcc/./pr-support_s.o libgcc/./unwind-c_s.o
> -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f
> ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv
> ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1
> ./libgcc_s.so

actually, for this test, I should have stopped here:
...
> libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./bpabi_s.o
> libgcc/./unaligned-funcs_s.o libgcc/./unwind-arm_s.o
> libgcc/./libunwind_s.o libgcc/./pr-support_s.o libgcc/./unwind-c_s.o
> -lc

the stuff after it is just moving around and so on.

> and pass options to generate verbose output. It could be related to binutils.

And there it was staring at me: the -lc thing. When I was grepping for 
libc.so.6 in the whole work directory I found this:

binutils-2.18/build.i686-linux.arm-angstrom-linux-uclibcgnueabi/ld/earmelf_linux_eabi.c:494

  /* We issue a warning if it looks like we are including two
     different versions of the same shared library.  For example,
     there may be a problem if -lc picks up libc.so.6 but some other
     shared library has a DT_NEEDED entry of libc.so.5.  This is a
     heuristic test, and it will only work if the name looks like
     NAME.so.VERSION.  FIXME: Depending on file names is error-prone.
     If we really want to issue warnings about mixing version numbers
     of shared libraries, we need to find a better way.  */

Can this be somehow related to the issue that I am experiencing?

Btw, just for the fun of it, I tried simply removing the -lc parameter - and
then it linked without error. But then of course I am not sure if that
is correct or if by doing that I produced garbage...

Any further ideas?

Kind regards,
Jin




> 
> 
> 
> 
> On Mon, Apr 28, 2008 at 12:26 PM, Sergey 'Jin' Bostandzhyan
> <jin@mediatomb.cc> wrote:
> > Hi everyone,
> >
> > I keep struggling with meta-toolchain and I hope to get some input on this.
> >
> > I'm on oe stable, angstrom-2007.1, ARM9, uclibc, EABI
> >
> > I start with a clean build: bitbake meta-toolchain
> >
> > Unfortunately gcc-cross-sdk fails to build:
> > NOTE: package gcc-cross-sdk-4.1.2-r11: task do_compile: failed
> >
> > And here's the most interesting part:
> > | /opt/44296fe048e6bdbb2da959e5d681dfdf/etcb/OE/build/angstrom/cross/bin/arm-angstrom-linux-uclibcgnueabi-ld: cannot find libc.so.6
> > | collect2: ld returned 1 exit status
> > | make[3]: *** [libgcc_s.so] Error 1
> >
> > Is it looking for libc.so.6 on a uclibc build?
> >
> > Here is the full log:
> > http://www.deadlock.dhs.org/jin/log_do_compile_uclibcgnueabi_gcc_cross_sdk.txt
> >
> > I started to poke around, looking for differences between the configuration
> > options of the sdk and non-sdk versions.
> >
> > Apart of the directories most things are the same, the only other additonal
> > options were in the gcc-cross-sdk (vs. gcc-cross)  configuration:
> > --enable-clocale=generic and --disable-nls (the non-sdk gcc-cross did not have
> > those).
> >
> > I also looked at binutils-cross and binutils-cross-sdk, here binutils-cross
> > had two more options: --enable-install-libbfd --disable-werror The rest,
> > except for the paths was the same.
> >
> > I also noticed that the sdk variants use the already available tools from
> > the cross directory, not sure if that can be related to my problem
> > binutils-cross:
> > checking for arm-angstrom-linux-uclibcgnueabi-gcc... no
> >
> > binutils-cross-sdk:
> > checking for arm-angstrom-linux-uclibcgnueabi-gcc... arm-angstrom-linux-uclibcgnueabi-gcc
> >
> > At this point I am sort of stuck, so if anyone has an idea or a clue - I'll
> > be happy to hear about it. Thanks!
> >
> > Kind regards,
> > Jin
> >
> > P.S. I'd submit a bug... but the bugtracker is still down :(
> >
> >
> > _______________________________________________
> > 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: problem building meta-toolchain for arm/uclibc

[Stanislav Brabec]

Sergey 'Jin' Bostandzhyan wrote:

> And there it was staring at me: the -lc thing. When I was grepping for 
> libc.so.6 in the whole work directory I found this:

You could check your config.log for site script inclusion.

If you will see, that site scripts .../site/arm-* are included, it is be
the same problem I described five days ago in the mail "brokenness of
native builds by cross-compile site scripts".

It needs a fox of class/siteinfo.bbclass. Probably don't include
anything if compiling native packages.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: problem building meta-toolchain for arm/uclibc

[Sergey Jin' Bostandzhyan]

On Tue, Apr 29, 2008 at 03:01:38PM +0200, Stanislav Brabec wrote:
> > libc.so.6 in the whole work directory I found this:
> 
> You could check your config.log for site script inclusion.

Thanks for the hint, let's see...

binutils-cross-sdk loads these scripts to that looks ok:
org.openembedded.stable/site/endian-little
org.openembedded.stable/site/common-glibc
org.openembedded.stable/site/ix86-common
org.openembedded.stable/site/common
org.openembedded.stable/site/common

same for gcc-cross SDK
 
> If you will see, that site scripts .../site/arm-* are included, it is be
> the same problem I described five days ago in the mail "brokenness of
> native builds by cross-compile site scripts".
> 
> It needs a fox of class/siteinfo.bbclass. Probably don't include
> anything if compiling native packages.

Seems that I am not hitting this particular problem... must be something else.

Kind regards,
Jin