* problem building meta-toolchain for arm/uclibc @ 2008-04-28 19:26 Sergey 'Jin' Bostandzhyan 2008-04-28 21:54 ` Khem Raj 0 siblings, 1 reply; 5+ messages in thread From: Sergey 'Jin' Bostandzhyan @ 2008-04-28 19:26 UTC (permalink / raw) To: openembedded-devel 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 :( ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: problem building meta-toolchain for arm/uclibc 2008-04-28 19:26 problem building meta-toolchain for arm/uclibc Sergey 'Jin' Bostandzhyan @ 2008-04-28 21:54 ` Khem Raj 2008-04-29 12:33 ` Sergey 'Jin' Bostandzhyan 0 siblings, 1 reply; 5+ messages in thread From: Khem Raj @ 2008-04-28 21:54 UTC (permalink / raw) To: openembedded-devel 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: problem building meta-toolchain for arm/uclibc 2008-04-28 21:54 ` Khem Raj @ 2008-04-29 12:33 ` Sergey 'Jin' Bostandzhyan 2008-04-29 13:01 ` Stanislav Brabec 0 siblings, 1 reply; 5+ messages in thread From: Sergey 'Jin' Bostandzhyan @ 2008-04-29 12:33 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: problem building meta-toolchain for arm/uclibc 2008-04-29 12:33 ` Sergey 'Jin' Bostandzhyan @ 2008-04-29 13:01 ` Stanislav Brabec 2008-04-29 13:08 ` Sergey Jin' Bostandzhyan 0 siblings, 1 reply; 5+ messages in thread From: Stanislav Brabec @ 2008-04-29 13:01 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: problem building meta-toolchain for arm/uclibc 2008-04-29 13:01 ` Stanislav Brabec @ 2008-04-29 13:08 ` Sergey Jin' Bostandzhyan 0 siblings, 0 replies; 5+ messages in thread From: Sergey Jin' Bostandzhyan @ 2008-04-29 13:08 UTC (permalink / raw) To: Stanislav Brabec; +Cc: openembedded-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-04-29 13:08 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-04-28 19:26 problem building meta-toolchain for arm/uclibc Sergey 'Jin' Bostandzhyan 2008-04-28 21:54 ` Khem Raj 2008-04-29 12:33 ` Sergey 'Jin' Bostandzhyan 2008-04-29 13:01 ` Stanislav Brabec 2008-04-29 13:08 ` Sergey Jin' Bostandzhyan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.