Crystal: Add a compile-time flag to strip paths from the binary.

[MrSorcus]

Currently, binaries can't be build as reproducible.
For example, build this code in two different directory.

require "yaml"

yaml = <<-YAML
foo: 123
YAML

struct Test
  YAML.mapping(
    bar: Int32
  )
end

Test.from_yaml yaml

You get different binaries with different hash sums.
Missing yaml attribute: bar .... to Int32 failed, at /home/user/tmp/src/main.cr:4:3:98 - this path should be stripped from binary file.
Even if you move all code into method and add rescue to catch all exceptions.

[straight-shoota]

These paths are debug information. You can skip that with --no-debug compiler flag. But then you're obviously lacking debug information, which might not be a perfect solution.
So yeah, in order to be reproducible, a binary must be built from the same working directory path.
IMO that seems like a legitimate requirement.
Why is that an issue to you?

[straight-shoota]

Alternatively, you could use the strip utility (or similar tools) to remove debug information from an executable. That has a similar effect (and some other consequences as well). Maybe that could be useful to you, for example to build and distribute with debug information, but calculate hashs of the stripped binary. Of course that inserts strip as a component into the reproducibility tool chain.

[MrSorcus]

These paths are debug information. You can skip that with --no-debug compiler flag. But then you're obviously lacking debug information, which might not be a perfect solution.
So yeah, in order to be reproducible, a binary must be built from the same working directory path.
IMO that seems like a legitimate requirement.
Why is that an issue to you?

Maybe i'm doing something wrong, but paths still exists even with --no-debug.
crystal build --release --no-debug main.cr - still contain paths.
I just get a warning, when packaging script with PKGBUILD.

==> WARNING: Package contains reference to $srcdir
usr/bin/main

[straight-shoota]

I see. That seems to be from the message of a TypeCastError which includes the source location. This message i created by the compiler explicitly and not subject to --no-debug (which AFAIK is finally handled by LLVM).

[asterite]

For example if you compile a go program the same happens, the path is there in the binary.

Is there a use case for this?

[MrSorcus]

For example if you compile a go program the same happens, the path is there in the binary.

Is there a use case for this?

Only reproducible builds i assume.
And maybe if path contains sensitive data (like user's name) somebody can brute-force a password for this user on build server. Haha.

[asterite]

On the other hand... https://banzaicloud.com/blog/go-1-13-favorite-features/

So I think this is probably good, but it's very low priority.

[straight-shoota]

A trivial solution would be to use only paths relative to CRYSTAL_PATH.