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