Boost.Thread fails to build on Cygwin

[Peter Dimov]

By default on Cygwin, the Boost.Thread headers choose the POSIX API. This decision is made in boost/thread/detail/platform.hpp:

#if defined(BOOST_THREAD_POSIX)
#  define BOOST_THREAD_PLATFORM_PTHREAD
#else
#  if defined(BOOST_THREAD_WIN32)
#       define BOOST_THREAD_PLATFORM_WIN32
#  elif defined(BOOST_HAS_PTHREADS)
#       define BOOST_THREAD_PLATFORM_PTHREAD
#  else
#       error "Sorry, no boost threads are available for this platform."
#  endif
#endif

In the Cygwin case, neither BOOST_THREAD_POSIX nor BOOST_THREAD_WIN32 appear to be defined, but BOOST_THREAD_CYGWIN, so the logic above chooses BOOST_THREAD_PLATFORM_PTHREAD.

This is actually correct, in my opinion; Cygwin is a POSIX platform.

However, the Jamfile by default chooses Win32 on Cygwin:

local rule default_threadapi ( )
{
    local api = pthread ;
    if [ os.name ] = "NT" { api = win32 ; }
    return $(api) ;
}

which later results in a bunch of errors when win32/thread.cpp is compiled against pthread/thread_data.hpp et al.

So, either the default in platform.hpp should be changed to Win32 under Cygwin, or (better) the default threadapi in the Jamfile should be changed to pthread under Cygwin.

Manually specifying threadapi=pthread is not a particularly good option, because Boost.Thread is a dependency of some tests, and when

b2 toolset=gcc,gcc-cxx11,clang,clang-cxx11,msvc-8.0,msvc-10.0,msvc-11.0,msvc-12.0

(for example) is invoked to test a library, threadapi=pthread is not possible.

[viboes]

I used to have a cygwin installation that worked. I'm unable to test it. I will see if Niall can do something. Niall?

[Niall Douglas]

Replying to viboes:

I used to have a cygwin installation that worked. I'm unable to test it. I will see if Niall can do something. Niall?

I had a sneaking suspicion you'd bump this onto me :)

I've actually been pretty ill last few days, the combination of medicines I was on unfortunately led to some poor choices of email to write as you may have noticed, so I deliberately have stayed away until the illness cleared and I no longer needed medicines. I intend to return to work tomorrow, albeit not at 100%.

I'll aim for next Saturday, though #9856 is before this in the queue. And, to be honest, that is a more important bug to fix than this in my opinion, so it may take some weeks.

Niall

[Peter Dimov]

Get well, Niall. I'll try to figure something out. Vicente, if you're on Windows, Cygwin is incredibly easy to install, you just run their setup.exe.

[Peter Dimov]

Nope, I couldn't figure anything out. :-) It's not possible to change the default value of the feature, because as I understand, in

b2 toolset=gcc,msvc-8.0

the default can't have two values at the same time. It's not possible to compile the Win32 sources under Cygwin, this results in errors. Perhaps it's possible to add <threadapi>pthread to the requirements for <toolset>gcc,<target-os>windows, but this would break MinGW. There are references to <target-os> being cygwin in gcc.jam, but it's not. <gcc:flavor> is mingw on MinGW, but not set on Cygwin.

[viboes]

Thanks Niall, and please, manage the priorities as you consider the best.

[Niall Douglas]

Replying to pdimov:

the default can't have two values at the same time. It's not possible to compile the Win32 sources under Cygwin, this results in errors. Perhaps it's possible to add <threadapi>pthread to the requirements for <toolset>gcc,<target-os>windows, but this would break MinGW. There are references to <target-os> being cygwin in gcc.jam, but it's not. <gcc:flavor> is mingw on MinGW, but not set on Cygwin.

Peter, my expectation for compiling under cygwin is that you would configure b2 as if it were Linux. That means WIN32 is *not* defined.

Cygwin isn't intended for compiling code that knows anything about Windows. I know it can be used as a "better than mingw", but to be honest since mingw-w64 came onto the scene it is neither a common use case nor a desirable one.

As a personal preference, I'd also like to drop mingw32 support as soon as it presents problems. Mingw-w64 is consuming all the development resources nowadays, and right now mingw32 latest is producing broken segfaulting binaries for AFIO at least. I'm currently intending to drop mingw32 support for the next AFIO release, I simply couldn't be bothered patching around it any more when mingw-w64 just works first time and every time.

BTW mingw-w64 also can produce 32 bit binaries. It is a total and much superior replacement for mingw32.

Niall

[viboes]

Hi Peter,

I'm on MacOS.

This used to work. I have not changed anything related to cygwin since a lot time.

Do you know of a bjam check that could identify cygwin?

[Peter Dimov]

No. See

​http://lists.boost.org/Archives/boost/2015/01/219408.php

for my unsuccessful attempts to add <threadapi>pthread on Cygwin.

[viboes]

Moved to Boost.Build in case them have some ideas.

[viboes]

Steve, do you have an idea?

[Steven Watanabe]

Use a conditional like this:

feature.feature threadapi : pthread win32 : optional propagated ;

rule choose-threadapi ( properties * )
{
    local result = [ property.select <threadapi> : $(properties) ] ;
    if $(result)
    {
        return $(result) ;
    }
    if <target-os>windows in $(properties)
    {
        return <threadapi>win32 ;
    }
    else
    {
        return <threadapi>pthreads ;
    }
}

Note that this depends on <target-os>cygwin being set correctly, but that isn't Boost.Thread's problem.

[Steven Watanabe]

As written this, of course, hits the "return doesn't really return" bug. It needs another else.