Automatic mem feature for -none targets

[steveyko]

I am cross-compiling a Rust library for aarch64-unknown-none-softfloat using cargo-xbuild and I'd like to disable the mem feature for compiler-builtins. I have a libc for my platform.

It looks like build.rs is now changed to automatically enable the mem feature when a target includes "-none" and it breaks my linking process due to multiple definitions of memcpy and other functions.

I admit that I don't know the background for the build.rs change, but I am not sure if forcing the mem feature for certain targets is the best possible idea. If that's going to stay, I can come up with my own workaround just for my setting, but it doesn't seem ideal to me.

[bjorn3]

A -none target is for when you are not using an OS, but running on bare metal. What OS are you using? Try using an existing target for that OS, or if not existing write your own json target specification file.

[steveyko]

Yup, exactly, I am not using an OS. It's bare metal with a mix of assembly, C, and Rust.

Feel free to close this issue if you think that the mem feature forcing is necessary at this point. I was just throwing it out there, and I can have my own workaround (perhaps I'll just have my own json spec as you said).

[bjorn3]

Yup, exactly, I am not using an OS. It's bare metal with a mix of assembly, C, and Rust.

Then how can you have a libc? Libc is for interfacing with an OS.

[steveyko]

It's just a C library that provides libc functions for the C side. It's not a libc for an OS.

[MabezDev]

I would also like to be able to turn this off. I am running on an embedded system where all access to flash must be word aligned, meaning I need to supply mem functions that do so. Any ideas?

The arch is not upstream in llvm, therefore I am running a fork, happy to hack rustc to get there :D

[josephlr]

I am running on an embedded system where all access to flash must be word aligned, meaning I need to supply mem functions that do so. Any ideas?

I'm not sure how your LLVM fork will handle things, but see this comment: #253 (comment). Using custom memcpy/memset/etc... might not help with your problem. For accesses to flash memory (instead of normal RAM accesses), you probably have to use some sort of volatile access (but there are helper crates that make this not too bad).

[MabezDev]

I'm not sure how your LLVM fork will handle things, but see this comment: #253 (comment). Using custom memcpy/memset/etc... might not help with your problem. For accesses to flash memory (instead of normal RAM accesses), you probably have to use some sort of volatile access (but there are helper crates that make this not too bad).

Thank you, this is something I hadn't considered.