serve-d
serve-d copied to clipboard
Installed binaries on MacOS Catalina don't work due to ABI changes
I've noticed that after installing code-d
via Visual Studio Code Extension, shipped binaries won't work.
> $ /Users/nazriel/.vscode/extensions/webfreak.code-d-0.21.0/bin/dcd-server
dyld: lazy symbol binding failed: Symbol not found: _dyld_enumerate_tlv_storage
Referenced from: /Users/nazriel/.vscode/extensions/webfreak.code-d-0.21.0/bin/dcd-server
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: _dyld_enumerate_tlv_storage
Referenced from: /Users/nazriel/.vscode/extensions/webfreak.code-d-0.21.0/bin/dcd-server
Expected in: /usr/lib/libSystem.B.dylib
[1] 54366 abort /Users/nazriel/.vscode/extensions/webfreak.code-d-0.21.0/bin/dcd-server
Due to removal of deprecated APIs for TLS on MacOS, which D's runtime was using all binaries compiled with old Druntime stopped working.
Re-release with DMD >= 2.088.0 is required.
Building DCD via brew install --HEAD dcd
works.
Although I am not able to bump DCD version in homebrew since there was no new release of DCD since July and building against master doesn't seem like good idea.
Related issues:
- https://github.com/dlang/dmd/pull/10489
- https://github.com/Homebrew/homebrew-core/pull/45456
- https://github.com/dlang-community/DCD/issues/610
- https://github.com/dlang/druntime/pull/2666
you are right that's a problem, but recently all the dlang-community projects have removed the auto release bot (I don't really know why) so this is really hard to solve if there isn't going to be any public releases.
But I can probably just add inclusion of dcd-client and dcd-server in the pre-compiled serve-d binaries too. This should simplify a lot of things, but it won't allow users to have their own dcd-client/dcd-server binaries so easily as it will first pick the one directly next to serve-d.
@WebFreak001 thanks for reply!
Also I just realised that I created issue in wrong repo, sorry for that!
That probably should land in code-d
.
Just to clarify: serve-d binary works flawlessly, it's just DCD that is causing problems.
What I did right now is I used DCD built via homebrew --HEAD
and passed paths to it in code-d settings.
I guess what matters is user experience and working out of the box. Power users probably won't have big issues with configuring their own DCD stack.
What you think?
has been fixed by fixing the deployment / build scripts on dlang-community with GitHub Actions again