Re: [Mingw-w64-public] winpthreads issue
So, after long debugging and testing I finally found the cause. Well, I cleaned up winpthread-code a bit while debugging for it, and finally found that the underlying issue was to be found in pthread.h and the constant definition of PTHREAD_PROCESS_PRIVATE and PTHREAD_PROCESS_SHARED. Actual the values for those constants were toggled. By fixing this, libgomp seems to work as expected. Regards, Kai -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] two winpthreads build machinery issues
On 8/16/2011 20:57, Ruben Van Boxem wrote: Hi, Since Kai fixed the winpthreads/libgomp problem (Kai, you are a hero!), I have been trying to finalize the winpthreads build stuff in my scripts and testing, which lead to two issues: 1. I can't link to winpthreads statically, better said, if I compile the small openmp test program with the added -static option, I get undefined references to pthreads functions. When I check the size of the static libpthread.a, it's smaller than the DLL import lib, which is not right. I think the autotools stuff is missing something here. Check if adding -lpthread works, If so check your openmp specs file, I can't remember what its called, it probably did something weird for the static case. 2. In order to get the DLL installed into sysroot/bin where it belongs (for non-multilib setups), I passed the --bindir=sysroot/bin option to configure, but the dll was still placed in prefix/bin instead. I can move it over myself, but autotools can do this, so it really should be fixed there. Thanks! Yes, you can do that, but I'm trying to figure out how to fixup the install dir without breaking cross builds. if build==host, then append ../../bin to bindir, hmmm. signature.asc Description: OpenPGP digital signature -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] two winpthreads build machinery issues
Op 16 aug. 2011 16:13 schreef JonY jo...@users.sourceforge.net het volgende: On 8/16/2011 20:57, Ruben Van Boxem wrote: Hi, Since Kai fixed the winpthreads/libgomp problem (Kai, you are a hero!), I have been trying to finalize the winpthreads build stuff in my scripts and testing, which lead to two issues: 1. I can't link to winpthreads statically, better said, if I compile the small openmp test program with the added -static option, I get undefined references to pthreads functions. When I check the size of the static libpthread.a, it's smaller than the DLL import lib, which is not right. I think the autotools stuff is missing something here. Check if adding -lpthread works, If so check your openmp specs file, I can't remember what its called, it probably did something weird for the static case. 2. In order to get the DLL installed into sysroot/bin where it belongs (for non-multilib setups), I passed the --bindir=sysroot/bin option to configure, but the dll was still placed in prefix/bin instead. I can move it over myself, but autotools can do this, so it really should be fixed there. Thanks! Yes, you can do that, but I'm trying to figure out how to fixup the install dir without breaking cross builds. if build==host, then append ../../bin to bindir, hmmm. Just fix the autotools --bindir option, so one can decide for oneself if it's needed/wanted. It's a custom step that may not be wanted everywhere you build winpthreads in that configuration. -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] two winpthreads build machinery issues
2011/8/16 NightStrike nightstr...@gmail.com: On Tue, Aug 16, 2011 at 10:52 AM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2011/8/16 NightStrike nightstr...@gmail.com: On Tue, Aug 16, 2011 at 10:17 AM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Op 16 aug. 2011 16:13 schreef JonY jo...@users.sourceforge.net het volgende: On 8/16/2011 20:57, Ruben Van Boxem wrote: Hi, Since Kai fixed the winpthreads/libgomp problem (Kai, you are a hero!), I have been trying to finalize the winpthreads build stuff in my scripts and testing, which lead to two issues: 1. I can't link to winpthreads statically, better said, if I compile the small openmp test program with the added -static option, I get undefined references to pthreads functions. When I check the size of the static libpthread.a, it's smaller than the DLL import lib, which is not right. I think the autotools stuff is missing something here. Check if adding -lpthread works, If so check your openmp specs file, I can't remember what its called, it probably did something weird for the static case. 2. In order to get the DLL installed into sysroot/bin where it belongs (for non-multilib setups), I passed the --bindir=sysroot/bin option to configure, but the dll was still placed in prefix/bin instead. I can move it over myself, but autotools can do this, so it really should be fixed there. Thanks! Yes, you can do that, but I'm trying to figure out how to fixup the install dir without breaking cross builds. if build==host, then append ../../bin to bindir, hmmm. Just fix the autotools --bindir option, so one can decide for oneself if it's needed/wanted. It's a custom step that may not be wanted everywhere you build winpthreads in that configuration. Change autoconf? Although I always have a hard time understanding your two-word replies, I assume you're saying that this would require patching autotools? This is not what I was steering at. All that would be logical is that the install directory for the winpthreads dll to listen to --bindir, so that the developer files can be installed in sysroot/target-triplet/ and the dll can be installed along with the other runtime dll's in sysroot/bin. Ruben Don't libraries go into libdir? So, wouldn't you want to pass --libdir on the configure line? No, DLLs don't go to prefix/lib, they go to prefix/bin. DLLs are not .so's or .dylib's or whatever. The DLL is already installed in a prefix/bin directory by default, that's not the problem. It's that GCC expects libpthread.a and pthread.h to be in sysroot/target-triple/include and lib, but when a user compiles a program that uses the pthreads DLL (s)he'd need to add sysroot/target-triple/bin to PATH, which also contains the binutils tools (which AFAIK aren't the ones you're supposed to be running). I'd like to use --bindir=sysroot/bin (or any other option you think is most suited for this) to change the install directory of the DLL. If this is not possible with autotools it's an oversight, then I'll just manually move the DLL, but this shouldn't be strictly necessary with all the options autotools provides. I just checked GMP, and it doesn't listen either. So I guess this might be a autotools problem that either requires copying/moving manually or a winpthreads configury local workaround. Ruben -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] two winpthreads build machinery issues
2011/8/16 Kai Tietz ktiet...@googlemail.com:
2011/8/16 Ruben Van Boxem vanboxem.ru...@gmail.com:
Hi,
Since Kai fixed the winpthreads/libgomp problem (Kai, you are a
hero!), I have been trying to finalize the winpthreads build stuff in
my scripts and testing, which lead to two issues:
1. I can't link to winpthreads statically, better said, if I compile
the small openmp test program with the added -static option, I get
undefined references to pthreads functions. When I check the size of
the static libpthread.a, it's smaller than the DLL import lib, which
is not right. I think the autotools stuff is missing something here.
Hi Ruben,
about 1. point. Could you try the following patch for this (for gcc's
gcc/config/i386/mingw32.h header)
Index: mingw32.h
===
--- mingw32.h (revision 177784)
+++ mingw32.h (working copy)
@@ -189,7 +189,8 @@
/* mingw32 uses the -mthreads option to enable thread support. */
#undef GOMP_SELF_SPECS
-#define GOMP_SELF_SPECS %{fopenmp: -mthreads}
+#define GOMP_SELF_SPECS %{fopenmp|ftree-parallelize-loops=*: \
+ -mthreads -pthread}
/* mingw32 atexit function is safe to use in shared libraries. Use it
to register C++ static destructors. */
Yes, this works (no more undefined references). Could this be applied
to GCC 4.5 and 4.6 please? That would be great!
2. In order to get the DLL installed into sysroot/bin where it
belongs (for non-multilib setups), I passed the --bindir=sysroot/bin
option to configure, but the dll was still placed in prefix/bin
instead. I can move it over myself, but autotools can do this, so it
really should be fixed there.
Well, this might be fixable by NightStrike.
Regards,
Kai
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] two winpthreads build machinery issues
On 8/16/2011 23:23, Ruben Van Boxem wrote: 2011/8/16 NightStrike nightstr...@gmail.com: On Tue, Aug 16, 2011 at 10:52 AM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2011/8/16 NightStrike nightstr...@gmail.com: On Tue, Aug 16, 2011 at 10:17 AM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Op 16 aug. 2011 16:13 schreef JonY jo...@users.sourceforge.net het volgende: On 8/16/2011 20:57, Ruben Van Boxem wrote: Hi, Since Kai fixed the winpthreads/libgomp problem (Kai, you are a hero!), I have been trying to finalize the winpthreads build stuff in my scripts and testing, which lead to two issues: 1. I can't link to winpthreads statically, better said, if I compile the small openmp test program with the added -static option, I get undefined references to pthreads functions. When I check the size of the static libpthread.a, it's smaller than the DLL import lib, which is not right. I think the autotools stuff is missing something here. Check if adding -lpthread works, If so check your openmp specs file, I can't remember what its called, it probably did something weird for the static case. 2. In order to get the DLL installed into sysroot/bin where it belongs (for non-multilib setups), I passed the --bindir=sysroot/bin option to configure, but the dll was still placed in prefix/bin instead. I can move it over myself, but autotools can do this, so it really should be fixed there. Thanks! Yes, you can do that, but I'm trying to figure out how to fixup the install dir without breaking cross builds. if build==host, then append ../../bin to bindir, hmmm. Just fix the autotools --bindir option, so one can decide for oneself if it's needed/wanted. It's a custom step that may not be wanted everywhere you build winpthreads in that configuration. Change autoconf? Although I always have a hard time understanding your two-word replies, I assume you're saying that this would require patching autotools? This is not what I was steering at. All that would be logical is that the install directory for the winpthreads dll to listen to --bindir, so that the developer files can be installed in sysroot/target-triplet/ and the dll can be installed along with the other runtime dll's in sysroot/bin. Ruben Don't libraries go into libdir? So, wouldn't you want to pass --libdir on the configure line? No, DLLs don't go to prefix/lib, they go to prefix/bin. DLLs are not .so's or .dylib's or whatever. The DLL is already installed in a prefix/bin directory by default, that's not the problem. It's that GCC expects libpthread.a and pthread.h to be in sysroot/target-triple/include and lib, but when a user compiles a program that uses the pthreads DLL (s)he'd need to add sysroot/target-triple/bin to PATH, which also contains the binutils tools (which AFAIK aren't the ones you're supposed to be running). I'd like to use --bindir=sysroot/bin (or any other option you think is most suited for this) to change the install directory of the DLL. If this is not possible with autotools it's an oversight, then I'll just manually move the DLL, but this shouldn't be strictly necessary with all the options autotools provides. I just checked GMP, and it doesn't listen either. So I guess this might be a autotools problem that either requires copying/moving manually or a winpthreads configury local workaround. Ruben No, the DLL should be going into sysroot by right, since that is where the target file system lives. On Windows, this sysroot thing would be a bit weird for native gcc, perhaps you can try what mingw.org does on MSYS, just use --prefix=/mingw. signature.asc Description: OpenPGP digital signature -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] two winpthreads build machinery issues
2011/8/16 JonY jo...@users.sourceforge.net: On 8/16/2011 23:23, Ruben Van Boxem wrote: 2011/8/16 NightStrike nightstr...@gmail.com: On Tue, Aug 16, 2011 at 10:52 AM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2011/8/16 NightStrike nightstr...@gmail.com: On Tue, Aug 16, 2011 at 10:17 AM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Op 16 aug. 2011 16:13 schreef JonY jo...@users.sourceforge.net het volgende: On 8/16/2011 20:57, Ruben Van Boxem wrote: Hi, Since Kai fixed the winpthreads/libgomp problem (Kai, you are a hero!), I have been trying to finalize the winpthreads build stuff in my scripts and testing, which lead to two issues: 1. I can't link to winpthreads statically, better said, if I compile the small openmp test program with the added -static option, I get undefined references to pthreads functions. When I check the size of the static libpthread.a, it's smaller than the DLL import lib, which is not right. I think the autotools stuff is missing something here. Check if adding -lpthread works, If so check your openmp specs file, I can't remember what its called, it probably did something weird for the static case. 2. In order to get the DLL installed into sysroot/bin where it belongs (for non-multilib setups), I passed the --bindir=sysroot/bin option to configure, but the dll was still placed in prefix/bin instead. I can move it over myself, but autotools can do this, so it really should be fixed there. Thanks! Yes, you can do that, but I'm trying to figure out how to fixup the install dir without breaking cross builds. if build==host, then append ../../bin to bindir, hmmm. Just fix the autotools --bindir option, so one can decide for oneself if it's needed/wanted. It's a custom step that may not be wanted everywhere you build winpthreads in that configuration. Change autoconf? Although I always have a hard time understanding your two-word replies, I assume you're saying that this would require patching autotools? This is not what I was steering at. All that would be logical is that the install directory for the winpthreads dll to listen to --bindir, so that the developer files can be installed in sysroot/target-triplet/ and the dll can be installed along with the other runtime dll's in sysroot/bin. Ruben Don't libraries go into libdir? So, wouldn't you want to pass --libdir on the configure line? No, DLLs don't go to prefix/lib, they go to prefix/bin. DLLs are not .so's or .dylib's or whatever. The DLL is already installed in a prefix/bin directory by default, that's not the problem. It's that GCC expects libpthread.a and pthread.h to be in sysroot/target-triple/include and lib, but when a user compiles a program that uses the pthreads DLL (s)he'd need to add sysroot/target-triple/bin to PATH, which also contains the binutils tools (which AFAIK aren't the ones you're supposed to be running). I'd like to use --bindir=sysroot/bin (or any other option you think is most suited for this) to change the install directory of the DLL. If this is not possible with autotools it's an oversight, then I'll just manually move the DLL, but this shouldn't be strictly necessary with all the options autotools provides. I just checked GMP, and it doesn't listen either. So I guess this might be a autotools problem that either requires copying/moving manually or a winpthreads configury local workaround. Ruben No, the DLL should be going into sysroot by right, since that is where the target file system lives. On Windows, this sysroot thing would be a bit weird for native gcc, perhaps you can try what mingw.org does on MSYS, just use --prefix=/mingw. No thanks, and it won't work. If you're building GCC with libgomp etc., it wants pthread.h and libpthread[.dll].a to be in prefix/target-triplet, so that would be a no go. This might only be in the case of a multilib build, which needs to be taken into account. And I don't want to clutter the main sysroot's include and lib if I don't have to. That's where GCC stuff lives. I'll just move the dll in a manual step after make install. Ruben -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] two winpthreads build machinery issues
So I applied change to 4.7 at revision 177789. I am not quite sure if this modification to 4.6 (and later) is worth doing. It would be better to merge here from trunk (on demand) the changes for -pthread and of this revision back. It should apply cleanly AFAICS. To choose here -lpthread can cause other issues, which I don't want to introduce on this branch. In fact I like it more that officially libgomp support gets added for mingw targets with the 4.7 version. Regards, Kai 2011/8/16 JonY jo...@users.sourceforge.net: On 8/16/2011 23:51, Ruben Van Boxem wrote: 2011/8/16 JonY jo...@users.sourceforge.net: On 8/16/2011 23:23, Ruben Van Boxem wrote: 2011/8/16 NightStrike nightstr...@gmail.com: On Tue, Aug 16, 2011 at 10:52 AM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2011/8/16 NightStrike nightstr...@gmail.com: On Tue, Aug 16, 2011 at 10:17 AM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Op 16 aug. 2011 16:13 schreef JonY jo...@users.sourceforge.net het volgende: On 8/16/2011 20:57, Ruben Van Boxem wrote: Hi, Since Kai fixed the winpthreads/libgomp problem (Kai, you are a hero!), I have been trying to finalize the winpthreads build stuff in my scripts and testing, which lead to two issues: 1. I can't link to winpthreads statically, better said, if I compile the small openmp test program with the added -static option, I get undefined references to pthreads functions. When I check the size of the static libpthread.a, it's smaller than the DLL import lib, which is not right. I think the autotools stuff is missing something here. Check if adding -lpthread works, If so check your openmp specs file, I can't remember what its called, it probably did something weird for the static case. 2. In order to get the DLL installed into sysroot/bin where it belongs (for non-multilib setups), I passed the --bindir=sysroot/bin option to configure, but the dll was still placed in prefix/bin instead. I can move it over myself, but autotools can do this, so it really should be fixed there. Thanks! Yes, you can do that, but I'm trying to figure out how to fixup the install dir without breaking cross builds. if build==host, then append ../../bin to bindir, hmmm. Just fix the autotools --bindir option, so one can decide for oneself if it's needed/wanted. It's a custom step that may not be wanted everywhere you build winpthreads in that configuration. Change autoconf? Although I always have a hard time understanding your two-word replies, I assume you're saying that this would require patching autotools? This is not what I was steering at. All that would be logical is that the install directory for the winpthreads dll to listen to --bindir, so that the developer files can be installed in sysroot/target-triplet/ and the dll can be installed along with the other runtime dll's in sysroot/bin. Ruben Don't libraries go into libdir? So, wouldn't you want to pass --libdir on the configure line? No, DLLs don't go to prefix/lib, they go to prefix/bin. DLLs are not .so's or .dylib's or whatever. The DLL is already installed in a prefix/bin directory by default, that's not the problem. It's that GCC expects libpthread.a and pthread.h to be in sysroot/target-triple/include and lib, but when a user compiles a program that uses the pthreads DLL (s)he'd need to add sysroot/target-triple/bin to PATH, which also contains the binutils tools (which AFAIK aren't the ones you're supposed to be running). I'd like to use --bindir=sysroot/bin (or any other option you think is most suited for this) to change the install directory of the DLL. If this is not possible with autotools it's an oversight, then I'll just manually move the DLL, but this shouldn't be strictly necessary with all the options autotools provides. I just checked GMP, and it doesn't listen either. So I guess this might be a autotools problem that either requires copying/moving manually or a winpthreads configury local workaround. Ruben No, the DLL should be going into sysroot by right, since that is where the target file system lives. On Windows, this sysroot thing would be a bit weird for native gcc, perhaps you can try what mingw.org does on MSYS, just use --prefix=/mingw. No thanks, and it won't work. If you're building GCC with libgomp etc., it wants pthread.h and libpthread[.dll].a to be in prefix/target-triplet, so that would be a no go. This might only be in the case of a multilib build, which needs to be taken into account. And I don't want to clutter the main sysroot's include and lib if I don't have to. That's where GCC stuff lives. I'll just move the dll in a manual step after make install. Ruben No, I meant the entire toolchain, as far as I know, mingw.org doesn't do --with-sysroot, just --prefix=/mingw for their native gcc. -- uberSVN's rich system and user
Re: [Mingw-w64-public] two winpthreads build machinery issues
2011/8/16 Kai Tietz ktiet...@googlemail.com: So I applied change to 4.7 at revision 177789. I am not quite sure if this modification to 4.6 (and later) is worth doing. It would be better to merge here from trunk (on demand) the changes for -pthread and of this revision back. It should apply cleanly AFAICS. To choose here -lpthread can cause other issues, which I don't want to introduce on this branch. In fact I like it more that officially libgomp support gets added for mingw targets with the 4.7 version. OK fair enough, then for GCC 4.6 and under, there won't be any -static linking with -fopenmp. Although I was under the impression this stuff already (should've worked). Ah wait, mingw.org provides a DLL-only pthreads-win32. Ugh... OK. Thanks for this! Ruben -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Darwin automated builds gone.
Hello, Due the recent number of builds for cygwin and linux, version 1.0 targeting win32 for darwin has disappear. Last file available was mingw-w32-1.0-bin_i686-darwin_20110429.tar.bz2 but seems is gone now. In the page, there are no more darwin builds available. Perhaps the buildbot is down? is there is something I can help with? Thank you. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
