Re: Installing on Windows 95 with Mingw32 1.1

From: williamkempf_at_[hidden]
Date: 2001-11-30 17:01:55

--- In Boost-Users_at_y..., karsjens+yahoo_at_v... wrote:
> --- 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.

I'd expect you to get the same error.  As I say below, I know 
something is wrong when compiling with gcc.  I'm trying to figure out 
just what.

As for documentation, there is some in the tools\build directory.  A 
lot of people are working on improving this, and your Wiki page is 
probably helpful for those trying to document things, those working 
on the build tools and those just trying to build stuff today.

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

All of the complication is in the implementation of the DLL, not in 
its use.  Since it will need to be in a DLL for those trying to use 
Boost.Threads in their own DLLs, I'm just going to have to work 
through those complications.
 
> > 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.

Probably.  In fact, likely given what you say above and the fact that 
this all works flawlessly with VC++.  I'll do the research and get 
this one fixed as soon as I can.  The info you gave above may help me 
in trying to figure this out.  Thanks.

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

I got the command line gdb to run, but what a pain.  I'm researching 
both the GUI version as well as the JIT versions available for 
mingw.  They may help out.  However, the command line version just 
stranded me with no clear idea why things were failing, so I don't 
know if the other debuggers will be much help.
 
> > 
> > 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.

I didn't take any of this as criticism.  Even if I had, it would have 
been constructive criticism and well appreciated.  Your article was 
also an interesting read, and likely of a lot of help for a lot of 
people.

Bill Kempf