May 01, 2023

On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote:

>

But how is this possible in a cross-compiling context. I am not sure if I can do that with the D language either as pure D or better C. DMD does not seem to offer cross compiling. GDC can compile better C, but not sure mingw can compile D/betterC code.

I build programs for macOS, iOS, Windows with ldc2 cross-compiling capabilities from my Linux computer, and the experience is okay, the executables are working fine but the set-up is a bit complicated, you need to copy files from the windows toolchain, copy your ldc config and edit it with some stuff, and do that at each ldc2 update.

If you just need cross-architecture, then gdc is a good option since it is compiled in a lot of cross compilation toolchains. However, I never managed to build a working gdc myself with ucrt or mingw cross-compilation capabilities, it always ends up with a compiler unable to link or executables that can't be executed on Windows.

May 02, 2023
On 5/1/23 03:23, Mike Parker wrote:

> If you're referring to `rt_init` and `rt_term` are the `extern(C)`
> functions in `core.runtime`. It's not necessary to call those from C. A
> D library with a C interface can provide an `extern(C)` initialization
> function that internally calls `Runtime.initialize`.

Indeed. That appears at the following spot of one of my DConf presentations, which touches on several points relevant to writing a C library in D:

  https://youtu.be/FNL-CPX4EuM?t=2585

Ali

May 02, 2023
> Any D function marked as extern(C) can be called from C. As long as you have a C header file defining the functions and the appropriate C declarations any custom types you have, the C code will have no idea it's calling into a D library.

Thanks for the example. It clarify things up. The druntime is just another dynamic library file I need to supply with my software. And I have interest in not statically linking it since the main program and the libraries will each need a copy of druntime.

So it's more the cross-compiling that could remain an issue, but it does not seem that much more complex than it currently is with gcc and mingw.

I guess I'll need to do some R&D for both D language and Raylib.


May 06, 2023

On Monday, 1 May 2023 at 16:57:39 UTC, Dadoum wrote:

>

On Sunday, 30 April 2023 at 17:51:15 UTC, Eric P626 wrote:

>

But how is this possible in a cross-compiling context. I am not sure if I can do that with the D language either as pure D or better C. DMD does not seem to offer cross compiling. GDC can compile better C, but not sure mingw can compile D/betterC code.

I build programs for macOS, iOS, Windows with ldc2 cross-compiling capabilities from my Linux computer, and the experience is okay, the executables are working fine but the set-up is a bit complicated, you need to copy files from the windows toolchain, copy your ldc config and edit it with some stuff, and do that at each ldc2 update.

If you just need cross-architecture, then gdc is a good option since it is compiled in a lot of cross compilation toolchains. However, I never managed to build a working gdc myself with ucrt or mingw cross-compilation capabilities, it always ends up with a compiler unable to link or executables that can't be executed on Windows.

Indeed, at DeepGlance we are cross-compiling and cross linking with LDC and LLVM ld.lld, from macOS to linux.

I'm interested in understanding if it's feasible to use importC with ffmpeg API and cross-compile and link them.

1 2
Next ›   Last »