Hi everyone,

LDC 1.4.0 is out now. The highlights of version 1.4 in a nutshell:

* Based on D 2.074.1.
* Shipping with ldc-build-runtime, a small D tool to easily (cross-)compile the runtime libraries yourself.
* Full Android support, incl. emulated TLS.
* Improved support for AddressSanitizer and libFuzzer. The libraries are shipped with the prebuilt Linux x86_64 and OSX packages.
* Prebuilt Linux x86_64 package shipping with LTO plugin, catching up with the OSX package.
* Prebuilt packages include the NVPTX LLVM target, in order to target CUDA via DCompute.

Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.4.0

Thanks to everybody contributing!

On Monday, 11 September 2017 at 23:35:42 UTC, kinke wrote:
> Hi everyone,
>
> LDC 1.4.0 is out now. The highlights of version 1.4 in a

Thanks. Why is the executable named `ldc2` on Linux? If it's for historical reasons, why not just drop it and use just `ldc`?

On Wednesday, 13 September 2017 at 07:17:04 UTC, Arun Chandrasekaran wrote:
> On Monday, 11 September 2017 at 23:35:42 UTC, kinke wrote:
>> Hi everyone,
>>
>> LDC 1.4.0 is out now. The highlights of version 1.4 in a
>
> Thanks. Why is the executable named `ldc2` on Linux? If it's for historical reasons, why not just drop it and use just `ldc`?

I agree, it was probably done to differentiate with D 1.0 back in the day, but enough time has passed since D 1.0's demise that we can probably just switch, while keeping a ldc2 symbolic link or wrapper so as not to break any code.

On Wednesday, 13 September 2017 at 08:07:38 UTC, Joakim wrote:
> On Wednesday, 13 September 2017 at 07:17:04 UTC, Arun Chandrasekaran wrote:
>> Why is the executable named `ldc2` on Linux? If it's for historical reasons, why not just drop it and use just `ldc`?

Because we can't simply change it and thus break integration with build tools.

> I agree, it was probably done to differentiate with D 1.0 back in the day, but enough time has passed since D 1.0's demise that we can probably just switch, while keeping a ldc2 symbolic link or wrapper so as not to break any code.

Yep that is/was the reason. Symbolic file links on Windows are very uncommon, as they require an NTFS file system and Vista or newer.

On Wednesday, 13 September 2017 at 12:28:39 UTC, kinke wrote:
> Yep that is/was the reason. Symbolic file links on Windows are very uncommon, as they require an NTFS file system and Vista or newer.

A hard link should be fine for a file.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363860%28v=vs.85%29.aspx docs say hard links were supported on xp.

On Wednesday, 13 September 2017 at 13:07:51 UTC, Kagamin wrote:
> On Wednesday, 13 September 2017 at 12:28:39 UTC, kinke wrote:
>> Yep that is/was the reason. Symbolic file links on Windows are very uncommon, as they require an NTFS file system and Vista or newer.
>
> A hard link should be fine for a file.
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363860%28v=vs.85%29.aspx docs say hard links were supported on xp.

Or, worst case, we could even provide a tiny binary that simply forwards to ldc, as ldmd2 currently does after adjusting for ldc's flags.

On Wednesday, 13 September 2017 at 13:07:51 UTC, Kagamin wrote:
> On Wednesday, 13 September 2017 at 12:28:39 UTC, kinke wrote:
>> Yep that is/was the reason. Symbolic file links on Windows are very uncommon, as they require an NTFS file system and Vista or newer.
>
> A hard link should be fine for a file.
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363860%28v=vs.85%29.aspx docs say hard links were supported on xp.

Requires NTFS too, only supported on the same volume (can't just move/copy to another partition), and the targets are apparently fixed (no relative link targets) after a quick test (copying to other directory). So I don't see an alternative to ugly wrappers for Windows compatibility.

On Wednesday, 13 September 2017 at 14:04:33 UTC, kinke wrote:
> only supported on the same volume (can't just move/copy to another partition), and the targets are apparently fixed (no relative link targets) after a quick test (copying to other directory).

Erm, yeah, by definition as hard link. ;) As we don't have an installer on Windows, just a portable archive, hard links aren't an option.

On Wednesday, 13 September 2017 at 14:04:33 UTC, kinke wrote:
> Requires NTFS too, only supported on the same volume (can't just move/copy to another partition), and the targets are apparently fixed (no relative link targets) after a quick test (copying to other directory).

I would expect them to be in the same folder. The downside for hardlink can be deletion and recreation of one of the files, after which they become unrelated files.

On Monday, 11 September 2017 at 23:35:42 UTC, kinke wrote:
> Hi everyone,
>
> LDC 1.4.0 is out now. The highlights of version 1.4 in a nutshell:
>
> * Based on D 2.074.1.
> * Shipping with ldc-build-runtime, a small D tool to easily (cross-)compile the runtime libraries yourself.
> * Full Android support, incl. emulated TLS.
> * Improved support for AddressSanitizer and libFuzzer. The libraries are shipped with the prebuilt Linux x86_64 and OSX packages.
> * Prebuilt Linux x86_64 package shipping with LTO plugin, catching up with the OSX package.
> * Prebuilt packages include the NVPTX LLVM target, in order to target CUDA via DCompute.
>
> Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.4.0
>
> Thanks to everybody contributing!

I have updated the wiki page on building ldc from source, showing how to build our branch of llvm and switching it to CMake:

https://wiki.dlang.org/Building_LDC_from_source

I have also added some info about building on or for Android.  Please look it over and add anything I missed.

I will now remove the instructions on building ldc for Android here, since it's all in the official page now and no patches are needed:

https://wiki.dlang.org/Build_LDC_for_Android