Historically, when handling issues like "the tools on the system we are delivering the

Some relevant outputs. --version is the usual, <code

Consider using `llvm-strip` about rust HOT 12 OPEN

workingjubilee commented on August 19, 2024 3

Consider using `llvm-strip`

from rust.

Comments (12)

Mark-Simulacrum commented on August 19, 2024 1

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.

workingjubilee commented on August 19, 2024

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.

workingjubilee commented on August 19, 2024

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.

taiki-e commented on August 19, 2024

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.

workingjubilee commented on August 19, 2024

y'all really out here shipping binutils with only one arch supported when ./configure --enable-targets=all is right there, huh

from rust.

workingjubilee commented on August 19, 2024

At least one prominent Linux distribution has informed me that their strip does not have cross-compilation support.

from rust.

the8472 commented on August 19, 2024

despite the local toolchain having an applicable, useful strip

Another option would be looking at all the available strips 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.

workingjubilee commented on August 19, 2024

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.

workingjubilee commented on August 19, 2024

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.

workingjubilee commented on August 19, 2024

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.

ChrisDenton commented on August 19, 2024

There was a discussion on zulip about llvm-tools.

from rust.

wesleywiser commented on August 19, 2024

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.

Consider using `llvm-strip` about rust HOT 12 OPEN

Comments (12)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent