• Andy Friesen (21/21) Aug 20 2004 I've been trying to make DWT do something useful, and I've run into a
• antiAlias (4/25) Aug 20 2004 Andy; the link you provided is broken. Also, I posted briefly on dsource...
• Andy Friesen (8/10) Aug 21 2004 oops. Link fixed.
• Walter (5/26) Aug 21 2004 It sounds like nothing in std.thread is actually being referred to by th...
• Andy Friesen (12/16) Aug 21 2004 I'm a bit more inclined to believe that the linker has gotten a bit
• antiAlias (4/7) Aug 21 2004 There are times when the static constructors are simply not invoked. I'v...
• antiAlias (10/17) Aug 21 2004 I should have noted that my issues were subtly different from Andy's ~ w...
• Walter (6/26) Aug 22 2004 Under Win32 or linux?
• antiAlias (5/36) Aug 22 2004 Win32 ... those builds were never tried on linux.

Andy Friesen <andy ikagames.com> writes:

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" <fu bar.com> writes:

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

Andy Friesen <andy ikagames.com> writes:

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

"Walter" <newshound digitalmars.com> writes:

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

Andy Friesen <andy ikagames.com> writes:

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

"antiAlias" <fu bar.com> writes:

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

"antiAlias" <fu bar.com> writes:

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.

"Walter" <newshound digitalmars.com> writes:

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.

"antiAlias" <fu bar.com> writes:

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.