Comments (12)
Please don't rely on llvm-tools for this purpose, it's lack of -preview was just an accident (not an intentional stabilization).
It's also a larger component and we shouldn't make it downloaded by default for users, IMO, and as such the experience of rustc/cargo shouldn't degrade without it. I think duplicating llvm-strip as a sibling to rust-lld makes a lot of sense to give a uniform experience for users.
from rust.
This obviously was exacerbated by the recent decision to strip in --release
but I should note it was very much preexisting. And I'm not sure who exactly would be responsible for this decision, seems like a shared one.
from rust.
There are other options, of course, like trying to respect e.g. a $STRIP environment variable, I just don't know if other compilers already respect any such variable and thus if there would be any precedent/intuition/pattern we would find useful. These choices are also not mutually exclusive, either.
It may also be the case that this is sufficiently easy-enough to fix that the package management tools in question will sort this out and we should just twiddle our thumbs for a couple weeks. That would be mildly preferable to macOS hosts having Yet Another strip binary, even if the waste is trivial. I'm mostly just trying to collect the information that we have floating around.
from rust.
I think this would also help to fix the problem with strip in cross-compilation (#114411, and if my guess is correct illumos has the same issue not only macOS).
from rust.
y'all really out here shipping binutils with only one arch supported when ./configure --enable-targets=all
is right there, huh
from rust.
At least one prominent Linux distribution has informed me that their strip
does not have cross-compilation support.
from rust.
despite the local toolchain having an applicable, useful strip
Another option would be looking at all the available strip
s on the PATH and picking a preferred one / skipping bad ones. Assuming they can be easily identified.
At least one prominent Linux distribution has informed me that their strip does not have cross-compilation support.
Does that result in an error or in a corrupted binary like on macos? The former doesn't seem so bad since we can turn that into a warning or error.
from rust.
Some relevant outputs. --version
is the usual, --info
lists the supported architectures of this binutils.
$ strip --version
GNU strip (GNU Binutils) 2.42.0
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
$ llvm-strip --version
llvm-strip, compatible with GNU strip
LLVM (http://llvm.org/):
LLVM version 17.0.6
Optimized build.
$ strip --info
BFD header file version (GNU Binutils) 2.42.0
elf64-x86-64
(header little endian, data little endian)
i386
elf32-i386
(header little endian, data little endian)
i386
elf32-iamcu
(header little endian, data little endian)
iamcu
elf32-x86-64
(header little endian, data little endian)
i386
pei-i386
(header little endian, data little endian)
i386
pe-x86-64
(header little endian, data little endian)
i386
pei-x86-64
(header little endian, data little endian)
i386
elf64-little
(header little endian, data little endian)
i386
iamcu
bpf
elf64-big
(header big endian, data big endian)
i386
iamcu
bpf
elf32-little
(header little endian, data little endian)
i386
iamcu
bpf
elf32-big
(header big endian, data big endian)
i386
iamcu
bpf
pe-bigobj-x86-64
(header little endian, data little endian)
i386
pe-i386
(header little endian, data little endian)
i386
pdb
(header little endian, data little endian)
elf64-bpfle
(header little endian, data little endian)
bpf
elf64-bpfbe
(header big endian, data big endian)
bpf
srec
(header endianness unknown, data endianness unknown)
i386
iamcu
bpf
symbolsrec
(header endianness unknown, data endianness unknown)
i386
iamcu
bpf
verilog
(header endianness unknown, data endianness unknown)
i386
iamcu
bpf
tekhex
(header endianness unknown, data endianness unknown)
i386
iamcu
bpf
binary
(header endianness unknown, data endianness unknown)
i386
iamcu
bpf
ihex
(header endianness unknown, data endianness unknown)
i386
iamcu
bpf
plugin
(header little endian, data little endian)
elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 pei-i386 pe-x86-64
i386 elf64-x86-64 elf32-i386 ----------- elf32-x86-64 pei-i386 pe-x86-64
iamcu ------------ ---------- elf32-iamcu ------------ -------- ---------
bpf ------------ ---------- ----------- ------------ -------- ---------
pei-x86-64 elf64-little elf64-big elf32-little elf32-big
i386 pei-x86-64 elf64-little elf64-big elf32-little elf32-big
iamcu ---------- elf64-little elf64-big elf32-little elf32-big
bpf ---------- elf64-little elf64-big elf32-little elf32-big
pe-bigobj-x86-64 pe-i386 pdb elf64-bpfle elf64-bpfbe srec symbolsrec
i386 pe-bigobj-x86-64 pe-i386 --- ----------- ----------- srec symbolsrec
iamcu ---------------- ------- --- ----------- ----------- srec symbolsrec
bpf ---------------- ------- --- elf64-bpfle elf64-bpfbe srec symbolsrec
verilog tekhex binary ihex plugin
i386 verilog tekhex binary ihex ------
iamcu verilog tekhex binary ihex ------
bpf verilog tekhex binary ihex ------
$ llvm-strip --info
llvm-strip: error: unknown argument '--info'
from rust.
I'm going to push this into T-compiler's agenda for next week as the possible solutions all involve affecting rustc's behavior at least mildly.
from rust.
Hmm. I spent some time dinking about and it seems we do in fact ship llvm-tools
as a rustup component and they are no longer a "preview" anything, so the question would be if they should be considered effectively mandatory or not.
from rust.
There was a discussion on zulip about llvm-tools.
from rust.
I think using llvm-strip
is entirely reasonable here especially given the extremely small size of the tool. If we don't want to rely on llvm-tools
being installed, I think it would be reasonable to ship it in the sysroot (possibly duplicating it with one in llvm-tools
).
from rust.
Related Issues (20)
- ICE : non-eager expansion without a parent scope
- ICE : no entry found for key HOT 1
- target aarch64-linux-android Compilation error HOT 2
- Tracking Issue for Rust 2024: Make `unsafe_op_in_unsafe_fn` warn-by-default HOT 4
- ICE: rustc_abi `the len is 0 but the index is 0` calculating offset HOT 3
- Reasons for feature removals are not translatable
- Borrow incorrectly "escapes" function when calling method of blanket impl for `'static` type HOT 3
- "undefined reference to `WaitOnAddress'" error with nightly toolchain nightly-2024-03-28 on Windows GNU target HOT 2
- error[E0275]: overflow evaluating the requirement… when importing bevy_ecs HOT 2
- Missed Optimization when Matching on Complete Unicode Character Ranges with an Unreachable Arm HOT 1
- Missed optimization with reserve and extend_from_slice
- --crate-type=bin causes no_mangle symbols to be ommitted. HOT 4
- Internal compiler error when copying value of normally copyable type under `no_core` HOT 1
- ICE: `type variables should not be hashed?` HOT 1
- ICE: const generic with default const expr specified before type generic causes compiler to crash HOT 1
- ICE: virtual-function-elimination HOT 1
- rust-1.72.1 Unable to compile HOT 2
- ICE when using offset_of! in generic_const_exprs
- Miri reports leak in thread local allocation HOT 4
- Upgrade the Node.js version to 20
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust.