Package Details: mingw-w64-boost 1.70.0-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-boost.git (read-only)
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: 21
Popularity: 1.282816
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 »

ekpyron commented on 2013-11-04 17:59

@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

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

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:

http://page.mi.fu-berlin.de/mokaga/mingw-w64-boost-1.54.0-1.src.tar.gz

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)

./bootstrap.sh --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.