Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tested uclibc target #35242

Closed
wants to merge 5 commits into from
Closed

Add tested uclibc target #35242

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
d133519
Add tested uclibc target
KennethAdamMiller Aug 3, 2016
64a1a13
correct license for travis build
KennethAdamMiller Aug 3, 2016
3b001ee
Add requested changes, will test in new docker instance
KennethAdamMiller Aug 3, 2016
577a30b
Revert uclibc target env, need to add to libc
KennethAdamMiller Aug 3, 2016
67e7e44
Rebasing changes onto upstream rust/master failed.
KennethAdamMiller Aug 3, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions mk/cfg/x86_64-unknown-linux-uclibc.mk
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# x86_64-unknown-linux-uclibc configuration
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we exclusively use rustbuild (which is how I've tested this before), then this file is not needed at all.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, is your decision to preference using rustbuild only? Because I need support for using rust with buildroot, and I think the way the buildroot feature/rust-v5 branch has it is bootstrapping from the bottom up.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, is your decision to preference using rustbuild only?

The Makefiles are going to be deprecated at some point (hopefully soon! I'm tired of having to test my PRs on and adapt them to work with two build systems -- it's time consuming), and supporting one build system means less testing on our part.

Because I need support for using rust with buildroot

But if you need it then I'm not going to oppose. By the way, could you point me to this "rust with buildroot" project/repository? It seems that they are building on top of the old Makefile-based build system, but they should move to rustbuild at some point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, could you point me to this "rust with buildroot" project/repository?

I believe it is https://github.com/elebihan/buildroot/tree/feature/rust-v5.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sanxiyn Thank you. I would have provided it, but I have been having some debilitating internet problems.

I'm working on a fork of that with changes to update the rust buildroot feature branch to be more flexible in allowing uclibc toolchains as well as some documentation on how to configure a rust toolchain for buildroot. It doesn't exactly have a checkbox you know.

@japaric So, I would be delighted to reduce the dependency on make as much as possible, and I totally understand you frustrations around time consumption. I've been writing some buildroot packages for a while, so I wouldn't have a problem altering their setup to build using the cargo build system. There's no way they'll give up using Makefiles; buildroot builds gigabytes worth of software for embedded environments, and there's too much momentum there. But I can't see them objecting to a buildroot package that calls cargo; we'd just be wrapping the rust build script with make, which sounds perfectly fine to me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

altering their setup to build using the cargo build system.
we'd just be wrapping the rust build script with make

Yes, this is what I meant.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do I run the exact tests you're referring to?

On Aug 4, 2016 3:52 PM, "Jorge Aparicio" [email protected] wrote:

In mk/cfg/x86_64-unknown-linux-uclibc.mk
#35242 (comment):

@@ -0,0 +1,29 @@
+# x86_64-unknown-linux-uclibc configuration

altering their setup to build using the cargo build system.
we'd just be wrapping the rust build script with make

Yes, this is what I meant.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rust/pull/35242/files/64a1a13405b41722033f3dee0554e6148c7450c5#r73590740,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACUb3n9TXXxJrYnZ2inyDDYpV2KszmOLks5qckLigaJpZM4JbzyU
.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I should go inside liblibc, and use the run.sh but I'm sure it may
be different. I think it's in the Travis files.

On Aug 4, 2016 3:52 PM, "Jorge Aparicio" [email protected] wrote:

In mk/cfg/x86_64-unknown-linux-uclibc.mk
#35242 (comment):

@@ -0,0 +1,29 @@
+# x86_64-unknown-linux-uclibc configuration

altering their setup to build using the cargo build system.
we'd just be wrapping the rust build script with make

Yes, this is what I meant.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rust/pull/35242/files/64a1a13405b41722033f3dee0554e6148c7450c5#r73590740,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACUb3n9TXXxJrYnZ2inyDDYpV2KszmOLks5qckLigaJpZM4JbzyU
.

CC_x86_64-unknown-linux-uclibc=$(CFG_UCLIBC_ROOT)/bin/uclibc-gcc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think CFG_UCLIBC_ROOT is not defined anywhere?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way that I can error the build out if the variable CC_x86_64-unknown-linux-uclibc is not set in this file?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably. FWIW, the convention is to set these variables to x86_64-linux-uclibc-gcc (no unknown component) and the user is supposed to make x86_64-linux-uclibc-gcc somehow (usually by symlinks somewhere in PATH).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll fix it.

CXX_x86_64-unknown-linux-uclibc=notaprogram
CPP_x86_64-unknown-linux-uclibc=$(CFG_UCLIBC_ROOT)/bin/uclibc-gcc -E
AR_x86_64-unknown-linux-uclibc=$(AR)
CFG_INSTALL_ONLY_RLIB_x86_64-unknown-linux-uclibc = 1
CFG_LIB_NAME_x86_64-unknown-linux-uclibc=lib$(1).so
CFG_STATIC_LIB_NAME_x86_64-unknown-linux-uclibc=lib$(1).a
CFG_LIB_GLOB_x86_64-unknown-linux-uclibc=lib$(1)-*.so
CFG_JEMALLOC_CFLAGS_x86_64-unknown-linux-uclibc := -m64
CFG_GCCISH_CFLAGS_x86_64-unknown-linux-uclibc := -Wall -Werror -g -fPIC -m64
CFG_GCCISH_CXXFLAGS_x86_64-unknown-linux-uclibc :=
CFG_GCCISH_LINK_FLAGS_x86_64-unknown-linux-uclibc :=
CFG_GCCISH_DEF_FLAG_x86_64-unknown-linux-uclibc :=
CFG_LLC_FLAGS_x86_64-unknown-linux-uclibc :=
CFG_INSTALL_NAME_x86_64-unknown-linux-uclibc =
CFG_EXE_SUFFIX_x86_64-unknown-linux-uclibc =
CFG_WINDOWSY_x86_64-unknown-linux-uclibc :=
CFG_UNIXY_x86_64-unknown-linux-uclibc := 1
CFG_LDPATH_x86_64-unknown-linux-uclibc :=
CFG_RUN_x86_64-unknown-linux-uclibc=$(2)
CFG_RUN_TARG_x86_64-unknown-linux-uclibc=$(call CFG_RUN_x86_64-unknown-linux-uclibc,,$(2))
CFG_GNU_TRIPLE_x86_64-unknown-linux-uclibc := x86_64-unknown-linux-uclibc
#CFG_THIRD_PARTY_OBJECTS_x86_64-unknown-linux-uclibc := crt1.o crti.o crtn.o
CFG_INSTALLED_OBJECTS_x86_64-unknown-linux-uclibc := crt1.o crti.o crtn.o

#NATIVE_DEPS_libc_T_x86_64-unknown-linux-uclibc += libc.a
NATIVE_DEPS_std_T_x86_64-unknown-linux-uclibc += crt1.o crti.o crtn.o
#NATIVE_DEPS_unwind_T_x86_64-unknown-linux-uclibc += libunwind.a
1 change: 1 addition & 0 deletions src/librustc_back/target/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -143,6 +143,7 @@ supported_targets! {
("i686-unknown-linux-musl", i686_unknown_linux_musl),
("mips-unknown-linux-musl", mips_unknown_linux_musl),
("mipsel-unknown-linux-musl", mipsel_unknown_linux_musl),
("x86_64-unknown-linux-uclibc", x86_64_unknown_linux_uclibc),

("i686-linux-android", i686_linux_android),
("arm-linux-androideabi", arm_linux_androideabi),
Expand Down
29 changes: 29 additions & 0 deletions src/librustc_back/target/x86_64_unknown_linux_uclibc.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
// Copyright 2014 The Rust Project Developers. See the COPYRIGHT
// file at the top-level directory of this distribution and at
// http://rust-lang.org/COPYRIGHT.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.

use target::{Target, TargetResult};

pub fn target() -> TargetResult {
let mut base = super::linux_base::opts();
base.cpu = "x86-64".to_string();
base.max_atomic_width = 64;
base.pre_link_args.push("-m64".to_string());
Ok(Target {
llvm_target: "x86_64-unknown-linux-uclibc".to_string(),
data_layout: "e-m:e-i64:64-f80:128-n8:16:32:64-S128".to_string(),
target_endian: "little".to_string(),
target_pointer_width: "64".to_string(),
arch: "x86_64".to_string(),
target_os: "linux".to_string(),
target_env: "uclibc".to_string(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The libc crate doesn't know about target_env = uclibc so I guess would be mostly empty?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe I will need to add that to the libc crate.

target_vendor: "unknown".to_string(),
options: base,
})
}