Re: [Mingw-w64-public] v4.0.0 released

2015-03-21 Thread Alon Bar-Lev 
On 21 March 2015 at 00:06, Stephen Kitt li...@sk2.org wrote:

 Hi,

 On Fri, 20 Mar 2015 22:04:38 +0200, Alon Bar-Lev alon.bar...@gmail.com
 wrote:
  Every major update we (at gentoo) and maybe others have issue to upgrade. I
  reported[1] this in the past.
 
  Building the crt should use the headers within the crt and not within
  sysroot, this to enable building the new crt using an environment that has
  the old crt.
 
  Other libc implementation does exactly that, I tried to modify the build of
  the mingw runtime and it seem non trivial to achieve this in current state.
 
  Can you please consider implementing that?

 The way I get around this is a variant of:

 * build the CRT headers
 * install them to ${source}/tmp (so they end up in
   ${source}/tmp/usr/${target}/include)
 * configure the CRT libraries with -I${source}/tmp/usr/${target}/include

 That way the CRT libraries are built with the provided headers, not the
 installed ones.

Thanks!
It seems to work, I tried this trick in 3.0 and it took the header out
of sysroot because it injected this as sysinclude.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads cleanup handlers not called afterpthread_exit()

2015-03-21 Thread Keri Harris 
On 21/03/2015 12:39, Victor Bombi wrote:
 May be it has some relation with?

 http://sourceforge.net/p/mingw-w64/mailman/message/31749147/

I don't think it's related; this has to do with explicit calls to 
thread_exit() not invoking cleanup handlers that were registered via 
pthread_cleanup_push().

Looking at the definition for pthread_cleanup_push() in 
winpthreads/include/pthread.h, it looks like the cleanup stack is only 
accessible via a local variable, and no mechanism exists to call these 
handlers unless pthread_cleanup_pop() is explicitly called. 
pthreads-win32 uses __try/__finally (for SEH) or 
pthread_setspecific()/pthread_getspecific() (for C cleanup) to ensure 
they're always called.


 - Original Message -
 From: Keri Harris k...@gentoo.org
 To: mingw-w64-public@lists.sourceforge.net
 Sent: Thursday, March 19, 2015 3:27 PM
 Subject: [Mingw-w64-public] winpthreads cleanup handlers not called
 afterpthread_exit()


 I've noticed some unexpected behaviour with winpthreads which I believe
 is a bug. Thread-cancellation cleanup handlers are not called when a
 thread terminates due to a call to pthread_exit(). This is unexpected;
 the pthread_cleanup_push(), pthread_cleanup_pop() specification [1]
 mentions:

  The cancellation cleanup handler shall be popped from the
 cancellation cleanup stack
  and invoked with the argument arg when:

  The thread exits (that is, calls pthread_exit()).

 An example program illustrating winpthreads failing to invoke cleanup
 handlers follows:


 #include pthread.h
 #include stdio.h

 void* cleanup_func(void *arg)
 {
  printf(cleanup_func()\n);
 }

 void* func(void *arg)
 {
  printf(func()\n);
  pthread_cleanup_push(cleanup_func, 0);
  pthread_exit(NULL);
  pthread_cleanup_pop(1);
 }

 int main()
 {
  pthread_t t;
  void *ret;

  pthread_create(t, NULL, func, (void*)NULL);
  pthread_join(t, ret);

  return 0;
 }



 Thanks

 Keri

 [1]
 http://pubs.opengroup.org/onlinepubs/95399/functions/pthread_cleanup_pop.html


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

2015-03-21 Thread Vincent Torri 
hey

imho, you should add a paypal link with a nice icon on the front page,
and not only in the 'donate' page.

Vincent Torri



On Fri, Mar 20, 2015 at 10:51 PM, Adrien Nader adr...@notk.org wrote:
 Hi,

 I've just pushed a redirect from http://mingw-w64.sourceforge.net to
 http://mingw-w64.yaxm.org in order to serve a new website.

 I have been taking care of the website for at least a couple years now.
 Not that I particularly enjoy doing PHP, CSS and Javascript but there
 was a need. However I suck at design and I had very little time
 available, which meant all the changes I could do were minimal.

 Last week I finally bit the bullet and spent half a day assessing
 whether something based on dokuwiki could work and then spent a day
 moving the data from the website to that dokuwiki and tweak its them and
 plugins.
 This was discussed a bit over IRC and the switch has been hurried by the
 release of 4.0: I was feeling miserable each time I had to update
 anything on the website and I really didn't feel like taking one hour
 just to add a section to the existing layout, especially knowing the
 website replacement was going to occur soon.

 The now-old website is still available, only masked through a redirect.
 Please speak up if you are not pleased with the new one.

 One notable change is that the website is not served through
 sourceforge.net anymore. I had started with everything on SF but more
 often than not, the pages would fail to load. Unfortunately this means
 there is a user-visible redirection on a temporary subdomain; this is
 expected to remain for one month at most.

 NB: this does not change anything else; nothing but the website that has
 been visible on http://mingw-w64.sourceforge.net changes.

 The wiki from sourceforge is going to be abandoned. Well. Noone has
 touched wiki2 since it was set up a year ago so it's not a big loss.
 Dokuwiki should be a nicer place for wiki changes (faster, cuter, and
 fully integrated into the website obviously).
 The only minor downside currently is that users cannot register
 themselves to change the website. This is minor since I can do it on
 request and because the set of pages that is currently up will not be
 editable by most people anyway (i.e. main page, downloads). This will
 be fixed.

 On a final note I'd like to thank the author of the initial mingw-w64
 website. As far as I remember he had a company named CodeCamel but
 currently the website is MIA but the domain name has been parked with
 seemingly-innocuous link spam. That website has served mingw-w64 well
 for around 5 years.
 Its replacement did not happen out of discontent but because a lot has
 happened over these 5 years, both the web (mobile, many new viewport
 sizes, saner browsers, ...) and for mingw-w64 (so many more users,
 contributors, activity on all fronts and much more content).
 Working with sourceforge.net SSH access was the painful part as it was
 slow and not having a CSS theme used (and tested) by many other websites
 made the process brittle and time-consuming.

 I wished there had been time to bring the topic on the mailing-list
 before doing the switch but v4.0 timing made that hard and I've also
 taken great care to not lose anything in the process. Any constructive
 criticism is welcome; don't hesitate.

 --
 Adrien Nader

 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads cleanup handlers not called afterpthread_exit()

2015-03-21 Thread Victor Bombi 
May be it has some relation with?

http://sourceforge.net/p/mingw-w64/mailman/message/31749147/

- Original Message - 
From: Keri Harris k...@gentoo.org
To: mingw-w64-public@lists.sourceforge.net
Sent: Thursday, March 19, 2015 3:27 PM
Subject: [Mingw-w64-public] winpthreads cleanup handlers not called 
afterpthread_exit()


 I've noticed some unexpected behaviour with winpthreads which I believe
 is a bug. Thread-cancellation cleanup handlers are not called when a
 thread terminates due to a call to pthread_exit(). This is unexpected;
 the pthread_cleanup_push(), pthread_cleanup_pop() specification [1]
 mentions:

 The cancellation cleanup handler shall be popped from the
 cancellation cleanup stack
 and invoked with the argument arg when:

 The thread exits (that is, calls pthread_exit()).

 An example program illustrating winpthreads failing to invoke cleanup
 handlers follows:


 #include pthread.h
 #include stdio.h

 void* cleanup_func(void *arg)
 {
 printf(cleanup_func()\n);
 }

 void* func(void *arg)
 {
 printf(func()\n);
 pthread_cleanup_push(cleanup_func, 0);
 pthread_exit(NULL);
 pthread_cleanup_pop(1);
 }

 int main()
 {
 pthread_t t;
 void *ret;

 pthread_create(t, NULL, func, (void*)NULL);
 pthread_join(t, ret);

 return 0;
 }



 Thanks

 Keri

 [1]
 http://pubs.opengroup.org/onlinepubs/95399/functions/pthread_cleanup_pop.html


 --
 Dive into the World of Parallel Programming The Go Parallel Website, 
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for 
 all
 things parallel software development, from weekly thought leadership blogs 
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public 


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] v4.0.0 released

2015-03-21 Thread Alon Bar-Lev 
On 21 March 2015 at 10:06, Alon Bar-Lev alon.bar...@gmail.com wrote:
 On 21 March 2015 at 00:06, Stephen Kitt li...@sk2.org wrote:

 Hi,

 On Fri, 20 Mar 2015 22:04:38 +0200, Alon Bar-Lev alon.bar...@gmail.com
 wrote:
  Every major update we (at gentoo) and maybe others have issue to upgrade. I
  reported[1] this in the past.
 
  Building the crt should use the headers within the crt and not within
  sysroot, this to enable building the new crt using an environment that has
  the old crt.
 
  Other libc implementation does exactly that, I tried to modify the build of
  the mingw runtime and it seem non trivial to achieve this in current state.
 
  Can you please consider implementing that?

 The way I get around this is a variant of:

 * build the CRT headers
 * install them to ${source}/tmp (so they end up in
   ${source}/tmp/usr/${target}/include)
 * configure the CRT libraries with -I${source}/tmp/usr/${target}/include

 That way the CRT libraries are built with the provided headers, not the
 installed ones.

 Thanks!
 It seems to work, I tried this trick in 3.0 and it took the header out
 of sysroot because it injected this as sysinclude.

Maybe stupid question... but why not build against in-tree headers by default?

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] v4.0.0 released

2015-03-21 Thread Erik van Pienbroek 
JonY schreef op zo 15-03-2015 om 09:20 [+0800]:
 *** Known Issues ***
 SDL2 build is broken due to incomplete DX11 support in mingw-w64 and 
 some duplicated declarations in SDL2. Disabling the DX11 backend 
 seems to fix things temporarily.

FYI, I just spent some time investigating this issue and came up with a
couple of patches which implement the missing D3D11 features which are 
required by SDL2 and which also fix two issues in SDL2 itself 
(duplicate d3d11 declarations and a gcc macro issue). I've just sent 
these patches to Jacek for review and approval so they should show up 
in wine and mingw-w64 soon.

Regards,

Erik



--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] v4.0.0 released

2015-03-21 Thread JonY 
On 3/22/2015 02:59, Alon Bar-Lev wrote:
 
 Maybe stupid question... but why not build against in-tree headers by default?
 

Because they are designed to be separate and haphazardly thrown together
in a single package. The top-level configure was a quick hack that was
never properly completed.




0xD4EBC740.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public