I've been trying to make DWT do something useful, and I've run into a rather harsh snag.

As far as I can figure, under some extremely bizzare conditions, among them the inclusion of the /CO link switch, the std.thread.Thread static constructor is not called.

The problem seems unwilling to be nailed down, so failing that, I've set up a self-contained demo at <http://andy.tadan.us/d/crasho.zip>

Building HelloDWT.exe with the commandline:

    dmd HelloDWT.obj advapi32.lib comctl32.lib comdlg32.lib dwt.lib gdi32.lib imm32.lib kernel32.lib msimg32.lib shell32.lib user32.lib

Produces a working executable. (actually, it doesn't work at all, but the static constructor is called as it should be)

Note that since everything is a .obj or a .lib, all DMD does is call link.exe.  Adding -g just causes DMD to pass /CO on to the linker.  This is the kicker: The resultant executable crashes when Thread.getThis() is called, as the static constructor is mysteriously ignored.

Further, creating a copy of std.thread within the source tree and using that instead causes the problem to go away.

If it "works," the test program will dump a few numbers to the console before crashing. :)

 -- andy

Andy; the link you provided is broken. Also, I posted briefly on dsource.org regarding this - may perhaps be of some use.


"Andy Friesen" <andy@ikagames.com> wrote in message news:cg6p3m$1c7a$1@digitaldaemon.com...
> I've been trying to make DWT do something useful, and I've run into a rather harsh snag.
>
> As far as I can figure, under some extremely bizzare conditions, among them the inclusion of the /CO link switch, the std.thread.Thread static constructor is not called.
>
> The problem seems unwilling to be nailed down, so failing that, I've set up a self-contained demo at <http://andy.tadan.us/d/crasho.zip>
>
> Building HelloDWT.exe with the commandline:
>
>      dmd HelloDWT.obj advapi32.lib comctl32.lib comdlg32.lib dwt.lib
> gdi32.lib imm32.lib kernel32.lib msimg32.lib shell32.lib user32.lib
>
> Produces a working executable. (actually, it doesn't work at all, but the static constructor is called as it should be)
>
> Note that since everything is a .obj or a .lib, all DMD does is call link.exe.  Adding -g just causes DMD to pass /CO on to the linker.  This is the kicker: The resultant executable crashes when Thread.getThis() is called, as the static constructor is mysteriously ignored.
>
> Further, creating a copy of std.thread within the source tree and using that instead causes the problem to go away.
>
> If it "works," the test program will dump a few numbers to the console before crashing. :)
>
>   -- andy

antiAlias wrote:
> Andy; the link you provided is broken. Also, I posted briefly on dsource.org
> regarding this - may perhaps be of some use.

oops.  Link fixed.

Also yeah, thanks for the advice. :)

I found that tossing a second copy of thread.d into the library was the easiest way to go: it works no matter what order things are built in. (this is a terrible long-term solution, of course, but I'm hoping it won't come to that...)

 -- andy

It sounds like nothing in std.thread is actually being referred to by the .obj file, hence it doesn't get linked in, hence the failure of the static constructor to run.

"Andy Friesen" <andy@ikagames.com> wrote in message news:cg6p3m$1c7a$1@digitaldaemon.com...
> I've been trying to make DWT do something useful, and I've run into a rather harsh snag.
>
> As far as I can figure, under some extremely bizzare conditions, among them the inclusion of the /CO link switch, the std.thread.Thread static constructor is not called.
>
> The problem seems unwilling to be nailed down, so failing that, I've set up a self-contained demo at <http://andy.tadan.us/d/crasho.zip>
>
> Building HelloDWT.exe with the commandline:
>
>      dmd HelloDWT.obj advapi32.lib comctl32.lib comdlg32.lib dwt.lib
> gdi32.lib imm32.lib kernel32.lib msimg32.lib shell32.lib user32.lib
>
> Produces a working executable. (actually, it doesn't work at all, but the static constructor is called as it should be)
>
> Note that since everything is a .obj or a .lib, all DMD does is call link.exe.  Adding -g just causes DMD to pass /CO on to the linker.  This is the kicker: The resultant executable crashes when Thread.getThis() is called, as the static constructor is mysteriously ignored.
>
> Further, creating a copy of std.thread within the source tree and using that instead causes the problem to go away.
>
> If it "works," the test program will dump a few numbers to the console before crashing. :)
>
>   -- andy

Walter wrote:

> It sounds like nothing in std.thread is actually being referred to by the
> .obj file, hence it doesn't get linked in, hence the failure of the static
> constructor to run.
> 

I'm a bit more inclined to believe that the linker has gotten a bit confused. :)

The first few lines of main() are as follows:

    import std.thread;

    int main() {
        printf("Current thread:\n");
        Thread t = Thread.getThis();
        printf("\t%p\n", t);
        ....
    }

 -- andy

"Walter" <newshound@digitalmars.com> wrote in message
> It sounds like nothing in std.thread is actually being referred to by the .obj file, hence it doesn't get linked in, hence the failure of the static constructor to run.

There are times when the static constructors are simply not invoked. I've seen the same thing a half-dozen times with Mango. I don't know how it happens, but it's generally fatal to the application.

I should have noted that my issues were subtly different from Andy's ~ where Andy was importing Thread.d from the Phobos library, my issues were all with directly compiled D modules. I'd speculate that it's the same bug, but an alternate manifestation.

Note that at least Andy's example is pretty small; I never did manage to whittle down the issue to a small test case regarding Mango.


"antiAlias" <fu@bar.com> wrote in message news:cg8582$29gm$1@digitaldaemon.com...
> "Walter" <newshound@digitalmars.com> wrote in message
> > It sounds like nothing in std.thread is actually being referred to by
the
> > .obj file, hence it doesn't get linked in, hence the failure of the
static
> > constructor to run.
>
> There are times when the static constructors are simply not invoked. I've seen the same thing a half-dozen times with Mango. I don't know how it happens, but it's generally fatal to the application.
>
>

Under Win32 or linux?

"antiAlias" <fu@bar.com> wrote in message news:cg85va$29pb$1@digitaldaemon.com...
> I should have noted that my issues were subtly different from Andy's ~
where
> Andy was importing Thread.d from the Phobos library, my issues were all
with
> directly compiled D modules. I'd speculate that it's the same bug, but an alternate manifestation.
>
> Note that at least Andy's example is pretty small; I never did manage to whittle down the issue to a small test case regarding Mango.
>
>
> "antiAlias" <fu@bar.com> wrote in message news:cg8582$29gm$1@digitaldaemon.com...
> > "Walter" <newshound@digitalmars.com> wrote in message
> > > It sounds like nothing in std.thread is actually being referred to by
> the
> > > .obj file, hence it doesn't get linked in, hence the failure of the
> static
> > > constructor to run.
> >
> > There are times when the static constructors are simply not invoked.
I've
> > seen the same thing a half-dozen times with Mango. I don't know how it happens, but it's generally fatal to the application.
> >
> >
>
>

Win32 ... those builds were never tried on linux.

"Walter" <newshound@digitalmars.com> wrote in message news:cg9ihh$552$2@digitaldaemon.com...
> Under Win32 or linux?
>
> "antiAlias" <fu@bar.com> wrote in message news:cg85va$29pb$1@digitaldaemon.com...
> > I should have noted that my issues were subtly different from Andy's ~
> where
> > Andy was importing Thread.d from the Phobos library, my issues were all
> with
> > directly compiled D modules. I'd speculate that it's the same bug, but
an
> > alternate manifestation.
> >
> > Note that at least Andy's example is pretty small; I never did manage to whittle down the issue to a small test case regarding Mango.
> >
> >
> > "antiAlias" <fu@bar.com> wrote in message news:cg8582$29gm$1@digitaldaemon.com...
> > > "Walter" <newshound@digitalmars.com> wrote in message
> > > > It sounds like nothing in std.thread is actually being referred to
by
> > the
> > > > .obj file, hence it doesn't get linked in, hence the failure of the
> > static
> > > > constructor to run.
> > >
> > > There are times when the static constructors are simply not invoked.
> I've
> > > seen the same thing a half-dozen times with Mango. I don't know how it happens, but it's generally fatal to the application.
> > >
> > >
> >
> >
>
>