Package Details: mingw-w64-boost 1.86.0-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-boost.git (read-only, click to copy)
Package Base: mingw-w64-boost
Description: Free peer-reviewed portable C++ source libraries (mingw-w64)
Upstream URL: http://www.boost.org/
Licenses: custom
Submitter: ekpyron
Maintainer: xantares
Last Packager: xantares
Votes: 19
Popularity: 0.000000
First Submitted: 2012-03-22 18:46 (UTC)
Last Updated: 2024-09-02 20:58 (UTC)

Latest Comments

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

hauzer commented on 2014-04-11 16:06 (UTC)

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

hauzer commented on 2014-04-11 16:04 (UTC)

@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 (UTC)

@xantares 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 (UTC)

Hi, Boost is not configured like in the fedora packages threading=single,multi 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. xan.

hauzer commented on 2014-04-03 03:31 (UTC)

I've made a mingw-w64-boost-python package (https://aur.archlinux.org/packages/mingw-w64-boost-python/), which complements this one.

ekpyron commented on 2014-01-21 14:24 (UTC)

@gchatelet 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 (UTC)

Because of 'threadapi=win32' the threading libraries are named libboost_thread_win32-mt.a libboost_thread_win32-mt.dll.a instead of libboost_thread-mt.a libboost_thread-mt.dll.a 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 ?

ekpyron commented on 2013-11-04 17:59 (UTC)

@hauzer I myself have no need for a debug build and I think most people won't, so feel free to create a debug variant of this package, but I don't intend to include debug builds in this package.

hauzer commented on 2013-11-04 17:02 (UTC)

What do you think, should a debug variant be included in this package, or a separate package would be a better alternative?

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