Arghhh, DLLs broken on Win32 *again*! (page 2)

March 21, 2012

Re: [D-runtime] Arghhh, DLLs broken on Win32 *again*!

Posted by Walter Bright
in reply to Walter Bright

Permalink

Walter Bright

Posted in reply to Walter Bright

Permalink

I added them to the dmd test suite in a separate directory, with a runtests.sh to run them.

On 3/21/2012 10:29 AM, Walter Bright wrote:
> Nobody liked my .sh version of the win32 tests :-)
>
> On 3/21/2012 10:18 AM, Brad Roberts wrote:
>> You can run arbitrary .sh files, so anything can be scripted.
>>
>> On 3/21/2012 10:08 AM, Walter Bright wrote:
>>> The way to compile it doesn't fit into the test harness you created.
>>>
>>> On 3/21/2012 3:26 AM, Brad Roberts wrote:
>>>> Delegate away, but to someone who actually develops on windows.
>>>>
>>>> On 3/21/2012 2:53 AM, Walter Bright wrote:
>>>>> I was hoping to delegate!
>>>>>
>>>>> On 3/21/2012 2:19 AM, Brad Roberts wrote:
>>>>>> There should be nothing that prevents anyone from adding tests to the suite.  You don't need me to do it.  I don't do
>>>>>> windows code if I can avoid it.
>>>>>>
>>>>>
> _______________________________________________
> D-runtime mailing list
> D-runtime@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
>
>
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

> I'm running the same test suite for years for DLLs. No, it is not linking things twice. Historically, it breaks badly every time someone tweaks the druntime startup code. I've been able to run the tests but as before the test executable depend on the ModuleInfo, so compilation fails. Error 42: Symbol Undefined _D5mydll12__ModuleInfoZ DMD v2.059 DEBUG Digital Mars Import Library Manager Version 7.6B1n _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime

On Mar 21, 2012, at 10:10 AM, Walter Bright <walter@digitalmars.com> wrote: > > > On 3/21/2012 5:23 AM, dawg@dawgfoto.de wrote: >> >> >> You're apparently not referring to this HTML-unittest >> http://dlang.org/dll.html#Dcode. None of it compiles, >> but once it is made compiling it works. >> >> Start Dynamic Link... >> DLL_PROCESS_ATTACH >> static this for mydll >> Hello world! >> DLL_PROCESS_DETACH >> static ~this for mydll >> >> Please post a correct way to setup a Windows dmd-dev toolchain, how to run unittest... . >> >> test.d imports mydll.d and needs mydll's ModuleInfo, thus dynamic loading is not possible. Have you linked the module twice? >> > > I'm running the same test suite for years for DLLs. No, it is not linking things twice. Historically, it breaks badly every time someone tweaks the druntime startup code. Because it explicitly calls internal functions instead of Runtime.initialize or whatever. _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime

> Because it explicitly calls internal functions instead of Runtime.initialize or whatever. It does even worse hacks than that but the current point of failure is the gcstub.obj doesn't get updated automatically. _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime

On Mar 21, 2012, at 2:13 PM, dawg@dawgfoto.de wrote: >> Because it explicitly calls internal functions instead of Runtime.initialize or whatever. > > It does even worse hacks than that but the current point > of failure is the gcstub.obj doesn't get updated automatically. It's debatable whether gcstub is really needed for this anyway. All it provides is some space savings in the generated DLL, and in turn guarantees that the DLL can only be loaded by a D executable. I'd be more interested in generating DLLs that can be loaded by executables of any language, and so would leave out gcstub. _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime

> It's debatable whether gcstub is really needed for this anyway. All it provides is some space savings in the generated DLL, and in turn guarantees that the DLL can only be loaded by a D executable. I'd be more interested in generating DLLs that can be loaded by executables of any language, and so would leave out gcstub. The whole Windows DLL support is flawed. The only sensible way to maintain the ODR is to link against a shared runtime. With a statically linked runtime multiple D DLLs must remain isolated from each other. We recently had an addition to druntime that also got that wrong https://github.com/D-Programming-Language/druntime/pull/142. _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime

On 3/21/2012 3:09 PM, Martin Nowak wrote: >> It's debatable whether gcstub is really needed for this anyway. All it provides is some space savings in the generated DLL, and in turn guarantees that the DLL can only be loaded by a D executable. I'd be more interested in generating DLLs that can be loaded by executables of any language, and so would leave out gcstub. > > The whole Windows DLL support is flawed. > That may be, but until a better approach is made we must not break existing code. _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime

On 3/21/2012 1:19 PM, Sean Kelly wrote: > On Mar 21, 2012, at 10:10 AM, Walter Bright<walter@digitalmars.com> wrote: > >> I'm running the same test suite for years for DLLs. No, it is not linking things twice. Historically, it breaks badly every time someone tweaks the druntime startup code. > Because it explicitly calls internal functions instead of Runtime.initialize or whatever. > The documentation here: http://dlang.org/dll.html must work. The test cases, druntime, and the documentation must all be in sync. _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime

On Mar 21, 2012, at 3:49 PM, Walter Bright wrote: > > On 3/21/2012 1:19 PM, Sean Kelly wrote: >> On Mar 21, 2012, at 10:10 AM, Walter Bright<walter@digitalmars.com> wrote: >> >>> I'm running the same test suite for years for DLLs. No, it is not linking things twice. Historically, it breaks badly every time someone tweaks the druntime startup code. >> Because it explicitly calls internal functions instead of Runtime.initialize or whatever. >> > > The documentation here: > > http://dlang.org/dll.html > > must work. The test cases, druntime, and the documentation must all be in sync. My mistake, those docs are correct. I thought the test was based on the old design. _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime

> That may be, but until a better approach is made we must not break existing code. Yes, and the best approach is to nail it into the test suite. _______________________________________________ D-runtime mailing list D-runtime@puremagic.com http://lists.puremagic.com/mailman/listinfo/d-runtime

Forums