[Mingw-w64-public] libwinpthreads dependency should be optional
The goal of C++ is that features not used should be possible to disable. If the C++ thread library is not used I would like an option -no-std-threads or something. Also, I wonder if the libwinpthread will conflict with native Win32 threads. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libwinpthreads dependency should be optional
On 3/19/2014 23:49, Torbjörn Rathsman wrote: The goal of C++ is that features not used should be possible to disable. If the C++ thread library is not used I would like an option -no-std-threads or something. You misunderstand, the C++ thread implementation does not allow that. libgcc itself depends on winpthreads for initialization if you want C++11 thread support. If you don't need C++11 thread support, don't use Posix thread version. Use the regular win32 thread version. Also, I wonder if the libwinpthread will conflict with native Win32 threads. No it will not, as long as you do not mix thread objects like mutex and semaphores meant for the other. signature.asc Description: OpenPGP digital signature -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Sbuild update 4.1.1
On Sun, Mar 23, 2014 at 1:11 AM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 S[mart|tupid] build[1] got a minjor update = About = sbuild is a set of scripts that build various free software packages for Windows from the source, starting with a GCC toolchain (cross-compiled) and MSYS2 core (cross-compiled), and ending with various applications (msys2-git, msys2-subversion, mingw-gdb), libraries and frameworks (GTK+, GNUnet, GStreamer). All buildscripts are written in simple-to-understand-style of POSIX shell language, and a few small utilities are in Python. = Release Highlights = == Package Of The Day == Today's Package Of The Day is GtkParasite[2] - a GTK+ plugin for messing with GTK+ applications at runtime. With the advent of GTK+-3.x it's now more important than ever to be able to try out theming CSS without restarting applications, and GtkParasite does the job. It also has ridiculously cute logo (which in no way influenced my decision to make GtkParasite the Package Of The Day). == MSYS2 == Not much has happened in MSYS2 land. Actually, no, some things did happen in upstream MSYS2 (new path mangling), but they didn't make it into 4.1.1, because i'm lazy. Just as well you are lazy. There's a few remaining problems with the new path mangling that we need to get fixed. Btw, do you ever run MSYS2 or Cygwin on Wine .. AFAIK it doesn't work, but I wondered if you knew more details about the issues? For MSYS2, building it all on Linux through Wine is something I we want to try. Anyway, MinGW/MSYS console is now set to use UTF-8 by default via LANG=en_US.UTF-8. This fixes some bugs with printing UTF8 text via printf that i've discovered a few months ago. I've finally had enough of CPAN and switched Perl-vendor download location to Fedora repositories. Hopefully, i won't need to update Perl-vendor as often as i did simply to keep up with CPAN dropping off old package versions. A gross bug in one of the custom libxslt patches i've been applying was fixed (the patch wasn't mine, by the way), this should dramatically reduce the number of xsltproc-related docbuilding failures. msys2-p11-kit and its direct dependencies are now built a bit earlier. == MinGW == MinGW-W64 didn't get any noteworthy updates, but winpthreads did get a patch that added a new pthreads function. Of note are updates to GNUTLS and libpng that fix security bugs. GNUTLS is particularly messy, as caused rtmpdump to need rebuilding, which caused libcurl to need rebuilding, which cause CMake to need rebuilding. There was an update to my GCC builds, which enabled pthreads in GCC. This ended up with me tagging sbuild 4.1, but i neglected to announce the update. Hence the minjor update this time. I've successfully built webkitgtk and Pidgin. Packages for those didn't make it into sbuild (but are available upon request), since i judged them to be too specialized; also, webkit alone takes HOURS to build...), but some of their dependencies did. In particular, i was told that PyGObject (Py2GObject, in this case) is awesome to have, so now sbuild builds it, and you can use GTK+-3.x from Python-2.x. Another notable addition is DBus (it passes the testsuite, but i'm still not sure how its usage in applications is going to play out). Added a script for updating Python EasyInstall package list (since sbuild used to screw it up, and now doesn't even touch it). Feels hackish, but hopefully it'll keep the damage to your Python installation minimal. Glib/GTK+ got some attention, which resulted in updates to some libraries in the G stack, and some patches (admittedly, one GTK+-3.x patch is experimental, and may cause memory leaks; it's better than crashing though, which is what happens without it). Finally, a string of spelling-related packages (aspell, enchant, gtkspell) is now built. They all work (tested this on gtkspell example app), and there's an English dictionary for aspell built and installed by default. == Issues known to be fixed == gnome-doc-utils might fail to build with a message along these lines: xsltApplyStylesheet: saving to C/name may not be possible. This was fixed. == Issues for which nothing is known == On one occasion gnome-doc-utils buildscript was reported to act in a manner similar to a fork bomb (!?!?), repeatedly (on restarts of the build process). Unable to reproduce, re-running the build from scratch seemed to have helped. No new reports of this bug. gobject-introspection might fail to generate stuff (failure at shutil.rmtree() in gdumpparser.py), especially on slow machines. Re-run the build from the last step. No new insights into this bug. xsltproc.exe from msys-xsltproc might segfault. Re-run the build from the last step. No new insights into this bug. = List of new packages = mingw-dbus-1-1.8.0-1 mingw-gsettings-desktop-schemas-3.0-3.11.91-1 mingw-json-glib-1.0-0.99.2-1
Re: [Mingw-w64-public] Sbuild update 4.1.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.03.2014 18:47, Ray Donnelly wrote: On Sun, Mar 23, 2014 at 1:11 AM, LRN wrote: Not much has happened in MSYS2 land. Actually, no, some things did happen in upstream MSYS2 (new path mangling), but they didn't make it into 4.1.1, because i'm lazy. Just as well you are lazy. There's a few remaining problems with the new path mangling that we need to get fixed. Btw, do you ever run MSYS2 or Cygwin on Wine .. AFAIK it doesn't work, but I wondered if you knew more details about the issues? For MSYS2, building it all on Linux through Wine is something I we want to try. No, i don't run anything in Wine. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJTLvVeAAoJEOs4Jb6SI2CwRZcH+gPW5FHMerhusoo3QQptvJV4 p8Cc8JozGVvDfQL0tv0R5VwVk9Qmj2bVbAeJCAd5T918h70wcgDy1oJIu2FdzlGA Z7tqkTmlezrYkMZDYpiM7B+61KCs5c5iQfPM9hqO9uVhxJvpHgZsgLZVAfVrkOPK DxcNrDppdxjx9hdui5Dzd1an2UTcH+zuLPwohNSE9TjmZvQEZW0XggPZ3ngvVI6E FQrq/I6m1UxIcbg28qBH4qYQiWJAYdZNBppixqkZYf5ybpEaKlSQ25Kxl4TwIcZN 10Yx3hhTcZZ9cJNmg5jOMtfHpXxDXgVPneqg9Vq6pQpz9WCnY0Xht9GmnrOPERI= =Y0EV -END PGP SIGNATURE- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libwinpthreads dependency should be optional
On Sun, Mar 23, 2014, John E. / TDM wrote: On 3/23/2014 4:12 AM, JonY wrote: On 3/19/2014 23:49, Torbjörn Rathsman wrote: The goal of C++ is that features not used should be possible to disable. If the C++ thread library is not used I would like an option -no-std-threads or something. *snip* If you don't need C++11 thread support, don't use Posix thread version. Use the regular win32 thread version. This is indeed the path users must take right now: choosing a different compiler build depending on what features they want to use. In many cases they don't even understand the features they're choosing among, or when to use which toolchain. * SJLJ unwinding Only option on 32b currently, see next point. * DW2 unwinding As said many times: it's possible but clearly discouraged. * SEH unwinding Best option on 64b. This makes one canonical set of EH: SJLJ on 32b and SEH on 64b. Typically something that the user doesn't see. * Win32 threading * POSIX threading Not much choice here. Download page now says C11/C++11 Threading Support instead of Win32/POSIX Threading since this is what it boils down too. Also note that the complaints are almost always to _disable_ the C11/C++11 threading support, never the other way round. In other words, the requests are to get a standard but only 95% of it! PS: I encourage everyone to refer to C11/C++11 threading support rather than posix or win32 threading support when appropriate; the former is what users see while the latter is what devs or tweakers see. -- Adrien Nader -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libwinpthreads dependency should be optional
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.03.2014 19:59, John E. / TDM wrote: On 3/23/2014 4:12 AM, JonY wrote: On 3/19/2014 23:49, Torbjörn Rathsman wrote: The goal of C++ is that features not used should be possible to disable. If the C++ thread library is not used I would like an option -no-std-threads or something. *snip* If you don't need C++11 thread support, don't use Posix thread version. Use the regular win32 thread version. This is indeed the path users must take right now: choosing a different compiler build depending on what features they want to use. In many cases they don't even understand the features they're choosing among, or when to use which toolchain. * SJLJ unwinding * DW2 unwinding * SEH unwinding I sincerely hope that SEH (and its x86_64 cousin) will replace everything this year, so the need to choose between different unwindings will disappear. * Win32 threading * POSIX threading It's a matter of adding native-W32-threads-using code to GCC. Doing that will remove winpthreads dependency. So far no one seems to be bothered enough to code this. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJTLxbZAAoJEOs4Jb6SI2Cw5GsH/25Zo5MEmiwPSHtw4mU35Ex6 qlw7sKxYwwJEWNYUH4Kg8TuIavQS2GvUihbOanD/l2ZoFuL+paaWvW1IXjUSPc6D LXcaXyD+SD2wJQoXHsaH/JJvIpeMyrVMe6SCEHjvcoLSQnPcH78+vnfOorIZ3E3X 6LuiiNo9SCASye3/RixzUSsrwkJkzt/gJKbFhcddNP8QsCthJk5BJNWhaXVHbO4i oBXXdALPrAtjlb4Q7OkGERBr6Nkm5+RiquPoZkpMyEipE6gF7Vp2yV6VwaV5uQFz +NAZIInEutBASAGWxJLpy1D2D4hfUW7rAu40QJ9VaKxlt04Ys2/dgwrYJZE1Wog= =aq4d -END PGP SIGNATURE- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libwinpthreads dependency should be optional
On Sun, Mar 23, 2014, LRN wrote: * Win32 threading * POSIX threading It's a matter of adding native-W32-threads-using code to GCC. Doing that will remove winpthreads dependency. So far no one seems to be bothered enough to code this. The main difficulty is in handling all the OS versions and it's not always that easy. -- Adrien Nader -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libwinpthreads dependency should be optional
On 3/24/2014 01:20, Adrien Nader wrote: On Sun, Mar 23, 2014, LRN wrote: * Win32 threading * POSIX threading It's a matter of adding native-W32-threads-using code to GCC. Doing that will remove winpthreads dependency. So far no one seems to be bothered enough to code this. The main difficulty is in handling all the OS versions and it's not always that easy. iirc there was some work done some time ago using win32 native threading, but it will cut off XP users completely due to how conditional variables are only available in Vista and later. signature.asc Description: OpenPGP digital signature -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] libwinpthreads dependency should be optional
Hello All! On Sun, Mar 23, 2014 at 6:13 PM, JonY j...@source.net wrote: On 3/24/2014 01:20, Adrien Nader wrote: On Sun, Mar 23, 2014, LRN wrote: * Win32 threading * POSIX threading It's a matter of adding native-W32-threads-using code to GCC. Doing that will remove winpthreads dependency. So far no one seems to be bothered enough to code this. I did do this on an experimental basis a few years back. I didn't do exhaustive testing, but according to my basic tests, all of std::thread was working. (That was my goal.) The implementation used windows critical sections for mutexes, and windows condition variables for condition variables. The only feature that didn't map neatly to the windows api in this scheme was std::timed_mutex, but with some extra work I was able to implement std::timed_mutex in terms of critical sections. The main difficulty is in handling all the OS versions and it's not always that easy. iirc there was some work done some time ago using win32 native threading, Yes, as described above. but it will cut off XP users completely due to how conditional variables are only available in Vista and later. Yes, windows condition variables are not supported in xp, so the above scheme only works for vista and later. My goal was to get gcc's std::thread working on windows, and the windows-api-based implementation accomplished this. But it's fair to say that even though pthreads is not part of the c++ standard (and I use std::thread in preference to pthreads for my own code), pthreads is very widely used. So although mingw-w64 doesn't need pthreads for c++11 compliance, it's clearly very valuable to ship a mingw-w64 that supports pthreads. And once you've done that, why not base std::thread on pthreads? Is there really any value is shipping two versions of std::thread? From my perspective (that of using portable, standard c++11 std::thread for threading), as long as std::thread works, I really don't care whether std::thread is based on pthreads or not. But I would really NOT want a version of mingw-w64 that only supported part of the c++11 standard, i.e., that didn't support std::thread. Happy Multi-Threaded Hacking! K. Frank -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
