On Tuesday, 10 May 2016 at 14:35:17 UTC, krzaq wrote:
On Tuesday, 10 May 2016 at 14:26:27 UTC, Vladimir Panteleev
wrote:
On Tuesday, 10 May 2016 at 14:19:15 UTC, krzaq wrote:
On Sunday, 8 May 2016 at 13:31:46 UTC, Vladimir Panteleev
wrote:
On Sunday, 8 May 2016 at 09:43:14 UTC, Steven Schveighoffer
wrote:
[...]
I understand that this is no longer a problem. We link
dynamically to the DLL, which is distributed with DMD, and
it's lazy-loaded (so we don't do anything at all until the
first std.net.curl function is called).
That could lead to some nasty surprises when distributing a
binary. I'd rather hear my customer say "I can't start your
program, because some .dll is missing" than "it randomly
crashes / doesn't work".
You imply that the error message that Druntime generates when
it cannot find the DLL is significantly worse than the error
message that the OS generates when it cannot find the DLL.
Even if it's better, it's significantly *later*. Once my code
runs in a production environment I'd really prefer it to not to
stop over things that could've easily been prevented.
You can actually still statically link libcurl to the executable
if you so desire.
Regardless, I'm not sure that we should worry much about the
particular case where you 1) link to libcurl dynamically 2)
distribute an incomplete application with some DLLs missing and
3) use libcurl late during your application's runtime.