Re: LDC 1.28.1
On Wednesday, 19 January 2022 at 15:55:39 UTC, kinke wrote: On Wednesday, 19 January 2022 at 13:55:56 UTC, workman wrote: Thanks for the kind reply. This azure download link work for me very well, with LTO or without LTO, the project build and run without problem. Glad to hear that, thanks for the feedback! My pleasure. I try use LDC for IOS with https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.1-rc3/clang+llvm-13.0.1-rc3-x86_64-apple-darwin.tar.xz (clang to build c library). This office llvm-13 support -arch arm64e flags, to link with ldc2 I get this error: ```sh tests.o has architecture arm64 which is incompatible with target architecture arm64e ``` Is there a option to made ldc2 support arch flags for apple ?
Re: LDC 1.28.1
On Wednesday, 19 January 2022 at 13:03:11 UTC, kinke wrote: Hi; LTO with lld for ELF targets has just been fixed in master, after v1.28.1. Without `-betterC` at least, not sure if `-betterC` was affected too in some way. Bumping LLVM to v13 wasn't trivial this time. There's https://github.com/ldc-developers/ldc/pull/3842 using an LLVM v13.0.1-rc2+, which fixed serious issues we've had with the gold linker (lld v13 was fine). You can download that CI artifact (with enabled assertions) and give it a try to see if it works for you: https://dev.azure.com/ldc-developers/ldc/_build/results?buildId=3243=artifacts=false=publishedArtifacts Thanks for the kind reply. This azure download link work for me very well, with LTO or without LTO, the project build and run without problem.
Re: LDC 1.28.1
On Saturday, 15 January 2022 at 15:43:16 UTC, Brian Callahan wrote: On Thursday, 13 January 2022 at 15:51:07 UTC, kinke wrote: A new patch version was just released: Thanks! Working on the OpenBSD package update as we speak... ~Brian Hi kinke, Thanks for the great work. I has some link problem with lld-12 if use with "--gc-sections -s", confirm on x86-64 and aarch64. (build with betterC) upgrade to lld-13(or NDK lld-14) no such problem. The lld-12 link as expect, but when start binary the quickjs promise stop work after one async call, remove "--gc-sections -s" fix the problem but generate huge binary. I has problem with cross llvm-version LTO, so I want to use same llvm version and upgrade to llvm-13. I want to know if I build ldc with llvm13 myself, will it work for betterC project ?
Re: Classes in D with betterC
On Tuesday, 23 November 2021 at 05:25:46 UTC, Stanislav Blinov wrote: Maybe it's a language or cultural issue? I'm not being bashful. "Use classes", at least to me, means, well, "use classes", and not "use a subset of classes that's really not much better than structs as you can't fully support inheritance anyway because destruction is a mess". In other words, in order to fully appreciate the message of your article, one has to already be aware of all the other issues. Which is a dangerous presupposition for a public article, especially not prefaced accordingly. Thanks for your input! I'm going to fix the issues you presented. You're welcome :) If you can only create C++ class object but can not destroy them, and can not support dynamic cast, then C++ class object is not working. Maybe the title could be "You can use C++ in betterC but they are not working", or add into prefaced section. There is no roadmap about when it could be work, or plan to fixed should also be mentioned.
Re: Time to setup D's wallet
On Tuesday, 9 November 2021 at 17:29:37 UTC, Rumbu wrote: Nim received a nice donation :) https://nim-lang.org/blog/2021/10/25/nim-receives-100k-usd-bitcoin.html You never know when it happens. There is a lot developer build digital coin product with NIM and made a fortune, by help NIM they can made more money in the future. I am not sure D has that kind users.
Re: Beta 2.098.0
On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: On 10/5/2021 10:36 AM, ag0aep6g wrote: it's also true that Walter prioritizes new features instead (ImportC is the latest fad) ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Unfortunately, ImportC is useless if it only half works. It has to work with existing C headers, which is why I'm concentrating on it to get to that point. Lack of ImportC has wasted a *lot* of developer time, making it a high leverage investment of time. Just think of all the time lost doing manual conversion of .h files, and then doing them again and again as they evolve. Then not one, not two, but *three* different automated programs were developed to try and resolve this (one of which I wrote). Then think of all the projects *not* done because of the barrier of trying to deal with several thousand lines of .h files. The Diemos project was an effort to crowdsource conversion of .h files to D, but it just was not adequate. In summary, ImportC is totally worth the effort. I should have done it 15 years ago. ImportC is more important to me then @live, because I think I will have a very hard time to make @live to work in my project. I suppose with ImportC, I an use all the meta programming ability with C header file ? (for example find all struct from a header.h and every details at CTFE time)
Re: LDC 1.28.0
On Tuesday, 19 October 2021 at 23:37:22 UTC, kinke wrote: Glad to announce LDC 1.28 - some highlights: * Based on D 2.098.0+ (yesterday's stable). * Dynamic casts across binary boundaries (DLLs etc.) now work. * Windows: `-dllimport=defaultLibsOnly` doesn't require `-linkonce-templates` anymore. * dcompute: Basic support for OpenCL image I/O. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.28.0 Thanks to all contributors & sponsors! Thanks for the amazing work!
Re: LDC 1.28.0
On Tuesday, 19 October 2021 at 23:37:22 UTC, kinke wrote: Glad to announce LDC 1.28 - some highlights: * Based on D 2.098.0+ (yesterday's stable). * Dynamic casts across binary boundaries (DLLs etc.) now work. * Windows: `-dllimport=defaultLibsOnly` doesn't require `-linkonce-templates` anymore. * dcompute: Basic support for OpenCL image I/O. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.28.0 Thanks to all contributors & sponsors! Thanks for the great work.
Re: LDC 1.28.0-beta1
On Saturday, 25 September 2021 at 21:30:49 UTC, kinke wrote: Glad to announce the first beta for LDC 1.28 - some highlights: * Based on D 2.098.0-beta.2+ (today's stable). * Dynamic casts across binary boundaries (DLLs etc.) now work. * Windows: `-dllimport=defaultLibsOnly` doesn't require `-linkonce-templates` anymore. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.28.0-beta1 Please help test, and thanks to all contributors & sponsors! Thanks for the great work. LLVM 13 is release, I hope LDC will upgrade to LLVM 13.
Re: LDC 1.27.0-beta2
On Thursday, 24 June 2021 at 23:14:26 UTC, kinke wrote: Glad to announce the second beta for LDC 1.27. Some noteworthy changes since beta1: * Frontend and druntime/Phobos upgraded to yesterday's DMD stable. * Windows DLL support: some fixes/tweaks and a new -dllimport option for greater flexibility. * Prebuilt Linux and Mac packages can show significant compiler performance increases due to newly employing the mimalloc allocator. * Important fixes for -linkonce-templates, DWARF v5 (e.g. with linked-in C[++] parts compiled with gcc 11) and bundled dub supporting somewhat longer paths on Windows. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.27.0-beta2 Please help test, and thanks to all contributors & sponsors! undefined symbol __fieldPostblit and __postblit cause link error only with LTO enabled for windows mingw target. There is more undefined symbols for LDC 1.27 compare to 1.26. My code not changed and they used to work with old version ldc. without LTO all work fine, old LDC link with -flto and -O fix the missing symbol, but 1.26 && 1.27 not work anymore.
