On Thursday, December 07, 2017 14:34:01 Timothee Cour via Digitalmars-d wrote:
> I have a simple test case to reproduce in
> https://issues.dlang.org/show_bug.cgi?id=18046
> this seems like a serious bug; what would be a workaround when dealing
> with shared libraries?

If you're trying to unit test a shared library, I'd suggest just turning it into a static library for the tests. Alternatively, you can write the unit tests in an application that links against the shared library, but that means separating the tests from the code, which isn't ideal.

- Jonathan M Davis

On 12/7/17 9:15 PM, Jonathan M Davis wrote:
> On Thursday, December 07, 2017 14:34:01 Timothee Cour via Digitalmars-d
> wrote:
>> I have a simple test case to reproduce in
>> https://issues.dlang.org/show_bug.cgi?id=18046
>> this seems like a serious bug; what would be a workaround when dealing
>> with shared libraries?
> 
> If you're trying to unit test a shared library, I'd suggest just turning it
> into a static library for the tests. Alternatively, you can write the unit
> tests in an application that links against the shared library, but that
> means separating the tests from the code, which isn't ideal.

I think you misunderstand. If there is a shared library being linked against, then the tests in your application don't run (see the bug report). Definitely a serious bug. I would be interested how they work on Linux with shared libraries, maybe it's a mac thing.

I think this has to do with which library initializes the runtime first.

However, I think this is supposed to work, as the code clearly has references to dealing with multiple sections of moduleinfo.

-Steve

On 2017-12-08 16:45, Steven Schveighoffer wrote:

> I would be interested how they work on Linux with shared libraries, maybe it's a mac thing.

Well, shared libraries are not officially support on macOS.

-- 
/Jacob Carlborg

On Friday, 8 December 2017 at 16:17:14 UTC, Jacob Carlborg wrote:
> Well, shared libraries are not officially support on macOS.

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).

But yes, you can't really expect any sort of runtime infrastructure to work with shared libraries on DMD/macOS right now.

 -David

On Friday, December 08, 2017 10:45:29 Steven Schveighoffer via Digitalmars-d wrote:
> On 12/7/17 9:15 PM, Jonathan M Davis wrote:
> > On Thursday, December 07, 2017 14:34:01 Timothee Cour via Digitalmars-d
> >
> > wrote:
> >> I have a simple test case to reproduce in
> >> https://issues.dlang.org/show_bug.cgi?id=18046
> >> this seems like a serious bug; what would be a workaround when dealing
> >> with shared libraries?
> >
> > If you're trying to unit test a shared library, I'd suggest just turning it into a static library for the tests. Alternatively, you can write the unit tests in an application that links against the shared library, but that means separating the tests from the code, which isn't ideal.
>
> I think you misunderstand. If there is a shared library being linked against, then the tests in your application don't run (see the bug report). Definitely a serious bug. I would be interested how they work on Linux with shared libraries, maybe it's a mac thing.

Ah. I did misunderstand then. Yeah, that would be a big problem, and I don't know how you'd work around that except not using shared libraries for the unit test build, which may or may not be possible.

- Jonathan M Davis

>> 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!

>> But yes, you can't really expect any sort of runtime infrastructure to work with shared libraries on DMD/macOS right now.

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.



On Fri, Dec 8, 2017 at 3:55 PM, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, December 08, 2017 10:45:29 Steven Schveighoffer via Digitalmars-d wrote:
>> On 12/7/17 9:15 PM, Jonathan M Davis wrote:
>> > On Thursday, December 07, 2017 14:34:01 Timothee Cour via Digitalmars-d
>> >
>> > wrote:
>> >> I have a simple test case to reproduce in
>> >> https://issues.dlang.org/show_bug.cgi?id=18046
>> >> this seems like a serious bug; what would be a workaround when dealing
>> >> with shared libraries?
>> >
>> > If you're trying to unit test a shared library, I'd suggest just turning it into a static library for the tests. Alternatively, you can write the unit tests in an application that links against the shared library, but that means separating the tests from the code, which isn't ideal.
>>
>> I think you misunderstand. If there is a shared library being linked against, then the tests in your application don't run (see the bug report). Definitely a serious bug. I would be interested how they work on Linux with shared libraries, maybe it's a mac thing.
>
> Ah. I did misunderstand then. Yeah, that would be a big problem, and I don't know how you'd work around that except not using shared libraries for the unit test build, which may or may not be possible.
>
> - Jonathan M Davis
>

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