Re: [Boost-users] thread no defined - issue

Hello Gavin, thanks for your replay and sorry for the delay. In the meantime I figured that I was on a wrong track. The code: #ifndef BOOST_THREAD_DEFINES_THREAD_ATTRIBUTES_NATIVE_HANDLE cout << "THREAD IS NOT DEFINED" << endl; #endif is triggered on any windows machine - also on the ones where everything is running perfectly fine. So probably the problem with this single user is maybe even not thread related - let's see ... Thanks for your help, which made me realize this. Best Alex -- http://www.carot.de Email : Alexander@Carot.de Tel.: +49 (0)177 5719797

Gesendet: Donnerstag, 15. September 2016 um 05:34 Uhr Von: "Gavin Lambert" An: boost-users@lists.boost.org Betreff: Re: [Boost-users] thread no defined - issue

On 10/09/2016 20:39, "Alexander Carôt" wrote:

...

...

How have you built boost and how your user has build boost? Which compile time flags are you using in your application and which is using your user? Are you defining BOOST_THREAD_POSIX

No, not at all: I am neither compiling boost with additional flags noram I defining anything in my sources.

The user simply runs a binary, which tells that threads are not available and hence does not work at all.

The code that you highlighted is based on a preprocessor symbol, so it is impossible for this to trigger on one machine and not another unless they are recompiling the sources rather than using a pre-built binary.

...

So - maybe this is where the problem starts: Should I explicitely compile boost with thread-support (or even pthread-support) ?

Boost should be compiled with thread support by default. This thread support might be native Windows rather than pthreads. Ideally, you should not care which of these are used, and should stick to the common Boost.Thread APIs that work on both.

So probably the code that you highlighted is checking the wrong thing, since it's looking for something pthreads-specific.

As I said before, the best thing to do is to change your code so that it's not pthreads-specific by removing use of native/pthreads APIs -- or failing that (if there's some reason you absolutely must use the native API for something), use a better method to identify whether pthreads or Windows threads are used and do the appropriate native thing in each case.

Always forcing use of pthreads is another option, but it's a less-good option. You might be able to get away with it for an application, but it's a very bad idea if you're making a library or something the user is expected to compile themselves.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users