On 05/12/2013 21:01, Jacob Carlborg wrote:
On 2013-11-29 13:26, Bruno Medeiros wrote:
I noticed the thread but didn't look into it, it is too big. I just took
a quick glance at some of the posts. I reckon there's issues with
regards to how the Curl lib links to libc and other dependency
libraries, is that it?Actually no. Although that could be another problem. In this case it's
because libcurl on Debian has different symbol names from libcurl on
other distributions. On Debian the SSL implementation, OpenSSL or Gnu
TLS, is mangled in the symbol names. That's not the case on Fedora.Yeah, that kind of stuff - interactions between the C libs themselves -
makes it very complicated for us to ship (and maintain) dub-packages
wrapping C libraries. But still I think the alternative seems just as
bad, if not worse.What about an intermediate approach for Dub, where a Dub package could
check in a sane way if it is possible to link against a certain C
library (for example, trying to compile and run a dummy internal
project)? And the dub package wrapper would be just that. It would fail
in a sane way, but it wouldn't actually try to install the library.How does Python deal with this BTW, anyone familiar? I think Python is
interesting to look at because it has binding to a lot of C-libraries,
so it must have encountered the same problem.I don't know about Python but Ruby just assumes the native library is
available in the standard paths. Although Ruby builds the bindings when
installing the gem, so you won't have that problem at least.
If I recall correctly from my short experience trying to run a Python
script that had quite a few dependencies, I think it was the same with
Python. The Python package manager would automatically install all the
bindings for the required deps, but otherwise it would assume the native
libraries would be available to the standard compiler.