On 25/03/11 21:48, Diane Holt wrote:
I hope you don't mind me sending you mail, but I'm a bit stuck...I've been told I need the Linaro 4.5.2 toolchain because it has some "neon optimizations" that the CS 4.5.1 doesn't have.
In general, you'd be better addressing these questions on the Linaro Toolchain mailing list: linaro-toolchain@lists.linaro.org (I've copied it in).
Not least because I'm on vacation for the next week. :)
Unfortunately, the Linaro 4.5.2 that's available for download (already built) won't work in my Scratchbox environment, since it was compiled against a glibc that's too new. The CS 4.5.1 works fine -- but I'm not allowed to use it, because of the neon stuff.
The CS and Linaro compilers are really very similar, but CodeSourcery has not made a release since the autumn, so Linaro will have some extra features.
Do you know whether CS actually does have (or will have) the same neon optimizations Linaro has?
It depends which optimizations you are referring to? The existing CS release had the latest improvements at the time it was released, and I believe that the upcoming release will probably be very similar to Linaro (at least, with respect to ARMv7 - there'll be many differences for other architecture variants), but I'm not promising that.
Sorry if that's a bit vague, but I the contents of the next CS release is still not finalised.
If it doesn't (and won't), then I'm going to have to build the Linaro one from source. Unfortunately, I've not been able to find any detailed information on how to go about doing that. Do you know if that's documented anywhere?
Are you talking about building native compiler, or a cross-compiler? The former is very simple (provided you have all the dependencies), while the latter is more involved.
Here's the recipe to build a native compiler:
tar xf gcc-linaro.....tar.bz2 mkdir objdir cd objdir ../gcc-linaro....../configure --prefix=<your-install-path> <opts> make bootstrap make install
You can copy the configure <opts> from another compiler using 'gcc -v' and './configure --help' in the source tree should tell you what they mean.
If you want to build a cross compiler, I suggest you look at crosstool or crosstool-ng, or OpenEmbedded. Building cross-toolchains is non-trivial.
Hope that helps.
Andrew
Sorry, I should have been more specific. Yes, a cross-compiler for ARM (we're building for cortex-a8, which is why we're interested in the neon optimizations). As I mentioned, I can't use the one that's available as a debian pkg built by Linaro, because I need to use the toolchain in Scratchbox, which has a rather old libc (in its host_shared/lib), and the Linaro one was built against a very new libc. I checked with scratchbox.org, and there are no current plans to update the host_shared libc, so, if the CS 4.5.1 doesn't have those same neon optimizations, then my only other recourse is to try and build the linaro 4.5.2 myself (since I need this "yesterday" :P ). So I was hoping the build process that's being used to build the cross for ARM would be documented somewhere, so I could do the same steps, just on an earlier Ubuntu (dapper), but I wasn't able to find anything on the Linaro site.
Thanks, Diane
On Sat, Mar 26, 2011 at 3:18 AM, Andrew Stubbs ams@codesourcery.com wrote:
On 25/03/11 21:48, Diane Holt wrote:
I hope you don't mind me sending you mail, but I'm a bit stuck...I've been told I need the Linaro 4.5.2 toolchain because it has some "neon optimizations" that the CS 4.5.1 doesn't have.
In general, you'd be better addressing these questions on the Linaro Toolchain mailing list: linaro-toolchain@lists.linaro.org (I've copied it in).
Not least because I'm on vacation for the next week. :)
Unfortunately, the Linaro
4.5.2 that's available for download (already built) won't work in my Scratchbox environment, since it was compiled against a glibc that's too new. The CS 4.5.1 works fine -- but I'm not allowed to use it, because of the neon stuff.
The CS and Linaro compilers are really very similar, but CodeSourcery has not made a release since the autumn, so Linaro will have some extra features.
Do you know whether CS actually does have (or will have) the same neon
optimizations Linaro has?
It depends which optimizations you are referring to? The existing CS release had the latest improvements at the time it was released, and I believe that the upcoming release will probably be very similar to Linaro (at least, with respect to ARMv7 - there'll be many differences for other architecture variants), but I'm not promising that.
Sorry if that's a bit vague, but I the contents of the next CS release is still not finalised.
If it doesn't (and won't), then I'm going to have to build the Linaro
one from source. Unfortunately, I've not been able to find any detailed information on how to go about doing that. Do you know if that's documented anywhere?
Are you talking about building native compiler, or a cross-compiler? The former is very simple (provided you have all the dependencies), while the latter is more involved.
Here's the recipe to build a native compiler:
tar xf gcc-linaro.....tar.bz2 mkdir objdir cd objdir ../gcc-linaro....../configure --prefix=<your-install-path> <opts> make bootstrap make install
You can copy the configure <opts> from another compiler using 'gcc -v' and './configure --help' in the source tree should tell you what they mean.
If you want to build a cross compiler, I suggest you look at crosstool or crosstool-ng, or OpenEmbedded. Building cross-toolchains is non-trivial.
Hope that helps.
Andrew
Dnia 2011-03-26, sob o godzinie 16:00 -0700, Diane Holt pisze:
As I mentioned, I can't use the one that's available as a debian pkg built by Linaro, because I need to use the toolchain in Scratchbox, which has a rather old libc (in its host_shared/lib), and the Linaro one was built against a very new libc.
iirc there was scratchbox rootfs based on Lenny available and this will be newer then Dapper (which is nearly 5 years old now).
I checked with scratchbox.org, and there are no current plans to update the host_shared libc, so, if the CS 4.5.1 doesn't have those same neon optimizations, then my only other recourse is to try and build the linaro 4.5.2 myself (since I need this "yesterday" :P ). So I was hoping the build process that's being used to build the cross for ARM would be documented somewhere, so I could do the same steps, just on an earlier Ubuntu (dapper), but I wasn't able to find anything on the Linaro site.
gcc-4.5 from 'natty' may be buildable even under dapper but you will have to backport some other packages too to make it work. As we do not support anything older then 10.04 'lucid' there will be no work done to make such backport.
On Sun, Mar 27, 2011 at 12:00 PM, Diane Holt holt.diane@gmail.com wrote:
Sorry, I should have been more specific. Yes, a cross-compiler for ARM (we're building for cortex-a8, which is why we're interested in the neon optimizations). As I mentioned, I can't use the one that's available as a debian pkg built by Linaro, because I need to use the toolchain in Scratchbox, which has a rather old libc (in its host_shared/lib), and the Linaro one was built against a very new libc. I checked with scratchbox.org, and there are no current plans to update the host_shared libc, so, if the CS 4.5.1 doesn't have those same neon optimizations, then my only other recourse is to try and build the linaro 4.5.2 myself (since I need this "yesterday" :P ). So I was hoping the build process that's being used to build the cross for ARM would be documented somewhere, so I could do the same steps, just on an earlier Ubuntu (dapper), but I wasn't able to find anything on the Linaro site.
Hi Diane. The toolchain working group has assignees from CodeSourcery, IBM, ARM, and Canonical. We often get access to improvements that CodeSourcery have done internally, and help get those upstream and get them tested by using them in real products such as Ubuntu. CodeSourcery are free to pick up optimisations that Linaro do up in the FSF trunk, such as the NEON improvements that Richard and Ira are working on. The short story is that there's good cross-pollination there.
Regarding building a new cross-compiler, have a look at my cross-build scripts: https://code.launchpad.net/~michaelh1/+junk/cross-build
and especially the cross-gcc directory. This does a single stage cross compiler build against a prebuilt binary sysroot like you have at the moment. Set PREFIX to where you want the compiler to install to and modify SYSROOT and the $(stamp)sysroot-extract rule to point the build at your scratchbox header files and includes.
It'll need a little bit of work. If it turns out, could you send some instructions to the list?
-- Michael
Thanks, Michael, that's the sort of thing I was hoping for. And it almost worked :)
The Dapper desktop VMWare appliance I got from Ubuntu didn't have these needed packages: bison, curl, flex, and texinfo. So I needed to install them.
Without curl, the downloads won't happen.
Without texinfo, makeinfo isn't found, which comes out looking like a warning, but it does fail the build.
Without bison and flex, you get a funky build failure for binutils -- it tries to link both sysinfo.o and syslex.o into sysinfo (which results in two main()'s being defined).
I needed to get and build tar-1.22, since your tar command uses -a, which the tar that comes with Dapper doesn't have. (Not sure when it was introduced, so I just went with the version that was on my lucid, since that one has it.)
There is no binutils_2.21.0.201103*0*2.orig.tar.gz -- it's binutils_2.21.0.201103*2*2.orig.tar.gz
Needed to get and build gmp, mpfr, and mpc, and add --with-gmp, --with-mpfr, and --with-mpc to GCCFLAGS.
The build got pretty far, but eventually failed with:
make[4]: Entering directory `/home/ubuntu/work/build/gcc/libiberty/testsuite' make[4]: Nothing to be done for `install'. make[4]: Leaving directory `/home/ubuntu/work/build/gcc/libiberty/testsuite' make[3]: Leaving directory `/home/ubuntu/work/build/gcc/libiberty' /bin/sh: line 3: cd: arm-linux-gnueabi/libstdc++-v3: No such file or directory make[2]: *** [install-target-libstdc++-v3] Error 1 make[2]: Leaving directory `/home/ubuntu/work/build/gcc' make[1]: *** [install] Error 2 make[1]: Leaving directory `/home/ubuntu/work/build/gcc' make: *** [stamp/gcc-install] Error 2
Any idea what I need to do about that? (I tried adding --enable-languages=c,c++ but that didn't help.)
Thanks, Diane
On Sun, Mar 27, 2011 at 12:31 PM, Michael Hope michael.hope@linaro.orgwrote:
On Sun, Mar 27, 2011 at 12:00 PM, Diane Holt holt.diane@gmail.com wrote:
Sorry, I should have been more specific. Yes, a cross-compiler for ARM (we're building for cortex-a8, which is why we're interested in the neon optimizations). As I mentioned, I can't use the one that's available as a debian pkg built by Linaro, because I need to use the toolchain in Scratchbox, which has a rather old libc (in its host_shared/lib), and the Linaro one was built against a very new libc. I checked with
scratchbox.org,
and there are no current plans to update the host_shared libc, so, if the
CS
4.5.1 doesn't have those same neon optimizations, then my only other recourse is to try and build the linaro 4.5.2 myself (since I need this "yesterday" :P ). So I was hoping the build process that's being used to build the cross for ARM would be documented somewhere, so I could do the same steps, just on an earlier Ubuntu (dapper), but I wasn't able to find anything on the Linaro site.
Hi Diane. The toolchain working group has assignees from CodeSourcery, IBM, ARM, and Canonical. We often get access to improvements that CodeSourcery have done internally, and help get those upstream and get them tested by using them in real products such as Ubuntu. CodeSourcery are free to pick up optimisations that Linaro do up in the FSF trunk, such as the NEON improvements that Richard and Ira are working on. The short story is that there's good cross-pollination there.
Regarding building a new cross-compiler, have a look at my cross-build scripts: https://code.launchpad.net/~michaelh1/+junk/cross-buildhttps://code.launchpad.net/%7Emichaelh1/+junk/cross-build
and especially the cross-gcc directory. This does a single stage cross compiler build against a prebuilt binary sysroot like you have at the moment. Set PREFIX to where you want the compiler to install to and modify SYSROOT and the $(stamp)sysroot-extract rule to point the build at your scratchbox header files and includes.
It'll need a little bit of work. If it turns out, could you send some instructions to the list?
-- Michael
On Mon, Mar 28, 2011, Diane Holt wrote:
The Dapper desktop VMWare appliance I got from Ubuntu [...]
Thanks a lot for sharing your notes!
If it's a requirement that you use Ubuntu 6.06, I'd be curious to hear why! It should mostly work, but I'm curious because we mostly target the latest LTS release of Ubuntu as a possible base rather than all LTSes; for instance, we try to provide backports to Ubuntu 10.04 but not to Ubuntu 8.04 or Ubuntu 6.06.
Thanks!
I'm using Dapper because that's got an old enough libc to build the Linaro toolchain against so that it will work as a toolchain in Scratchbox. The one that was built by you guys won't work, because the /scratchbox/host_shared/lib/libc.so is too old (and there are no current plans to update it).
I'm happy to say that a quick test on the one I'm building on Dapper looks like it will work -- but I need to get past that build failure on install-target-libstdc++-v3. Do you have any suggestions?
Thanks, Diane
On Tue, Mar 29, 2011 at 2:47 AM, Loïc Minier loic.minier@linaro.org wrote:
On Mon, Mar 28, 2011, Diane Holt wrote:
The Dapper desktop VMWare appliance I got from Ubuntu [...]
Thanks a lot for sharing your notes!
If it's a requirement that you use Ubuntu 6.06, I'd be curious to hear why! It should mostly work, but I'm curious because we mostly target the latest LTS release of Ubuntu as a possible base rather than all LTSes; for instance, we try to provide backports to Ubuntu 10.04 but not to Ubuntu 8.04 or Ubuntu 6.06.
Thanks!
Loďc Minier
On Tue, Mar 29, 2011 at 4:31 PM, Diane Holt holt.diane@gmail.com wrote:
Thanks, Michael, that's the sort of thing I was hoping for. And it almost worked :)
A great thing about Debian/Ubuntu is 'apt-get build-dep'. On recent systems at least you can run 'apt-get build-dep gcc-snapshot' and have all of the build dependencies downloaded and instaled.
The Dapper desktop VMWare appliance I got from Ubuntu didn't have these needed packages: bison, curl, flex, and texinfo. So I needed to install them.
Without curl, the downloads won't happen.
Without texinfo, makeinfo isn't found, which comes out looking like a warning, but it does fail the build.
Without bison and flex, you get a funky build failure for binutils -- it tries to link both sysinfo.o and syslex.o into sysinfo (which results in two main()'s being defined).
I needed to get and build tar-1.22, since your tar command uses -a, which the tar that comes with Dapper doesn't have. (Not sure when it was introduced, so I just went with the version that was on my lucid, since that one has it.)
There is no binutils_2.21.0.20110302.orig.tar.gz -- it's binutils_2.21.0.20110322.orig.tar.gz
There used to be on 02, but Natty marches on very quickly. I've changed the local version of my script to use binutils 2.21 from the FSF.
Needed to get and build gmp, mpfr, and mpc, and add --with-gmp, --with-mpfr, and --with-mpc to GCCFLAGS.
The build got pretty far, but eventually failed with:
make[4]: Entering directory `/home/ubuntu/work/build/gcc/libiberty/testsuite' make[4]: Nothing to be done for `install'. make[4]: Leaving directory `/home/ubuntu/work/build/gcc/libiberty/testsuite' make[3]: Leaving directory `/home/ubuntu/work/build/gcc/libiberty' /bin/sh: line 3: cd: arm-linux-gnueabi/libstdc++-v3: No such file or directory make[2]: *** [install-target-libstdc++-v3] Error 1 make[2]: Leaving directory `/home/ubuntu/work/build/gcc' make[1]: *** [install] Error 2 make[1]: Leaving directory `/home/ubuntu/work/build/gcc' make: *** [stamp/gcc-install] Error 2
Any idea what I need to do about that? (I tried adding --enable-languages=c,c++ but that didn't help.)
Not sure there. Could you capture the output from configure and send it through?
-- Michael
On Tue, Mar 29, 2011 at 6:18 PM, Michael Hope michael.hope@linaro.orgwrote:
The build got pretty far, but eventually failed with:
make[4]: Entering directory `/home/ubuntu/work/build/gcc/libiberty/testsuite' make[4]: Nothing to be done for `install'. make[4]: Leaving directory
`/home/ubuntu/work/build/gcc/libiberty/testsuite'
make[3]: Leaving directory `/home/ubuntu/work/build/gcc/libiberty' /bin/sh: line 3: cd: arm-linux-gnueabi/libstdc++-v3: No such file or directory make[2]: *** [install-target-libstdc++-v3] Error 1 make[2]: Leaving directory `/home/ubuntu/work/build/gcc' make[1]: *** [install] Error 2 make[1]: Leaving directory `/home/ubuntu/work/build/gcc' make: *** [stamp/gcc-install] Error 2
Any idea what I need to do about that? (I tried adding --enable-languages=c,c++ but that didn't help.)
Not sure there. Could you capture the output from configure and send it through?
Actually all the install-target-* targets fail (of the three it tries to do), and in the same way -- ie., on that relative-path cd. If I comment out the actions for install-target-libstdc++-v3, install-target-libgcc, and install-target-libiberty, then the build finishes, creating the tar file.
This is what the target for libstdc++-v3 looks like (they're all pretty much the same, just with a different subdir in the cd and a different exports var):
install-target-libstdc++-v3: installdirs @: $(MAKE); $(unstage) @r=`${PWD_COMMAND}`; export r; \ s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \ $(RAW_CXX_TARGET_EXPORTS) \ (cd $(TARGET_SUBDIR)/libstdc++-v3 && \ $(MAKE) $(TARGET_FLAGS_TO_PASS) install)
I'm not sure where that cd is supposed to be relative to, but nowhere do I have a libstdc++* or libgcc* shared lib (or static), so it looks to me like they're not getting built -- nothing fails, so I assume they're not even trying to be built. I don't know why, though. So even though I got through to the tarfile creation, it isn't actually complete -- but I suppose as a workaround for now, I could try snagging those libs from release you guys built and see if that works.
Diane
Hi Diane. Please send through your configure arguments and a log of the output of configure. I suspect that these libraries are somehow half disabled leading to a later build error.
-- Michael
On Wed, Mar 30, 2011 at 3:20 PM, Diane Holt holt.diane@gmail.com wrote:
On Tue, Mar 29, 2011 at 6:18 PM, Michael Hope michael.hope@linaro.org wrote:
The build got pretty far, but eventually failed with:
make[4]: Entering directory `/home/ubuntu/work/build/gcc/libiberty/testsuite' make[4]: Nothing to be done for `install'. make[4]: Leaving directory `/home/ubuntu/work/build/gcc/libiberty/testsuite' make[3]: Leaving directory `/home/ubuntu/work/build/gcc/libiberty' /bin/sh: line 3: cd: arm-linux-gnueabi/libstdc++-v3: No such file or directory make[2]: *** [install-target-libstdc++-v3] Error 1 make[2]: Leaving directory `/home/ubuntu/work/build/gcc' make[1]: *** [install] Error 2 make[1]: Leaving directory `/home/ubuntu/work/build/gcc' make: *** [stamp/gcc-install] Error 2
Any idea what I need to do about that? (I tried adding --enable-languages=c,c++ but that didn't help.)
Not sure there. Could you capture the output from configure and send it through?
Actually all the install-target-* targets fail (of the three it tries to do), and in the same way -- ie., on that relative-path cd. If I comment out the actions for install-target-libstdc++-v3, install-target-libgcc, and install-target-libiberty, then the build finishes, creating the tar file.
This is what the target for libstdc++-v3 looks like (they're all pretty much the same, just with a different subdir in the cd and a different exports var):
install-target-libstdc++-v3: installdirs @: $(MAKE); $(unstage) @r=`${PWD_COMMAND}`; export r; \ s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \ $(RAW_CXX_TARGET_EXPORTS) \ (cd $(TARGET_SUBDIR)/libstdc++-v3 && \ $(MAKE) $(TARGET_FLAGS_TO_PASS) install)
I'm not sure where that cd is supposed to be relative to, but nowhere do I have a libstdc++* or libgcc* shared lib (or static), so it looks to me like they're not getting built -- nothing fails, so I assume they're not even trying to be built. I don't know why, though. So even though I got through to the tarfile creation, it isn't actually complete -- but I suppose as a workaround for now, I could try snagging those libs from release you guys built and see if that works.
Diane
Hi Michael,
Thanks for hanging in there with me :)
I know now why those three libs didn't build -- their configure-target-* target failed, because when it tried to compile a little test program, the loader couldn't find libmpc. I did include the --with-mpc flag in the GCCFLAGS in your Makefile, but apparently that doesn't carry down through to here -- so I just moved it (and gmp and mpfr) all to /usr/lib, and now the configure-target-libstdc++-v3 no longer gets that error. Unfortunately, it failed to find arm-linux-gnueabi-ar when it was trying to archive libgcc.a. It does exist (in build/sysroot/.../cross-gcc-linaro/bin, but I'll have to dig around a bit more to see how to get it to find it there (or maybe I'll just throw them all into /usr/bin :)
Anyway, I think I'm getting close...
Diane
On Wed, Mar 30, 2011 at 5:36 PM, Michael Hope michael.hope@linaro.orgwrote:
Hi Diane. Please send through your configure arguments and a log of the output of configure. I suspect that these libraries are somehow half disabled leading to a later build error.
-- Michael
On Wed, Mar 30, 2011 at 3:20 PM, Diane Holt holt.diane@gmail.com wrote:
On Tue, Mar 29, 2011 at 6:18 PM, Michael Hope michael.hope@linaro.org wrote:
The build got pretty far, but eventually failed with:
make[4]: Entering directory `/home/ubuntu/work/build/gcc/libiberty/testsuite' make[4]: Nothing to be done for `install'. make[4]: Leaving directory `/home/ubuntu/work/build/gcc/libiberty/testsuite' make[3]: Leaving directory `/home/ubuntu/work/build/gcc/libiberty' /bin/sh: line 3: cd: arm-linux-gnueabi/libstdc++-v3: No such file or directory make[2]: *** [install-target-libstdc++-v3] Error 1 make[2]: Leaving directory `/home/ubuntu/work/build/gcc' make[1]: *** [install] Error 2 make[1]: Leaving directory `/home/ubuntu/work/build/gcc' make: *** [stamp/gcc-install] Error 2
Any idea what I need to do about that? (I tried adding --enable-languages=c,c++ but that didn't help.)
Not sure there. Could you capture the output from configure and send it through?
Actually all the install-target-* targets fail (of the three it tries to do), and in the same way -- ie., on that relative-path cd. If I comment
out
the actions for install-target-libstdc++-v3, install-target-libgcc, and install-target-libiberty, then the build finishes, creating the tar file.
This is what the target for libstdc++-v3 looks like (they're all pretty
much
the same, just with a different subdir in the cd and a different exports var):
install-target-libstdc++-v3: installdirs @: $(MAKE); $(unstage) @r=`${PWD_COMMAND}`; export r; \ s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \ $(RAW_CXX_TARGET_EXPORTS) \ (cd $(TARGET_SUBDIR)/libstdc++-v3 && \ $(MAKE) $(TARGET_FLAGS_TO_PASS) install)
I'm not sure where that cd is supposed to be relative to, but nowhere do
I
have a libstdc++* or libgcc* shared lib (or static), so it looks to me
like
they're not getting built -- nothing fails, so I assume they're not even trying to be built. I don't know why, though. So even though I got
through
to the tarfile creation, it isn't actually complete -- but I suppose as a workaround for now, I could try snagging those libs from release you guys built and see if that works.
Diane
The good news is, my build completed successfully, once I put those extra libs in /usr/lib and updated my PATH to include the bin in the work area.
The bad news is, there are a number of utililties that this build doesn't produce, that my CodeSourcery 4.4.1 has:
arm-none-linux-gnueabi/libc/sbin: ldconfig sln
arm-none-linux-gnueabi/libc/usr/bin: catchsegv gencat getent ldd localedef pcprofiledump sprof xtrace gdbserver getconf iconv locale mtrace rpcgen tzselect
arm-none-linux-gnueabi/libc/usr/lib/bin: POSIX_V6_ILP32_OFF32 catchsegv iconvconfig nscd tzselect POSIX_V6_ILP32_OFFBIG gdbserver ldconfig pcprofiledump xtrace POSIX_V7_ILP32_OFF32 gencat ldd rpcgen zdump POSIX_V7_ILP32_OFFBIG getconf locale rpcinfo zic XBS5_ILP32_OFF32 getent localedef sln XBS5_ILP32_OFFBIG iconv mtrace sprof
arm-none-linux-gnueabi/libc/usr/libexec/getconf: POSIX_V6_ILP32_OFF32 POSIX_V7_ILP32_OFF32 XBS5_ILP32_OFF32 POSIX_V6_ILP32_OFFBIG POSIX_V7_ILP32_OFFBIG XBS5_ILP32_OFFBIG
arm-none-linux-gnueabi/libc/usr/sbin: iconvconfig nscd rpcinfo zdump zic
Do you know what sources these are built from?
I also don't have the i18n/{charmaps/locales} files. At a minimum, I definitely need that (and localedef) -- getconf would also be nice to have.
Thanks, Diane
On Wed, Mar 30, 2011 at 6:33 PM, Diane Holt holt.diane@gmail.com wrote:
Hi Michael,
Thanks for hanging in there with me :)
I know now why those three libs didn't build -- their configure-target-*
target failed, because when it tried to compile a little test program, the loader couldn't find libmpc. I did include the --with-mpc flag in the GCCFLAGS in your Makefile, but apparently that doesn't carry down through to here -- so I just moved it (and gmp and mpfr) all to /usr/lib, and now the configure-target-libstdc++-v3 no longer gets that error. Unfortunately, it failed to find arm-linux-gnueabi-ar when it was trying to archive libgcc.a. It does exist (in build/sysroot/.../cross-gcc-linaro/bin, but I'll have to dig around a bit more to see how to get it to find it there (or maybe I'll just throw them all into /usr/bin :)
Anyway, I think I'm getting close...
Diane
On Sat, Apr 2, 2011 at 1:07 PM, Diane Holt holt.diane@gmail.com wrote:
The good news is, my build completed successfully, once I put those extra libs in /usr/lib and updated my PATH to include the bin in the work area.
The bad news is, there are a number of utililties that this build doesn't produce, that my CodeSourcery 4.4.1 has:
arm-none-linux-gnueabi/libc/sbin: ldconfig sln
arm-none-linux-gnueabi/libc/usr/bin: catchsegv gencat getent ldd localedef pcprofiledump sprof xtrace gdbserver getconf iconv locale mtrace rpcgen tzselect
arm-none-linux-gnueabi/libc/usr/lib/bin: POSIX_V6_ILP32_OFF32 catchsegv iconvconfig nscd tzselect POSIX_V6_ILP32_OFFBIG gdbserver ldconfig pcprofiledump xtrace POSIX_V7_ILP32_OFF32 gencat ldd rpcgen zdump POSIX_V7_ILP32_OFFBIG getconf locale rpcinfo zic XBS5_ILP32_OFF32 getent localedef sln XBS5_ILP32_OFFBIG iconv mtrace sprof
arm-none-linux-gnueabi/libc/usr/libexec/getconf: POSIX_V6_ILP32_OFF32 POSIX_V7_ILP32_OFF32 XBS5_ILP32_OFF32 POSIX_V6_ILP32_OFFBIG POSIX_V7_ILP32_OFFBIG XBS5_ILP32_OFFBIG
arm-none-linux-gnueabi/libc/usr/sbin: iconvconfig nscd rpcinfo zdump zic
Do you know what sources these are built from?
Hi Diane. The files listed above come from GLIBC and should already be in your Scratchbox root. They are not part of the compiler itself.
I also don't have the i18n/{charmaps/locales} files. At a minimum, I definitely need that (and localedef) -- getconf would also be nice to have.
These should also be provided by your Scratchbox setup.
-- Michael
Nope -- all those files came with the CodeSourcery 4.4.1 (arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2) -- I just don't know what CS built them from. (I suppose if I can't find out how to build them myself I could try just snagging them from my 4.4.1 toolchain and seeing if they work in this 4.5.2 linaro one...)
Thanks, Diane
On Sun, Apr 3, 2011 at 6:55 PM, Michael Hope michael.hope@linaro.orgwrote:
On Sat, Apr 2, 2011 at 1:07 PM, Diane Holt holt.diane@gmail.com wrote:
The good news is, my build completed successfully, once I put those extra libs in /usr/lib and updated my PATH to include the bin in the work area.
The bad news is, there are a number of utililties that this build doesn't produce, that my CodeSourcery 4.4.1 has:
arm-none-linux-gnueabi/libc/sbin: ldconfig sln
arm-none-linux-gnueabi/libc/usr/bin: catchsegv gencat getent ldd localedef pcprofiledump sprof xtrace gdbserver getconf iconv locale mtrace rpcgen tzselect
arm-none-linux-gnueabi/libc/usr/lib/bin: POSIX_V6_ILP32_OFF32 catchsegv iconvconfig nscd tzselect POSIX_V6_ILP32_OFFBIG gdbserver ldconfig pcprofiledump xtrace POSIX_V7_ILP32_OFF32 gencat ldd rpcgen zdump POSIX_V7_ILP32_OFFBIG getconf locale rpcinfo zic XBS5_ILP32_OFF32 getent localedef sln XBS5_ILP32_OFFBIG iconv mtrace sprof
arm-none-linux-gnueabi/libc/usr/libexec/getconf: POSIX_V6_ILP32_OFF32 POSIX_V7_ILP32_OFF32 XBS5_ILP32_OFF32 POSIX_V6_ILP32_OFFBIG POSIX_V7_ILP32_OFFBIG XBS5_ILP32_OFFBIG
arm-none-linux-gnueabi/libc/usr/sbin: iconvconfig nscd rpcinfo zdump zic
Do you know what sources these are built from?
Hi Diane. The files listed above come from GLIBC and should already be in your Scratchbox root. They are not part of the compiler itself.
I also don't have the i18n/{charmaps/locales} files. At a minimum, I definitely need that (and localedef) -- getconf would also be nice to
have.
These should also be provided by your Scratchbox setup.
-- Michael
OK. Note that these do come from GLIBC, so building GLIBC for your target using your new cross compiler should basically give you what you want. I wouldn't be surprised if there's a Scratchbox package that already provides these though.
-- Michael
On Tue, Apr 5, 2011 at 2:07 PM, Diane Holt holt.diane@gmail.com wrote:
Nope -- all those files came with the CodeSourcery 4.4.1 (arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2) -- I just don't know what CS built them from. (I suppose if I can't find out how to build them myself I could try just snagging them from my 4.4.1 toolchain and seeing if they work in this 4.5.2 linaro one...)
Thanks, Diane
On Sun, Apr 3, 2011 at 6:55 PM, Michael Hope michael.hope@linaro.org wrote:
On Sat, Apr 2, 2011 at 1:07 PM, Diane Holt holt.diane@gmail.com wrote:
The good news is, my build completed successfully, once I put those extra libs in /usr/lib and updated my PATH to include the bin in the work area.
The bad news is, there are a number of utililties that this build doesn't produce, that my CodeSourcery 4.4.1 has:
arm-none-linux-gnueabi/libc/sbin: ldconfig sln
arm-none-linux-gnueabi/libc/usr/bin: catchsegv gencat getent ldd localedef pcprofiledump sprof xtrace gdbserver getconf iconv locale mtrace rpcgen tzselect
arm-none-linux-gnueabi/libc/usr/lib/bin: POSIX_V6_ILP32_OFF32 catchsegv iconvconfig nscd tzselect POSIX_V6_ILP32_OFFBIG gdbserver ldconfig pcprofiledump xtrace POSIX_V7_ILP32_OFF32 gencat ldd rpcgen zdump POSIX_V7_ILP32_OFFBIG getconf locale rpcinfo zic XBS5_ILP32_OFF32 getent localedef sln XBS5_ILP32_OFFBIG iconv mtrace sprof
arm-none-linux-gnueabi/libc/usr/libexec/getconf: POSIX_V6_ILP32_OFF32 POSIX_V7_ILP32_OFF32 XBS5_ILP32_OFF32 POSIX_V6_ILP32_OFFBIG POSIX_V7_ILP32_OFFBIG XBS5_ILP32_OFFBIG
arm-none-linux-gnueabi/libc/usr/sbin: iconvconfig nscd rpcinfo zdump zic
Do you know what sources these are built from?
Hi Diane. The files listed above come from GLIBC and should already be in your Scratchbox root. They are not part of the compiler itself.
I also don't have the i18n/{charmaps/locales} files. At a minimum, I definitely need that (and localedef) -- getconf would also be nice to have.
These should also be provided by your Scratchbox setup.
-- Michael
On 05/04/11 03:07, Diane Holt wrote:
Nope -- all those files came with the CodeSourcery 4.4.1 (arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2) -- I just don't know what CS built them from. (I suppose if I can't find out how to build them myself I could try just snagging them from my 4.4.1 toolchain and seeing if they work in this 4.5.2 linaro one...)
Michael already replied to this, but just to be clear ...
The CS Linux toolchains consist of GNU Binutils (as, ld, nm, objdump, etc.), GCC, GLIBC (and/or uClibc), GDB, and a few other useful utilities, all bundled up into one install.
Most of the utilities you mentioned do indeed come from Glibc, not GCC, and should be included with your Glibc provider - in this case Scratchbox. A few of them may come from other places; 'gdbserver' comes from GDB, for example.
Andrew
linaro-toolchain@lists.linaro.org
-
Andrew Stubbs -
Diane Holt -
Loïc Minier -
Marcin Juszkiewicz -
Michael Hope