-unittest doesn't work when linking against shared libraries

[David Nadlinger]

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