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

Jump to bottom

Stripping a Linux binary built with raco exe --orig-exe gives a contract violation #3831

Closed
sschwarzer opened this issue May 13, 2021 · 1 comment
Closed

Stripping a Linux binary built with raco exe --orig-exe gives a contract violation #3831

sschwarzer opened this issue May 13, 2021 · 1 comment

Comments

@sschwarzer
Copy link
Contributor

What version of Racket are you using?
8.1 [cs]

What program did you run?
I compiled a Racket program on Fedora Linux 33 with

raco exe --orig-exe myprogram.rkt

(Actually the program source is in a different directory and is named differently.)

If I run the program with ./myprogram --help, I get the help output as expected.

If I run strip myprogram and then ./myprogram --help, I get

open-input-bytes: contract violation
  expected: bytes?
  given: #<eof>

What should have happened?
The output of the program should be the same as before stripping.

If you got an error message, please include it here.
See above

Please include any other relevant details

  • I'm running Fedora Linux 33.
  • I installed Racket from the shell installer racket-8.1-x86_64-linux-cs.sh.
@mflatt
Copy link
Member

mflatt commented May 13, 2021

The issue here is that --orig-exe is disabling proper ELF manipulation of the executable by raco exe and uses absolute-file-offset mode. Running strip can change offsets or discard the orphaned (not in an ELF section) bytes. So, --orig-exe mode should be improved.

mflatt added a commit to mflatt/racket that referenced this issue May 15, 2021
@mflatt
clean up self-path and ELF handling for embedding executables
b0f0dd8 
Clean up tangled and partly repeated code, and normalize ELF use for
boot files and embedded modules. Also, repair Unix-style Mac OS
builds.

With these changes, `raco exe` should always produce a well-formed
ELF, Mach-O, or PE excutable. The mode that just appends to the end of
the executable should happen only platforms that don't use one of
those three --- which are very rare and unlikely supported, anyway.

Closes racket#3831
@mflatt mflatt closed this as completed in 0f74380 May 15, 2021
maueroats pushed a commit to maueroats/racket that referenced this issue Jun 17, 2021
@mflatt
clean up self-path and ELF handling for embedding executables
b54a1e9 
Clean up tangled and partly repeated code, and normalize ELF use for
boot files and embedded modules. Also, repair Unix-style Mac OS
builds.

With these changes, `raco exe` should always produce a well-formed
ELF, Mach-O, or PE excutable. The mode that just appends to the end of
the executable should happen only platforms that don't use one of
those three --- which are very rare and unlikely supported, anyway.

Closes racket#3831
maueroats pushed a commit to maueroats/racket that referenced this issue Jun 17, 2021
@mflatt
clean up self-path and ELF handling for embedding executables
e1c40d4 
Clean up tangled and partly repeated code, and normalize ELF use for
boot files and embedded modules. Also, repair Unix-style Mac OS
builds.

With these changes, `raco exe` should always produce a well-formed
ELF, Mach-O, or PE excutable. The mode that just appends to the end of
the executable should happen only platforms that don't use one of
those three --- which are very rare and unlikely supported, anyway.

Closes racket#3831
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mflatt @sschwarzer