Package Details: mingw-w64-boost 1.83.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: 2023-09-03 19:55 (UTC)

Latest Comments

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

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?

ekpyron commented on 2013-09-16 15:50 (UTC)

I updated to 1.54.0. Please note that the dlls now go to /usr/*-w64-mingw32/bin instead of /usr/*-w64-mingw32/lib as suggested by the package guidelines. Please let me know if there are any issues with the new version.

ekpyron commented on 2013-09-16 15:16 (UTC)

@rockman Thank you very much, that indeed does fix the problem. I tried earlier to define BOOST_USE_WINDOWS_H globally, but somehow it didn't work - defining it in boost/detail/interlocked.hpp indeed fixes the problem, though. I'll just update the PKGBUILD to use a package() routine, etc., and upload a working PKGBUILD for version 1.54.0 shortly.

GuLinux commented on 2013-09-16 13:05 (UTC)

I haven't tried yet your 1.54 package, but I was having the same issue with the 1.50 build. I found this though: http://sourceforge.net/mailarchive/message.php?msg_id=31189847 , and just defining BOOST_USE_WINDOWS_H in boost/detail/interlocked.hpp seems to fix the issue. I might try the same on 1.54 when I'm home.

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