GLIBCXX_4.3.20

[StephanvanSchaik]

After unpacking rust-2015-01-29-52c74e6-arm-unknown-linux-gnueabihf-86b081147432a8db92c4f102a2f8e91de15f51be.tar.gz to /usr/local/ and invoking rustc on Gentoo, I get the following error:

rustc: /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.8.3/libstdc++.so.6: version `GLIBCCXX_3.4.20' not found (required by /usr/local/lib/librustc_llvm-4e7c5e5c.so).

I am using gcc 4.8.3 and glibc 2.19-r1. More recent versions, if required, haven't been considered stable yet (last emerge --sync was today). I'm going to try and unmask them, but it would be much nicer if I could just keep using the stable versions, as newer versions of gcc are masked with a reason (it is not uncommon for gcc to have bugs that cause faulty compilation of the Linux kernel and other software; why the ArchLinux package maintainers consider it stable goes beyond me).

Also, if you are interested, the platforms I am using at the moment are (I am a maintainer of linux-exynos.org btw.):

• Samsung Chromebook XE303C12 (snow; Samsung Exynos 5250).
• Samsung Chromebook 2 XE503C32 (peach-pi; Samsung Exynos 5800).
• Acer Chromebook CB5-311-T28J (nyan-big; Nvidia Tegra K1).

If you are interested in having your builds tested on more platforms, I also have direct access to an InForce IFC6410 (Qualcomm Snapdragon 600), a Cubieboard 2 (Allwinner A20), a Cubieboard 3 (Allwinner A20), an A10-OLinuXino-LIME (Allwinner A10) a PandaBoard ES (Texas Instruments OMAP 4460), and some other platforms that aren't that interesting (due to a lack of processing power and memory).

Addendum:

When installing gcc-4.9.2 and libssh2-1.4.3-r1 both rustc and cargo seem to work. However, when running cargo, the system seems to complain about the version of libcurl (probably being too old: curl-7.39.0).

[japaric]

Thanks for the detailed report!

Yes, Arch is too bleeding egde and the nightlies end with library requirements that are too high for several distributions.

Right now, I'm looking into building the nightlies in a Ubuntu 12.04 (ARM) chroot to lower the requirements. Since you have several boards probably running different OSes, maybe you can help me here, I'd like to confirm if the versions of glibc and libcurl in the chroot are low enough:

$ dpkg -l | grep libc
ii  libc-bin                        2.15-0ubuntu10.10                 Embedded GNU C Library: Binaries
ii  libc6                           2.15-0ubuntu10.10                 Embedded GNU C Library: Shared libraries
$ dpkg -l | grep curl
ii  curl                            7.22.0-3ubuntu4.12                Get a file from an HTTP, HTTPS or FTP server
ii  libcurl3                        7.22.0-3ubuntu4.12                Multi-protocol file transfer library (OpenSSL)

If the version of the libraries in your devices are higher than or equal to these, I think we are good to go.

If you are interested in having your builds tested on more platforms

It'd be great if you could run some smoke tests (I think building a cargo package is a good test) in your devices. Ultimately, I'd like run the full test suite (make check) in several boards, open a metabug with a list of the failed tests in the rust-lang/rust repo and the work towards fixing the bugs. (I got some raw data about this in issue #15)

I'll ping you when I get a rust/cargo nightly built in the Ubuntu chroot.

[StephanvanSchaik]

At the moment, sys-libs/glibc-2.19-r1 is the most recent version that is considered stable on Gentoo, and sys-libs/glibc-2.20-r1 is the most recent version that is in a testing phase on the armv7a-architecture on Gentoo (that means it is currently being tested for the specific architecture, but not ready for production yet.).

As for curl. The most recent stable version is net-misc/curl-7.39.0, and the most recent testing version is net-misc/curl-7.40.0.

Another dependency that has been causing issues, as mentioned before, is libstdc++.so, which, in case of Gentoo, is part of sys-devel/gcc. The most recent stable version is sys-devel/gcc-4.8.3 and the most recent testing version is sys-devel/gcc-4.9.2.

A final word on picking the greatest common denominator. I think it would be best to take the stable release of either Debian or CentOS, as these usually have the oldest packages among the most recent releases of Linux distributions. Gentoo, ArchLinux, OpenSUSE Tumbleweed, etc. shouldn't be too problematic as they are well-maintained rolling distributions.I am not sure if those support proper version selection like the Portage package manager in Gentoo, i.e. allowing you to limit the packages to versions considered stable, allowing you to use versions in the testing phase, or even allowing you to use bleeding edge (so called 9999-ebuilds that download from upstream, build and install). Do note though that the testing phase is architecture-dependent in case of Gentoo. It is thus likely that on x86 and x86-64 more recent versions may be considered stable.

[japaric]

I think it would be best to take the stable release of either Debian or CentOS

Yes, my original plan was to built the nightlies in a Raspbian (armhf Wheezy) chroot, which has a glibc-2.13 package, but I'm having trouble getting an initial rustc ARM binary that doesn't depend on glibc-2.15 (see my last comment in #18). So I'm settling on Ubuntu 12.04 (glibc-2.15) for the time being.

I haven't touch CentOS before, do you know if there's any armhf rootfs for it? And what glibc version uses? (I doubt it's older than glibc-2.13 though).

[StephanvanSchaik]

Well fortunately, it seems that they have dropped support for all architectures but x86-64, because CentOS 6.5 still uses glibc-2.12. However, CentOS 7 uses glibc-2.17, but still it doesn't matter.

[japaric]

@StephanvanSchaik

The rust-2015-02-03-3b2ed14-... nightly was created in an ubuntu 12.04 chroot and should have a glibc-2.15 requirement, could you give it a try in your ARM devices?

[japaric]

@StephanvanSchaik any update here?

I'm now building the nightlies in a Raspbian chroot. The glibc requirement should be 2.13+, and the cargo nightly is statically linked to libcurl, so it should work regardless of your installed version.

[StephanvanSchaik]

I've installed rust-2015-02-06-f3573aa-arm-unknown-linux-gnueabihf-568ee4e5ab5eea3781db4f264204a07a398005f9.tar.gz and cargo-2015-02-04-0557065-arm-unknown-linux-gnueabihf-a9ff590afc96c8c0d71adc2b008e96969816e6c6.tar.gz on my Samsung Chromebook 2 with Gentoo. Which seems to work fine with sys-devel/gcc-4.8.3, sys-libs/glibc-2.19-r1 and net-misc/curl-7.39.0.

One thing I have noticed is that the triplet you are using is a bit odd. On my installation the triplet is armv7a-hardfloat-linux-gnueabi, which is a lot more specific, but other than that it shouldn't matter much.

What I can do now is help you run the tests (I am not sure how to do that yet), and eventually patch dev-lang/rust-bin on Gentoo to use these binary packages for ARMv7a. Then I can look into what is needed to get dev-lang/rust to work on ARMv7a (which is the package used to build rustc from the source code).

[japaric]

I've installed rust-2015-02-06-f3573aa-arm-unknown-linux-gnueabihf-568ee4e5ab5eea3781db4f264204a07a398005f9.tar.gz and cargo-2015-02-04-0557065-arm-unknown-linux-gnueabihf-a9ff590afc96c8c0d71adc2b008e96969816e6c6.tar.gz on my Samsung Chromebook 2 with Gentoo. Which seems to work fine with sys-devel/gcc-4.8.3, sys-libs/glibc-2.19-r1 and net-misc/curl-7.39.0.

Excellent! :+1:

One thing I have noticed is that the triplet you are using is a bit odd. On my installation the triplet is armv7a-hardfloat-linux-gnueabi, which is a lot more specific, but other than that it shouldn't matter much.

That's the target rustc uses (it's a lowest common denominator that targets ARMv6 VFP2 and up), changing it requires messing with target specifications.

AFAIK, only gentoo uses very specific triples, other distros use arm-unknown-linux-gnueabihf or arm-linux-gnueabihf, but I don't think it's a problem.

What I can do now is help you run the tests (I am not sure how to do that yet)

I'd love that. Sadly, the tests binaries don't ship with the nightlies, so you have to bootstrap a full compiler and then run the test suite (a.k.a. make && make check). As for the steps to do that, you need to clone the rust-lang/rust repo, then ./configure, make -j$(nproc) and make check. If you want the specific commands that I use, you can look at the build-rust.sh script.

I'm planning to run the test suite for each nightly and upload the output. You can already see this in the dropbox folder, there's a cargo-*.test.output.txt. And I'm running rust test suite at thet moment.

I'll like to check if the same tests fail (yes, they fail) in multiple devices. If different tests fail in different devices, that probably will make it harder to fix the bugs and test the fixes. Anyways, it'd be great if you could send me the full output of make check (in a gist or something). Some timing information (time make -j(nproc) and time make check) would be nice as well.

eventually patch dev-lang/rust-bin on Gentoo to use these binary packages for ARMv7a

Please mention that these are unofficial nightlies, and may break every now and then, and also may contain bugs.

Then I can look into what is needed to get dev-lang/rust to work on ARMv7a (which is the package used to build rustc from the source code).

Take a look at the build-rust.sh script, the process is rather straightforward.

[japaric]

I'm going to close this, because the issue has been solved (the glibc requirements have been lowered). @StephanvanSchaik if you manage to run the tests, please leave a comment in issue #10 / #15. Thanks!

P.S. I'd also like your opinion on #23.