Package Details: mingw-w64-boost 1.61.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: 12
Popularity: 0.016716
First Submitted: 2012-03-22 18:46
Last Updated: 2016-05-14 16:10

Latest Comments

xantares commented on 2015-05-18 10:29

@Pse, thanks added it, I guess the error appears from the mingw-gcc 5.1 update

travnick commented on 2015-05-17 18:23

Can not build 1.58:

common.copy [...]/mingw-w64-boost/pkg/mingw-w64-boost/usr/i686-w64-mingw32/lib/libboost_wave-mt.a
...failed updating 6 targets...
...skipped 13 targets...
...updated 12666 targets...

silverhammermba commented on 2015-05-15 21:40

Where do you define that? I tried adding -D compiler flags but the build still fails for me.

Pse commented on 2015-05-15 19:39

I had to add the following definitions for Boost to compile on my 64-bit system:


xantares commented on 2015-04-29 07:47

@schala: i cant update 1.58 just yet; the coroutine lib does not build because of a symbol problem in boost.context

xantares commented on 2014-11-20 12:45

could you use the right mingw flags (
cxxflags=-std=c++11 \
cxxflags="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4" \
(is -std=c++11 flag still necessary ? the core package doesn't have that)

ekpyron commented on 2014-09-28 18:09


Could you be more specific about error messages, etc.? It should build on x86_64 without any changes. Note that yaourt usually compiles packages in /tmp and boost needs a lot of space, so you need a lot of RAM for that to work - "yaourt --tmp /some/directory/on/disk/ -S mingw-w64-boost" should work, if that's the problem.

applesauce commented on 2014-09-28 05:53

When I tried installing this on an x86_64 system, yaourt told me that the installation failed. Do I need to change anything in the PKGBUILD?

ekpyron commented on 2014-09-09 22:05


The reason was that there were some differences between the architectures anyways in earlier versions. Still now the correct address-model=[32|64] must be specified, but you're right - it makes sense to combine the code for the architectures, so I updated the PKGBUILD accordingly.

xantares commented on 2014-09-09 13:58

why dont you use an arch list loop:

_architectures = "i686-... x86_64-..."
for _arch in ${_architectures}; do
mkdir -p build-${_arch} && pushd build-${_arch}

package code would be twice shorter

xantares commented on 2014-09-02 08:03


ekpyron commented on 2014-08-27 22:40

Please refrain from flagging this package out-of-date before boost in extra is updated.

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 ?

ekpyron commented on 2013-11-04 17:59

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

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

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

@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

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: , 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.

ekpyron commented on 2013-08-26 15:08

I did some experiments with boost 1.54.0. I included a patch from the boost bug tracker, that ports the parts of the context library depending on masm to gas. The 32-bit build seems to work fine with that, but in the 64-bit build the locale library fails with undefined reference to InterlockedCompareExchange, InterlockedExchangePointer, etc. Maybe there are further issues with the 64-bit build.

If anyone can find a solution for the 64-bit build, I'd be happy to update the PKGBUILD.

I uploaded the PKGBUILD here:

Anonymous comment on 2013-05-30 21:33

I have built boost 1.53 with mingw-w64 (the nightly build from May 30 2013) on arch linux. Had to disable quite a lot of stuff to make it compile, but in the end the following seemed to make it build both as 32bit and 64bit:

First set up user-config.bjam targeting 32bit compiler and 64bit compiler (docs are at boost)

./ --without-icu --without-libraries=python,wave,mpi

(now one could probably enable python wave and mpi if those were properly installed on your system - mine is not, and I have no use for them, so I disabled them)

./b2 --disable-filesystem2 --without-context --without-mpi --without-python threading=multi cxxflags=c++11 address-model=64 --user-config=64bit-boost-user-config.jam toolset=gcc target-os=windows threadapi=win32 -sNO_BZIP2=1 -sNO_ZLIB=1 install

./b2 --disable-filesystem2 --without-context --without-mpi --without-python threading=multi cxxflags=c++11 address-model=32 --user-config=32bit-boost-user-config.jam toolset=gcc target-os=windows threadapi=win32 -SNO_BZIP2=1 -sNO_ZLIB=1 install

The user-config files are just instructions for bjam to where the mingw compiler binaries are located - example:

using gcc : : /path/to/mingw/c++/compiler
<rc> /path/to/mingw/windres/compiler
<ar> /path/to/mingw/ar

So again - it is probably possible to enable mpi and python if correctly configured - the main problem I had with 1.53 was the context library, that just does not compile with mingw (if you compile under windows you can enable it by downloading masm and putting masm in your path - but that is not an option for me, I also have no need for context library - so i just ignore it)

Now i do appreciate that probably some people will need what I disabled, so this is no universal fix, it only goes to show that it is possible to compile boost 1.53.0 with mingw64 if you are prepared to disable some of the boost libraries.

I havent tried rubenvb personal builds for compiling boost 1.54.0 but I'm guessing that will work as well.

ekpyron commented on 2013-04-08 03:31

Unfortunately boost 1.53 doesn't seem to fix the problem, the threading library still does not compile (probably the same issue mingw32-boost is having). Maybe I can soon have another look at it, when I have more time.

Schala commented on 2013-03-15 21:13

Boost 1.53 is out. I don't know whether or not it should fix the problems you encountered with 1.52. Apparently being unable to build with mingw-w64 was a known issue for 1.52.

ekpyron commented on 2013-02-23 01:08

If anybody can provide a working PKGBUILD for building boost 1.52.0, I'll happily update the package - otherwise I'm afraid the update will take a while, because I'm having some difficulties getting the new version to compile and I don't have much time to figure it out at the moment.

ekpyron commented on 2012-11-03 06:23

Please don't mark this as deprecated before boost in [extra] is updated.

Schala commented on 2012-09-09 04:49

compared to 1.50.0-3 I think. I'm not worried though. It probably just detected the capability to compile another component than the prebuilt you provided.

ekpyron commented on 2012-09-07 08:35


@Schala: 6 megs larger compared to which version? Would be interesting what's the reason for that - probably nothing to worry about, though.

Schala commented on 2012-09-07 05:38

Built successfully! Though an unexplainably 6 megs larger. I guess it must've detected the capability to build an extra library or so.

Schala commented on 2012-09-07 05:14

Building currently. I'm not getting a slew of errors with each link now. Fingers crossed!

naelstrof commented on 2012-09-07 04:34

It works flawlessly! Thanks!

ekpyron commented on 2012-09-07 04:32

OK, even in a clean chroot with only "base" and "base-devel" installed before mingw-w64-gcc, it does support "-mthreads" for me, so I'll leave it at "threading=multi" for now, unless somebody reports that this does not work with a clean, fresh, up-to-date installation. I made the other changes (i.e. adding "unset LDFLAGS" and using a custom toolchain name), though, and updated the PKGBUILD accordingly.

naelstrof commented on 2012-09-07 03:58

Sweet thanks for your support! I tested using -mthreads on x86_64-w64-mingw32-gcc and it worked fine. I'm trying to build mingw-w64-boost again right now, lets see if it works.

ekpyron commented on 2012-09-07 03:10

OK, your right about adding "unset LDFLAGS" and I see no real harm in using a custom "gcc-mingw64" toolset (although it surprises me, that it does make a difference, as the usual toolset definition works for me without problems).

As to "threading=single": this is the really interesting part, as this seems like the same issue Schala had before.
You are sure that your mingw64 gcc compiler does not support the "-mthreads" flag (you can verify by compiling "int main(void){}" with "x86_64-w64-mingw32-gcc -mthreads")? For testing I just removed all my mingw-w64 packages and rebuilt from scratch and my mingw-w64-gcc does support the "-mthreads" flag (as it has always done), so we have to figure out why that is... I'll setup a clean chroot with only the necessary dependencies for building mingw-w64-gcc and mingw-w64-boost and see whether I can thus reproduce the problem (although I tried that before without luck)...

naelstrof commented on 2012-09-06 21:31

I put in unset LDFLAGS due to it being a requirement in the mingw-w64 packaging standards here:
I put threading=single due to my mingw64 gcc compiler not supporting the "-mthreads" compile flag. Not sure if it's due to it being out of date or having the feature disabled, but for what I wanted I didn't mind using single thread.
I had to use "using gcc : mingw64 : ${_arch}-g++" instead of "using gcc : 4.7 : ${_arch}-g++" because otherwise bjam would try to link files together with the default /usr/bin/ld; which created some errors. Creating the custom toolset gcc-mingw64 allowed it to auto-detect the needed binaries (or something) as it caused no problems.

And yeah I agree, adding "using mpi ;" probably doesn't change anything. I was having so much trouble with the package that when bjam advised me to include it I didn't think it'd hurt.

ekpyron commented on 2012-09-06 06:02

Hm - strange. For me both versions, the one here and the one you uploaded, work without problems. Could you do some testing as to figure out what exactly makes the difference for you? I think the problem must be one of the following:
* you use "unset LDFLAGS" - if this is the cause of your problem, it's likely that you have a modified /etc/makepkg.conf that prevents the build from succeeding.
* you use "threading=single", I use "threading=multi" - I'd rather not want to change that. If that's the cause for your problem, we should report the problem upstream, as I think that would likely mean there's an issue in boost.
* you use "using gcc : mingw64 : ${_arch}-g++" and thus "toolset=gcc-mingw64" - I use "using gcc : 4.7 : ${_arch_target32}-g++" and thus "toolset=gcc" - I think this is actually meant to be used like I do (or at least work both ways), but if this causes the problem for you it's no problem to change the PKGBUILD accordingly.
* I don't think that "using mpi;" makes any difference.
Apart from that your PKGBUILD seems to do pretty much the same as mine. If you were so kind as to check which of these point(s) allow you to compile the package and which prevent you from doing so, I'll happily adjust the PKGBUILD accordingly.

Could you try the PKGBUILD naelstrof posted, as to check whether this solves your problem as well?

naelstrof commented on 2012-09-06 02:38

For whatever reason I couldn't compile it properly either, I adjusted the PKGBUILD till it worked for me. You can find it here for whoever needs it:

Schala commented on 2012-08-15 03:15

It just occurred to me that perhaps I have a malformed system setting. I recall the time that hardly anything would build for me and it turns out the thing I had to do was set my system LOCALE. However, I wonder what the problem is this time...

Schala commented on 2012-08-10 10:39

For some odd reason, some packages fail in mingw-w64 64 32-bit wwhereas they build in mingw32. I think fontconfig is one of them.

ekpyron commented on 2012-08-09 16:53

Well, first of all we'd need mingw-w64-gcc in [community] - it has 9 out of 10 votes that are mentioned to be required for an inclusion in [community], so yes, hopefully things will move in that direction soon - it will make things easier indeed (I'd even consider mingw32 deprecated then as mingw-w64 can compile both 32 and 64 bit).

Schala commented on 2012-08-09 15:17

Yeah, bjam is a nightmare to comprehend. I don't urgently need this, but I cast my vote in hopes this'll make it into [community] or something and save me a headache when I do need it.

ekpyron commented on 2012-08-09 09:09

Yes, that was what I meant, but my guess is still that for some strange reason bjam on your system doesn't use the right version of g++... as it worked on every system with a clean new mingw-w64 I tried it on, I recommend that you remove and then reinstall your whole mingw-w64 (i.e. not only mingw-w64-gcc, but also mingw-w64-binutils, mingw-w64-winpthreads, etc.) and see whether the problem remains (sometimes updating only mingw-w64-gcc without rebuilding all the other packages from scratch breakes things). Also check if the normal boost on your system is up to date. If you urgently need this package I put a pre-compiled version online at (install with "pacman -U [path to downloaded file]").
I'm sorry that I can't help you further, but I'm not an expert in regards to the boost build system myself (I always found this whole bjam-stuff to be quite a bit crappy...) and without being able to reproduce your problem, I can't do much more.

Schala commented on 2012-08-09 05:30

Well, I copied and pasted the whole thing into the following file. Sorry if it's not what you meant, but if you want to see where the error occurs, look to the very bottom.

ekpyron commented on 2012-08-09 04:04

Not surprising that it also happened with mingw32 as I took the PKGBUILD from there (with only minor modifications)...
Maybe I could help you if you gave me the full build messages and not only the final error message - as I said, I think for some reason bjam tries to use the wrong version of g++... what's strange is that I just set up a fresh 64-bit arch system recently and I don't have the problem, so I think there is most likely something strange going on with your system (whatever that could be)...

Schala commented on 2012-08-09 02:33

64-bit, and no it doesn't unfortunately. mingw-w64-gcc is up to date. The same error happened with mingw32 as well, so... I have no clue what's going on.

ekpyron commented on 2012-08-09 01:47

Are you sure your mingw-w64-gcc is up to date and working correctly? x86_64-w64-mingw32-g++ and i686-w64-mingw32-g++ do recognize the '-mthreads' option - it appears that for some reason on your system the boost build system tries to use the normal g++ instead of the mingw-w64 version...
Are you on a 32-bit or a 64-bit system? It's difficult to fix the problem without being able to reproduce it...
Does it work if you change the version number in the PKGBUILD back to 1.49.0 (there haven't been any changes in the PKGBUILD apart from updating the version number)?

Schala commented on 2012-08-09 00:19

I got the following error about a dozen times:

g++: error: unrecognized command line option ‘-mthreads’

ekpyron commented on 2012-08-07 19:31

@Schala Could you be more specific about the problem you're experiencing? For me it does build without any problems (on a freshly built 64-bit arch with the latest mingw-w64-gcc)...

Schala commented on 2012-08-06 23:58

Fails for me, doesn't seem to recognize "-mthreads" parameter