Modify

Opened 3 years ago

Last modified 2 years ago

#10942 new Bugs

Boost.Thread fails to build on Cygwin

Reported by: Peter Dimov Owned by: Steven Watanabe
Milestone: To Be Determined Component: build
Version: Boost 1.57.0 Severity: Problem
Keywords: Cc:

Description

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.

Attachments (0)

Change History (13)

comment:1 Changed 3 years ago by Peter Dimov

Owner: changed from Anthony Williams to viboes

comment:2 Changed 3 years ago by viboes

Owner: changed from viboes to Niall Douglas

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

comment:3 in reply to:  2 Changed 3 years ago by 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

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by 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.

comment:6 Changed 3 years ago by viboes

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

comment:7 in reply to:  5 Changed 3 years ago by 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

comment:8 Changed 3 years ago by 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?

Last edited 3 years ago by viboes (previous) (diff)

comment:9 Changed 3 years ago by Peter Dimov

No. See

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

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

comment:10 Changed 2 years ago by viboes

Component: threadbuild

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

comment:11 Changed 2 years ago by viboes

Owner: changed from Niall Douglas to Steven Watanabe

Steve, do you have an idea?

comment:12 Changed 2 years ago by 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.

comment:13 Changed 2 years ago by Steven Watanabe

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain Steven Watanabe.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.