[Issue 15391] Problems loading libcurl.so and running datetime unittest on NixOS package build

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15391

--- Comment #7 from Thomas Mader <thomas.mader at gmail.com> ---
(In reply to Martin Nowak from comment #5)
> (In reply to Thomas Mader from comment #3)
> > I was able to hack around the issue by patching the curl.d sourcefile.
> > 
> >       #Ugly hack so the dlopen call has a chance to succeed.
> >       substituteInPlace src/phobos/std/net/curl.d --replace libcurl.so
> > ${curl}/lib/libcurl.so
> > 
> > 
> > That's in the package description for the dmd package on NixOS. That's
> > necessary because in NixOS every package is stored in isolation to
> > everything else.
> > So libcurl on my system resides in
> > /nix/store/v5a69m1b823zm1yy8yvhrd2zi2w385b1-curl-7.44.0/lib/libcurl.so.
> 
> Maybe try to  LD_LIBRARY_PATH instead?
> As mentioned here
> https://dlang.org/changelog/2.069.0.html#curl-dynamic-loading you can also
> link against libcurl (make sure to use no-as-needed), then the symbols will
> get loaded from your executable.

The LD_LIBRARY_PATH solution isn't viable for NixOS and even if the libcurl
linking is solved, two issues remain. (Path to zoneinfo and using gcc's linker)

I think I need to explain the idea of NixOS a little bit. Since I am new to
NixOS I am not the perfect candidate to explain in detail. Therefore it's
better to read
https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansible-arent-good-enough-and-we-can-do-better/
for a brief overview and the reasoning behind the NixOS idea.

I see the patching I need to do now to package dmd on NixOS as a Hack. There
needs to be a better solution.
Wouldn't it be reasonable to provide a way to define the exact path to every
external dependency?
I thought about optional Makefile arguments to set the paths which are
propageted into the build as compiler switches?
If it is considered a viable solution, I could even try to do a PR.

--