On Saturday, 29 September 2012 at 13:19:01 UTC, Jacob Carlborg
wrote:
That's a fairly uninteresting test.
I am not a D developer which means I have no incentive in blindly
portraying D as a language having shared libraries support when
in fact it has some issues. I am a D user which has incentive to
gladly report which part of D does work (or seems to work) and
which doesn't when making shared libraries.
You are linking to the dynamic library. What's interesting is
loading a dynamic library using dlopen, or similar. What's the
point of using dynamic libraries if you're linking with them?
I was not taking about dynamic loading, but about dynamic
linking. If I understand topic right, the issue is the former,
not the latter.
BTW, in majority cases dynamic loading gives no advantages over
dynamic linking (just the opposite: doing unnecessary job which
can be done by linker and loader). In most cases, when an app is
being written, it is known which functional from which
third-party libraries would be used. The only exceptions I can
name are pluggin support and hacker's binary ELF/PE tools. I can
count few apps in windows and linux which are used often, which
dynamically load something, and if they do, they likely load
pluggins. This was made for cases when app developers by
definition cannot know beforehand full list of used shared
libraries. So, the question is just opposite: "What's the point
of using dynamic loading if you know beforehand which libraries
you use, which happens almost in all cases?".
But I certainly agree that dynamic loading is essential for some
applications, if not irreplaceable, and support of it also needed
to be inspected and improved.
