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 »

naelstrof commented on 2012-09-07 04:34 (UTC)

It works flawlessly! Thanks!

ekpyron commented on 2012-09-07 04:32 (UTC)

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

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

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

I put in unset LDFLAGS due to it being a requirement in the mingw-w64 packaging standards here: https://wiki.archlinux.org/index.php/MinGW_PKGBUILD_guidelines 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 (UTC)

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

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: http://farmpolice.com/content/texts/mingw-w64-boost

Schala commented on 2012-08-15 03:15 (UTC)

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

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

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

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