Boost C++ Libraries: Ticket #10942: Boost.Thread fails to build on Cygwin

owner changed

Peter Dimov — Sun, 18 Jan 2015 19:12:09 GMT

owner changed from Anthony Williams to viboes

owner changed

viboes — Sun, 18 Jan 2015 21:47:49 GMT

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?

Niall Douglas — Mon, 19 Jan 2015 00:59:11 GMT

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 — Mon, 19 Jan 2015 02:09:30 GMT

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 — Mon, 19 Jan 2015 03:23:23 GMT

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 — Mon, 19 Jan 2015 07:46:54 GMT

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

Niall Douglas — Tue, 20 Jan 2015 23:48:40 GMT

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 — Thu, 19 Feb 2015 08:31:32 GMT

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 — Thu, 19 Feb 2015 13:22:02 GMT

No. See

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

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

component changed

viboes — Sat, 04 Apr 2015 21:45:28 GMT

component thread → build

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

owner changed

viboes — Sat, 04 Apr 2015 21:46:11 GMT

owner changed from Niall Douglas to Steven Watanabe

Steve, do you have an idea?

Steven Watanabe — Sat, 04 Apr 2015 22:46:56 GMT

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 — Sat, 04 Apr 2015 22:53:40 GMT

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