www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - LDC 1.42.0

reply kinke <noone nowhere.com> writes:
Glad to announce LDC 1.42. Some major changes:

* Based on D 2.112.1+ (today's upstream stable).
* Support for LLVM 21; the prebuilt packages use v21.1.8.
* New prebuilt package for Alpine Linux aarch64.
* `ldc2.conf` can now be a directory. All the files inside it, 
ordered naturally, will be concatenated and treated like a big 
config. This enables simpler config extensions (e.g., for 
cross-compilation targets) by adding files instead of modifying a 
file. This feature comes with breaking CMake changes.
* Breaking change for dcompute: The special ` kernel` UDA is now 
a function and requires parentheses.
* New `--fdebug-prefix-map` command-line option to aid 
reproducible builds.

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

Thanks to all contributors & sponsors!
Mar 01
next sibling parent Johan <j j.nl> writes:
On Sunday, 1 March 2026 at 19:51:41 UTC, kinke wrote:

 Glad to announce LDC 1.42.


Excellent!

Godbolt's Compiler Explorer should have it within the next days.

cheers,
   Johan
Mar 01
prev sibling next sibling parent reply Witold Baryluk <witold.baryluk gmail.com> writes:
On Sunday, 1 March 2026 at 19:51:41 UTC, kinke wrote:

 Glad to announce LDC 1.42. Some major changes:

 * Based on D 2.112.1+ (today's upstream stable).
 * Support for LLVM 21; the prebuilt packages use v21.1.8.
 * New prebuilt package for Alpine Linux aarch64.
 * `ldc2.conf` can now be a directory. All the files inside it, 
 ordered naturally, will be concatenated and treated like a big 
 config. This enables simpler config extensions (e.g., for 
 cross-compilation targets) by adding files instead of modifying 
 a file. This feature comes with breaking CMake changes.
 * Breaking change for dcompute: The special ` kernel` UDA is 
 now a function and requires parentheses.
 * New `--fdebug-prefix-map` command-line option to aid 
 reproducible builds.

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

 Thanks to all contributors & sponsors!


Thanks for all the work.

Any pointers and instruction on musl usage?

I tried

```
user debian:~/ldc2-1.42.0-alpine-x86_64$ ./bin/ldc2 -static 
../hello.d
/usr/bin/x86_64-linux-gnu-ld.bfd: 
/home/user/ldc2-1.42.0-alpine-x86_64/bin/../lib/libphobos2-ldc.a(curl.o): in
function `std.net.curl.CurlAPI.loadAPI()':
...
```

I also tried `-mtriple=x86_64-linux-musl`, but it does nothing.


Without `-static` it compiles, but links to glibc.
Mar 01
parent reply kinke <noone nowhere.com> writes:
On Monday, 2 March 2026 at 00:53:45 UTC, Witold Baryluk wrote:

 Any pointers and instruction on musl usage?
 […]
 Without `-static` it compiles, but links to glibc.


This happens when running the Alpine package on a non-musl 
distro. The Alpine compiler targets musl by default, as do its 
bundled druntime and Phobos libraries - incl. 64-bit `real` for 
example (not the 80-bit x87 as for glibc on x86[_64]). For 
linking, it defaults to the `cc` C compiler, assuming that it's a 
matching musl-toolchain one (as on Alpine). On Debian/Ubuntu, you 
can set it via e.g. `-gcc=x86_64-linux-musl-gcc` after installing 
the `musl-dev` apt package. - But it's probably best/easiest when 
using the prebuilt Alpine package in an Alpine-based container.

As for Phobos' `std.net.curl`, AFAIK that is just plain 
incompatible with fully-static executables, because it's based on 
libdl (dlopen/sym/close). While you can theoretically link 
libcurl and all of its dependencies statically, and make sure the 
`curl_*` C symbols are all exported as dynamic symbols (so that 
`std.net.curl` can `dlsym()` them from the executable), you still 
cannot make any executable depending on `std.net.curl` fully 
static via `-static`. This is e.g. the reason why some bundled 
tools in the LDC Alpine packages aren't fully static and depend 
on a (musl-targeting) libcurl loaded at runtime, e.g., 
`ldc-build-runtime`.

FWIW, Phobos also has raw C bindings in `etc.c.curl`.
Mar 01
parent Witold Baryluk <witold.baryluk gmail.com> writes:
On Monday, 2 March 2026 at 02:16:15 UTC, kinke wrote:

 On Monday, 2 March 2026 at 00:53:45 UTC, Witold Baryluk wrote:

 Any pointers and instruction on musl usage?
 […]
 Without `-static` it compiles, but links to glibc.


 This happens when running the Alpine package on a non-musl 
 distro. The Alpine compiler targets musl by default, as do its 
 bundled druntime and Phobos libraries - incl. 64-bit `real` for 
 example (not the 80-bit x87 as for glibc on x86[_64]). For 
 linking, it defaults to the `cc` C compiler, assuming that it's 
 a matching musl-toolchain one (as on Alpine). On Debian/Ubuntu, 
 you can set it via e.g. `-gcc=x86_64-linux-musl-gcc` after 
 installing the `musl-dev` apt package. - But it's probably 
 best/easiest when using the prebuilt Alpine package in an 
 Alpine-based container.


Thanks for the help.

Yeah. I am on Debian.

I tried with `-gcc` flag and it helps, but not quiet

```
user debian:~/ldc2-1.42.0-alpine-x86_64$ ./bin/ldc2 -static 
-gcc=$HOME/musl-1.2.5/./obj/musl-gcc ../hello.d
/usr/bin/x86_64-linux-gnu-ld.bfd: 
/usr/lib/gcc/x86_64-linux-gnu/15/libgcc_eh.a(unwind-dw2-fde-dip.o): in function
`_Unwind_Find_FDE':
(.text+0x290c): undefined reference to `_dl_find_object'
/usr/bin/x86_64-linux-gnu-ld.bfd: (.text+0x2b90): undefined 
reference to `_dl_find_object'
collect2: error: ld returned 1 exit status
Error: /home/user/musl-1.2.5/./obj/musl-gcc failed with status: 1
```

And with Debian provided one:

```
user debian:~/ldc2-1.42.0-alpine-x86_64$ ./bin/ldc2 -static 
-gcc=x86_64-linux-musl-gcc ../hello.d
/usr/bin/x86_64-linux-gnu-ld.bfd: 
/usr/lib/gcc/x86_64-linux-gnu/15/libgcc_eh.a(unwind-dw2-fde-dip.o): in function
`_Unwind_Find_FDE':
(.text+0x290c): undefined reference to `_dl_find_object'
/usr/bin/x86_64-linux-gnu-ld.bfd: (.text+0x2b90): undefined 
reference to `_dl_find_object'
collect2: error: ld returned 1 exit status
Error: /usr/bin/x86_64-linux-musl-gcc failed with status: 1
```


PS. I do not need curl, it is just first line of failure. I do 
understand why phobos complains about static linking to glibc, 
i.e. when using NSS for things like hostname resolution, and 
stuff - but I do not need NSS, and simplified resolver for musl 
is all I need. Same for user / group name resolution.



I did try in `alpine` docker container, with their prepackaged 
ldc (I also needed to install clang), and it did produce 
musl-linked binary (but it was still I think linked dynamically 
to musl)

```
$ podman run --rm -it alpine

( 1/33) Installing clang21-headers (21.1.2-r2)
...
OK: 733.1 MiB in 49 packages



hello.d


	/lib/ld-musl-x86_64.so.1 (0x7fe6f2aeb000)


hello: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
static-pie linked, 
BuildID[sha1]=03644e6f92304c90cb0d57585f1c87c1f0d55acd, with 
debug_info, not stripped

```
Mar 01
prev sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Sun, Mar 01, 2026 at 07:51:41PM +0000, kinke via Digitalmars-d-announce
wrote:

 Glad to announce LDC 1.42.


Awesome!  Thanks to all the LDC team for continuing to maintain and
release an awesome D compiler.



 Some major changes:


[...]

 * `ldc2.conf` can now be a directory. All the files inside it, ordered
 naturally, will be concatenated and treated like a big config. This
 enables simpler config extensions (e.g., for cross-compilation
 targets) by adding files instead of modifying a file. This feature
 comes with breaking CMake changes.


[...]

This will be very convenient.  Thanks!


--T
Mar 04