Package Details: mingw-w64-boost 1.70.0-1

Git Clone URL: (read-only)
Package Base: mingw-w64-boost
Description: Free peer-reviewed portable C++ source libraries (mingw-w64)
Upstream URL:
Licenses: custom
Submitter: ekpyron
Maintainer: xantares
Last Packager: xantares
Votes: 21
Popularity: 0.917186
First Submitted: 2012-03-22 18:46
Last Updated: 2019-04-13 05:37

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 Next › Last »

xantares commented on 2014-04-12 17:07

ok, thanks for the explanation.

ekpyron commented on 2014-04-11 17:53

@hauzer: I agree - I guess usually the multithreaded libraries will be sufficient and IMHO the build takes long enough as it is, so I tend to stay with threading=multi, unless there is a really good reason not to

ekpyron commented on 2014-04-11 17:51

@hauzer: I would agree - I think usually the multithreaded libraries will be sufficient and the build takes long enough as it is, so I tend to stay with threading=multi

hauzer commented on 2014-04-11 16:06

Oh, I forgot about shared libraries. Make that four additional sets.

hauzer commented on 2014-04-11 16:04

@xantares, @ekpyron: Adding threading=single to the current configuration will produce two additional sets of the library, taking this package twice longer to build. If someone wants Boost without multithreading safety, changing the PKGBUILD is just an edit away.

ekpyron commented on 2014-04-11 15:54

threading=multi just causes thread-safe libraries to be built - I'm not sure whether there is any point in changing that to threading=single,multi.

threadapi=win32 makes boost use the native windows threading api instead of trying to use pthreads - neither of those choices are "correct" per se.

As far as I understand it, the naming conventions for the boost libraries allow for different suffixes and it is the responsibility of the package to support all possible combinations...

At the moment I see no reason to mimic fedora packages and would prefer staying with the native windows threading api, but if there are a lot of issues with the current configuration that can be solved by changing to pthreads and single- and multi-threaded libraries, I will consider making these adjustments.

xantares commented on 2014-04-11 13:49

Boost is not configured like in the fedora packages
instead you do
threading=multi threadapi=win32
which one is correct ?
It has an impact on the component name, which becomes thread_win insted of thread on fedora (libboost_thread-mt.dll), and some packages fail to build.

hauzer commented on 2014-04-03 03:31

I've made a mingw-w64-boost-python package (, which complements this one.

ekpyron commented on 2014-01-21 14:24

Sorry for the late reply. Have a look at the comments in the beginning of FindBoost.cmake. It says:

# Boost libraries come in many variants encoded in their file name. Users or
# projects may tell this module which variant to find by setting variables:
# Boost_THREADAPI - Suffix for "thread" component library name,
# such as "pthread" or "win32". Names with
# and without this suffix will both be tried.

So if you want FindBoost.cmake to find the thread library, just set Boost_THREADAPI to win32 and it should work (e.g. by invoking cmake with the additional command line argument "-DBoost_THREADAPI=win32").

Consequently I don't think that the libraries should be renamed, as someone might want to have a separate package providing a pthread version of the library or something similar.

gchatelet commented on 2013-12-29 15:20

Because of 'threadapi=win32' the threading libraries are named

instead of

This makes cmake FindBoost.cmake fail.
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for THREAD_LIBRARY_RELEASE: boost_thread-gcc47-mt-1_55;boost_thread-gcc47-mt;boost_thread-mt-1_55;boost_thread-mt;boost_thread
-- [ /usr/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for THREAD_LIBRARY_DEBUG: boost_thread-gcc47-mt-d-1_55;boost_thread-gcc47-mt-d;boost_thread-mt-d-1_55;boost_thread-mt-d;boost_thread-mt;boost_thread

I guess this should be fixed on the CMake side but wanted to give a heads up here. How about renaming ? What do you think ?