Installing on Windows 95 with Mingw32 1.1
Since I had quite a bit of trouble getting started with boost, I though i would document my difficulties so the install process can be improved and other users having similar difficulties might benefit from my experience. I have placed my story on the boost wiki in the topic InstallingOnMingw32Windows95 Direct url: http://www.crystalclearsoftware.com/cgi-bin/boost_ wiki/wiki.pl?InstallingOnMingw32Windows95 I hope this is helpful to somebody. -- Brad Karsjens
Brad - Thanks. I don't know how many users will benefit from your experience, but I'm sure someone will. This type of contribution is always appreciated! After reading your Wiki page, one thing I'm not entirely sure about is how much of what you have done should be factored back into boost build configurations so that this is easier for those that follow you. I suspect you are the first to try threading in this environment.... Jeff PS: About a year ago, I used boost/smart_ptr under mingw, but that was trivially simple b/c it didn't require any library compilation.
-----Original Message----- From: karsjens+yahoo@visionary.com [mailto:karsjens+yahoo@visionary.com] Sent: Friday, November 30, 2001 12:09 PM To: Boost-Users@yahoogroups.com Subject: [Boost-Users] Installing on Windows 95 with Mingw32 1.1
Since I had quite a bit of trouble getting started with boost, I though i would document my difficulties so the install process can be improved and other users having similar difficulties might benefit from my experience.
I have placed my story on the boost wiki in the topic InstallingOnMingw32Windows95
Direct url:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?InstallingOnM... 32Windows95
I hope this is helpful to somebody. -- Brad Karsjens
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). 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. 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. Bill Kempf
--- In Boost-Users@y..., williamkempf@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.
--- In Boost-Users@y..., williamkempf@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
--- In Boost-Users@y..., karsjens+yahoo@v... wrote: 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.
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,
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. 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.
Bill Kempf
I also want to say that I'm not trying to put down the threads
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. 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
participants (1)
-
Jeff Garland -
karsjens+yahoo＠visionary.com -
williamkempf＠hotmail.com