On Saturday, 9 December 2017 at 00:32:36 UTC, Timothee Cour wrote:
They are on LDC; would be interesting to see whether the
problem occurs there as well (I'm having issues with my Mac
right now, so can't check myself until later).
just updated bug report: same issue with ldc!
Only if not linking against the shared runtime libraries, which
is always required to get shared library support in LDC. (We
should probably figure out a way to warn about this.)
a lot of things work with shared libraries on OSX, it would be
great if this worked too. It's not because shared libraries are
not 100% fully officially supported that we should ignore this
issue. Certain use cases are impossible without using shared
libraries.
Solution: Use LDC and be happy. ;)
As far as partial support goes, you can't really build parts of a
house without pouring the foundation first. Unit test support is
one of the "upper storey" language niceties without too many
cross-dependencies, but it builds on the underlying runtime
machinery. Are you sure your program can work sensibly when the
GC starts collecting random live objects? Or thread-local storage
doesn't work from shared libraries? When module constructors
aren't run? Do your tests comprehensively detect any sporadic
issues with these?
If you find any dylib-related bugs in LDC, it will be easily
possible to fix them, since all the groundwork is in place. But
you can't expect to paper over a hole in the floor and then
continue to build on top of that; that is to just hack unit test
support into DMD in a sensible fashion without supporting the
rest of it.
(Feel free to just port "my" LDC/macOS implementation to DMD,
though; the hardest work has already been done, especially given
Jacob's (?) recent work on native TLS for DMD.)
—David
