On Monday, 19 December 2016 at 20:05:20 UTC, Ilya Yaroshenko
wrote:
What about other non Mir numerical library written in Dlang,
say for FFT?
How they should be linked together.
If Mir libs are static libs this can indeed be a problem.
If someone has made another D library like this, it will either
have to be its own dynlib or come with a runtime with the same
API. You can manage to use very little of druntime such as
"emplace"/"destroy" and that's about it when it comes to API.
I'll concede that my solution will not get you packaged on
official package lists for Debian/Ubuntu, because shared
libraries will get preferred there.
But I just checked and libcublas is just put in the non-free
packages.
https://packages.debian.org/jessie/libcublas6.0
If it's good enough for CUDA then maybe it's good enough for MIR?
Note that with MIR being several dynlibs everyone of Mir library
can come with any runtime (and then use it or not) without
interaction of these runtimes.
When you use a CUDA dynamic library you don't know if it has a C
runtime inside (or a X runtime, whatever).
Do you propose to constraint Dlang library distribution in
binary form?
No. Not sure how that question ensues from the premises.
