Re: [Boost-users] help needed picking up pthread.h with Visual Studio .NET 2003

boost-users-bounces@lists.boost.org wrote:
Andrew Marlow wrote:
1) Building the boost library on top of pthread instead of native WinThreads?
Yes. Once the boost libs (and a few examples) have built ok I will then release these as prebuilts.
Sorry this does not make sense to me, as this would imply your project will be using the boost library: Boost.Thread.
Yes it will.
So normally you wouldn't want to have them use the pthread implementation in turn.
Things are not normal here. My app has to use an in-house lib that was coded using pthreads. When that lib had to be available on windoze they did it by using the win32 port of pthreads. My app has to use this in-house lib, hence I have to link with the win32 port of pthreads. But I also want to do my own threading. I want to do it in a platform-independent way so I choose boost threads.
The only exception I can think of is when you are doing some performance testing.
Nope.
Usually the Boost.Thread on native windows API will be faster than on top of pthreads, since there is one emulation layer less.
Agreed. And if it was not for the in-house lib being built on the win32 port of pthreads then we would probably use boost threads throughout with a default build that uses the win32 api. But that is not an option. We do not want any apps to contain a mixture of win32 pthreads and win32 API threads.
I will have to do this for a number of versions of Visual Studio. Then for VC71 I will use the prebuilt boost lib to build my own project. It will be developed using the VC71 IDE but will be built overnight by a perl script that uses msdev in command line mode. This overnight job will not build boost, it will pick up the boost prebuilt.
So I assume you are attempting to build the boost library?
Yes, but I want to build it with a version of the win32 port of pthreads that lives in a special (non-std place).
If so, simply read the getting started from the boost homepage and then precompiler your library, which basically has to be done from the boost root directory: bjam -s"TOOLS=vc-7_1" install which will install to C:\Boost directory by default. (The above is for version 1.33, upcoming 1.34 is different. )
I don't think that works. I already tried it and it builds to the WIN32 API, not to the win32 port of pthreads that I have.
As an alternative you might also download the prebuilt binary versions of the lib.
I thought of that, but that won't work either. The boost that I wind up with MUST be one that is built wrt the win32 port of pthreads that comes with this in-house lib. Even if there was a prebuilt version of boost built with the win32 port of pthread even that would not do. It must be the particular version of the win32 port of pthreads that the in-house lib was built with. Wot a pain, eh? -Andrew M. ******************************************************************************" The data and information (collectively called Information) herein is the sole property of ICAP. The Information is confidential, may be legally privileged and is intended solely for the use of the individual or entity to whom it is addressed. Unauthorised disclosure, copying or distribution of the Information is strictly prohibited and the recipient of the Information shall not redistribute the Information in any form to a third party. If you received this Information in error please tell us by reply (or telephone the sender) and delete all copies on your system. References in this Information to ICAP are references to ICAP plc, a company incorporated in England with registered number 3611426 whose registered office is 2 Broadgate, London, EC2M 7UR and where the context requires, includes its subsidiary and associated undertakings. As applicable, certain companies within the ICAP group are authorised and regulated by the Financial Services Authority. Any investment research sent from ICAP will provide an impartial and objective assessment of the securities, companies or other matters that are the subject of their research and our Conflicts of Interest Management Policy regarding investment research can be viewed by requesting a copy from your usual contact at ICAP. Please visit www.icap.com for further regulatory information including details regarding the European eCommerce Directive. *******************************************************************************" We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. " *******************************************************************************

Andrew Marlow wrote:
Things are not normal here. My app has to use an in-house lib that was coded using pthreads. When that lib had to be available on windoze they did it by using the win32 port of pthreads. My app has to use this in-house lib, hence I have to link with the win32 port of pthreads. But I also want to do my own threading. I want to do it in a platform-independent way so I choose boost threads.
Ok the mist is rasing ;-) There should be no problem mixing pthread and Boost.Thread. I.e. your inherited lib can use pthread while your new code can use Boost.Thread on the native API. But if on the other hand for whatever reason you want to take the additional (IMHO unnecessary step) to build boost thread on top of pthread you can. Here is how we go: Open the file BOOST_ROOT/libs/thread/build/threads.jam Follow the instructions found there and set up your environment variables accordingly. Then build the library as usual. You will find an additional library in C:\Boost\lib which has the ptw32 tag in it. Link your final executables with this library instead of the one without the tag. This should do it. Again the whole mess isn't worth doing it. And then you should not need to fiddle around with the configure. You need not have BOOST_HAS_PTHREAD defined. This in your case is an internal detail. Roland
participants (2)
-
Andrew Marlow
-
Roland Schwarz