How to use a system compiler

[baryluk]

Linux, Debian testing

gdc 13.2.0-7, also had ldc 1.35.0 (LLVM 16), and dmd v2.106.0.

Tried running with gdc,

user@debian:~/aa$ dub run --compiler=gdc hipreme_engine:build_selector
             Building package hipreme_engine:build_selector in /home/user/.dub/packages/hipreme_engine/1.0.13/hipreme_engine/tools/user/build_selector/
     Warning Dependency 'arsd-official:terminal' depends on git branch '~master', which is deprecated.
             Specify the git repository and commit hash in your dub.json:
             "arsd-official:terminal": {"repository": "git+<git url>", "version": "<commit>"}
     Warning Dependency 'arsd-official:cgi' depends on git branch '~master', which is deprecated.
             Specify the git repository and commit hash in your dub.json:
             "arsd-official:cgi": {"repository": "git+<git url>", "version": "<commit>"}
     Warning Dependency 'arsd-official:minigui' depends on git branch '~master', which is deprecated.
             Specify the git repository and commit hash in your dub.json:
             "arsd-official:minigui": {"repository": "git+<git url>", "version": "<commit>"}
     Warning Warning: License in sub-package hipreme_engine:build_selector is different than its parent package, this is discouraged.
    Starting Performing "debug" build using gdc for x86_64.
  Up-to-date arsd-official:core ~master: target for configuration [library] is up to date.
  Up-to-date arsd-official:cgi ~master: target for configuration [embedded_httpd] is up to date.
  Up-to-date arsd-official:color_base ~master: target for configuration [library] is up to date.
  Up-to-date arsd-official:simpledisplay ~master: target for configuration [normal] is up to date.
  Up-to-date arsd-official:textlayouter ~master: target for configuration [library] is up to date.
  Up-to-date arsd-official:minigui ~master: target for configuration [library] is up to date.
  Up-to-date arsd-official:terminal ~master: target for configuration [normal] is up to date.
    Building objc_meta 1.0.11: building configuration [library]
../.dub/packages/objc_meta/1.0.11/objc_meta/source/objc/runtime.d:2:15: internal compiler error: in make_import, at d/imports.cc:48
    2 | public import objc.meta : selector, ObjectiveC, ObjcExtend, instancetype;
      |               ^
0x7f4eacf1c6c9 __libc_start_call_main
    ../sysdeps/nptl/libc_start_call_main.h:58
0x7f4eacf1c784 __libc_start_main_impl
    ../csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-13/README.Bugs> for instructions.
Error gdc failed with exit code 1.

Ok. Fair enough, requires some version probably and stuff (this objc probably should not even be a dependency on Liunx).

Lets try system ldc:

user@debian:~/aa$ dub run --compiler=ldc2 hipreme_engine:build_selector | cat
             Building package hipreme_engine:build_selector in /home/user/.dub/packages/hipreme_engine/1.0.13/hipreme_engine/tools/user/build_selector/
     Warning Dependency 'arsd-official:terminal' depends on git branch '~master', which is deprecated.
             Specify the git repository and commit hash in your dub.json:
             "arsd-official:terminal": {"repository": "git+<git url>", "version": "<commit>"}
     Warning Dependency 'arsd-official:cgi' depends on git branch '~master', which is deprecated.
             Specify the git repository and commit hash in your dub.json:
             "arsd-official:cgi": {"repository": "git+<git url>", "version": "<commit>"}
     Warning Dependency 'arsd-official:minigui' depends on git branch '~master', which is deprecated.
             Specify the git repository and commit hash in your dub.json:
             "arsd-official:minigui": {"repository": "git+<git url>", "version": "<commit>"}
     Warning Warning: License in sub-package hipreme_engine:build_selector is different than its parent package, this is discouraged.
    Starting Performing "debug" build using ldc2 for x86_64.
  Up-to-date arsd-official:core ~master: target for configuration [library] is up to date.
  Up-to-date arsd-official:cgi ~master: target for configuration [embedded_httpd] is up to date.
  Up-to-date arsd-official:color_base ~master: target for configuration [library] is up to date.
  Up-to-date arsd-official:simpledisplay ~master: target for configuration [normal] is up to date.
  Up-to-date arsd-official:textlayouter ~master: target for configuration [library] is up to date.
  Up-to-date arsd-official:minigui ~master: target for configuration [library] is up to date.
  Up-to-date arsd-official:terminal ~master: target for configuration [normal] is up to date.
  Up-to-date objc_meta 1.0.11: target for configuration [library] is up to date.
  Up-to-date hipreme_engine:build_selector 1.0.13: target for configuration [default] is up to date.
    Finished To force a rebuild of up-to-date targets, run again with --force
     Running ../.dub/packages/hipreme_engine/1.0.13/hipreme_engine/tools/user/build_selector/hipreme_engine_build_selector 

No ldcVersion specified, your HipremeEngine will attempt to install locally LDC2 1.36.0-beta1
    This compiler version is installed locally and won't affect your system D installation.
Your system will download a file: Download D cross compiler LDC2 1.36.0-beta1(https://github.com/ldc-developers/ldc/releases/download/v1.36.0-beta1/ldc2-1.36.0-beta1-linux-x86_64.tar.xz) [Y]es/[N]o

I do not like that.

Is there a way to not do that, and use system ldc by default?

Also please DO NOT do terminal reset, before printing this message. It screws things up (i.e. hard to copy build logs).

Additionally pressing N, causes terminal to be in-non-echo mode forever (until reset). Please do not touch echo mode. Require Y+Enter instead.

[MrcSnm]

gdc

Keep in mind that I've never used, not even once GDC for programming anything. I declare it completely unstable support for it. DMD and LDC are the recommended compilers.

Ok. Fair enough, requires some version probably and stuff (this objc probably should not even be a dependency on Liunx).

I agree that it should not be a dependency. Unfortunately, the only way to do that is by specifying other configuration, because this bug: https://github.com/dlang/dub/issues/2752, though it should be only on macOS, there are some advantages on testing side for the meta generation stuff. I may choose to tackle this by adding some special versions for it.

Is there a way to not do that, and use system ldc by default?

No. If you look at the changelog history of the D Runtime, it keeps changing every release and I do not have time to keep it compatible with older releases specially because I've yet to see a disadvantage in not updating it by now. If somebody is willing to help me maintain my WASM/PSVita runtime, okay, we can talk, but this is a lot of work.

Additionally pressing N, causes terminal to be in-non-echo mode forever (until reset). Please do not touch echo mode. Require Y+Enter instead.

That means it won't do anything after pressing simply Y? I may need to check one of the libraries I'm using

[MrcSnm]

I've tested and I think it may be fixed now the non-echo problem. On the system compiler, this is not really the recommended way to solve this. The bug fix on terminal must is on version 1.0.14

[baryluk]

Thanks for the answers.

Keep in mind that I've never used, not even once GDC for programming anything. I declare it completely unstable support for it.

I only use GDC (for many reasons). I have been using GDC for more than 10 years. I am perfectly happy with it. It is fine for it to not be officially supported (including compilation issues from time to time, either due to outdated phobos or D frontend, or bugs in Hipreme itself that did not handle it correctly).

The import issue of objc, looks like a possible bug in the compiler. I will follow on this with gdc folks.

Initially I read that it says "cannot import", but actually reading error message shows that it is an internal compiler error. Sorry about that.

No. If you look at the changelog history of the D Runtime, it keeps changing every release and I do not have time to keep it compatible with older releases specially because I've yet to see a disadvantage in not updating it by now

I want to use system compiler. If it breaks, or does not work, it is my problem.

For some usages (and possibly be a default) it is fine to use a bundled compiler and runtime, but there should be a way to specify system toolchain. What if I want to debug and fix gdc issues, what if I want to test a prerelease version of ldc, what if I want to compile it on not-yet-officially supported architecture like riscv, etc. etc. What if want stable release, and haver control over what is used.

I've tested and I think it may be fixed now the non-echo problem.

I am not so sure about this. If I kill it (kill -9), it will still leave the terminal in wrong mode.

That means it won't do anything after pressing simply Y?

Yes.

[baryluk]

Filled GDC bug upstream with minimal reproducer - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113125

[MrcSnm]

I want to use system compiler. If it breaks, or does not work, it is my problem.

Currently, you may specify "ldcPath" and trick the "ldcVersion" the same one which is the default here.

After some thought, I've concluded that I'm going to do a mini refactor onto the dependency section of build_selector. I'll introduce some kind of featureset required for each task available. I don't know how fast it will be, but it has already started since it was already in my plans to do that in future, but with this issue, I may increase the priority on it.

prerelease version of ldc

The way I'm doing this is by always updating to preleases of LDC, which means it is always using bleeding edge versions of the LDC compiler since I need to keep the D Runtime up to date, so this should not be a problem.

what if I want to compile it on not-yet-officially supported architecture like riscv, etc. etc.

This would need a new target input creation inside build_selector. Maybe having a way to define a custom target would be nice. But of course it won't be very portable, but I don't see myself working on that right now.

What if want stable release, and haver control over what is used.

On the featureset descriptor I'm doing, it may be a little more relaxed and may skip some checks based on that.