ldc icon indicating copy to clipboard operation
ldc copied to clipboard

Add a way to not embed the full path to the compiler installation directory in build outputs

Open symphorien opened this issue 3 years ago • 1 comments

(Note: I'm opening this issue as a downstream packager, namely for NixOS, and I'm not very familiar with D)

Currently, when building D programs, the build outputs can contain the full path to the compiler. Checked to happen with btdu and ldc itself (pointing to the bootstrap ldc compiler) as compiled with nix.

This is problematic for two reasons at least:

  • reproducible builds https://tests.reproducible-builds.org/debian/dbd/unstable/amd64/ldc_1.28.0-2.diffoscope.html#ldc_-.--.---_amd--.deb---data.tar.xz---data.tar---.-usr-bin-ldc-build-runtime---strings---all---bytes-----
  • with the nix package manager specifically: a runtime dependency is automatically declared on every package whose path appears in the build outputs. As a consequence, btdu depends on ldc which in turns depends on ldc-bootstrap. In the end installing btdu for an end-user downloads 1GB too much. As a downstream maintainer I can manually remove the dependency with sed by replacing all the occurences of the paths to the compiler by /doesnotexist but I am afraid that it will break the build output subtly.

The ideal solution would be to only embed relative paths to the compiler directory.

Another one, which requires work for downstream, would be to provide an equivalent to -ffile-prefix-map in gcc (https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html) and --remap-path-prefix in rustc (https://doc.rust-lang.org/rustc/command-line-arguments.html#--remap-path-prefix-remap-source-names-in-output). This way we can pass --remap-path-prefix /dcompilerlocation=/build systematically to the compiler and we don't get the aforementioned issues.

Example of specific issue:

$  strings result/bin/btdu | grep /nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/algorithm/iteration.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/core/internal/string.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/datetime/timezone.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/utf.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/conv.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/uni/package.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/string.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/algorithm/searching.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/algorithm/mutation.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/algorithm/sorting.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/path.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/getopt.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/format/package.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/net/curl.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/range/package.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/regex/internal/ir.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/regex/internal/kickstart.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/regex/internal/parser.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/regex/package.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/base64.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/stdio.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/file.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/random.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/encoding.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/format/write.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/format/spec.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/array.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/range/primitives.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/format/internal/write.d
/nix/store/wdmkjkcczk0nvnpi78c79wzrfb80i2jc-ldc-1.27.1/include/d/std/format/internal/floats.d

symphorien avatar Jan 29 '22 14:01 symphorien

These filenames are mostly referenced by __FILE__ usages, e.g., for assertions, bounds checks, enforce() calls etc.

The ideal solution would be to only embed relative paths to the compiler directory.

Not for the regular user - relative paths are currently relative to the directory the compiler was invoked in. I highly doubt anyone would prefer fake-relative paths to the modules shipped with the compilers. The current absolute path makes sure anyone can open that file directly and take a look at it.

Another one, which requires work for downstream, would be to provide an equivalent to -ffile-prefix-map in gcc

Yeah I guess that would be needed for your case.

kinke avatar Jan 30 '22 12:01 kinke