Re: Installing on Windows 95 with Mingw32 1.1

From: karsjens+yahoo_at_[hidden]
Date: 2001-11-30 16:48:15

--- In Boost-Users_at_y..., williamkempf_at_h... wrote:
> I've just gotten a chance to read the page.  I won't comment much
on 
> the build process, but since your focus was on using Boost.Threads 
> I'll make a few comments there.
> 
> First, you can run the regression test using Jam instead of
manually 
> running gcc.  Just cd into the test directory and type your typical 
> Jam command (hint, if you create a batch file to set your
environment 
> right the entire command can be just "Jam").  This should build the 
> executable and run it.  The benefit to this approach is that 
> it "automagically" locates and uses the DLL.  This can be helpful 
> when debugging.  However, to use the actual debugger, unless it 
> supports JIT Debugging, you'll have to go back to manually insuring 
> everything is set up for this (i.e. copy the DLL as you did).

Okay, I figured out how to do this, and I get the same error.  When I
was looking for documentation on how to use jam, there wasn't much
available on the boost site.  I realize that jam is not originally
from boost, but a 'using jam with boost' might be an appropriate
subtopic on the installation page.  If nothing else, it could list
possible targets.  It's not a big deal, though -- I'm just moaning
about lack of documentation and since I'm a developer, I know when
that job usually gets done.

> 
> You asked in your paper why there needs to be a DLL. 
Unfortunately, 
> this is the only way to clean up thread specific storage on Win32.  
> I'm working on putting all of Boost.Threads in a DLL which will at 
> least be more intuitive for most users.

Okay, I guess I understand this.  The destructors have to run
sometime.  However, I think it might be a mistake to put everything in
a DLL, since DLLs are inherently more complicated to get right.  As it
is, even though I currently can't get the DLL part to work right, I
can still use boost.threads without it.  I don't like thread-specific
storage, so I tend to design it out.

> 
> As for the segfault...  I've experienced the same problem using
gcc.  
> Not being a gcc user I'm finding it difficult to debug to figure
out 
> why.  If you or anyone else can either give me pointers on
debugging 
> for gcc or even just supply the fix I'd be eternally grateful ;). 
In 
> any event, I'm working on this one.

I actually think the segfault might be in just calling the DLL.  I
reduced the DLL to basically nothing (returning immediately from
DLLMain), and didn't call any of the thread-specific stuff (basically
test_thread.cpp without calling test_tss(), so it was still linked
in), and still got the pagefault.  It may simply be a gcc issue, like
the -mthreads switch.

I'm certainly willing to help debug.  Unfortunately, my debugging
efforts in c++ are currently limited to printf-style debugging.  I'll
get gdb going (and learn it a bit better) someday.

> 
> Bill Kempf

I also want to say that I'm not trying to put down the threads library
or boost.  My goal with the article was a real-life user experience
that will hopefully improve future user's experiences.  I like what I
see of boost so far.