Re: [Mingw-w64-public] [PATCH] Add some missing IMAGE_DLLCHARACTERISTICS_* constants
On Thu, May 28, 2015 at 6:51 PM, Jacek Caban ja...@codeweavers.com wrote: On 05/28/15 17:29, İsmail Dönmez wrote: On Thu, May 28, 2015 at 4:49 PM, Jacek Caban ja...@codeweavers.com wrote: On 05/28/15 11:06, İsmail Dönmez wrote: On Mon, May 25, 2015 at 7:47 PM, İsmail Dönmez ism...@donmez.ws wrote: Hi, . Noticed while trying to compile the application from http://blogs.msdn.com/b/oldnewthing/archive/2015/05/18/10615339.aspx . Patch attached. ping? Looks good to me. Could you please apply it? Thanks! I committed the change, but I noticed that you modified winnt.h from widl directory. I removed that part because that's just an internal side effect of importing it from Wine. The one we care about is in mingw-w64-headers/include. Btw, without winnt.h change, I still cannot compile the example program from http://blogs.msdn.com/b/oldnewthing/archive/2015/05/18/10615339.aspx so I think, it also should be applied. Regards, ismail -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] build: autoconf: enable multiple tools and libs
I did respond, and your patch brings things steps away from usable,
not closer. Check your email, I explained how to do what you are
trying to do. Your patch is a really bad patch. Sorry.
On Thu, May 28, 2015 at 9:53 AM, Alon Bar-Lev alon.bar...@gmail.com wrote:
Quoting my-self:
Hi,
I do not have a response from NightStrike, this patch set is modifying the
top level autoconf to work properly. Can you please consider it?
For all who are not using the top level autoconf, it should not matter, as
you do not use it anyway.
For these who are, it bring us one step closer to something that is usable.
Thanks,
Alon
On 4 May 2015 at 22:47, Alon Bar-Lev alon.bar...@gmail.com wrote:
this somewhat reduces the error checking, but makes code and usage nicer.
Signed-off-by: Alon Bar-Lev alon.bar...@gmail.com
---
configure.ac | 55 ---
1 file changed, 12 insertions(+), 43 deletions(-)
diff --git a/configure.ac b/configure.ac
index 468d1b1..1b59821 100644
--- a/configure.ac
+++ b/configure.ac
@@ -56,32 +56,12 @@ AC_ARG_WITH([libraries],
[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh,
winpthreads, or all])],
[],
[with_libraries=no])
-AS_CASE([$with_libraries],
- [yes|all],[
-with_libraries=libmangle,pseh,winpthreads
-with_libraries_winpthreads=yes
-with_libraries_mangle=yes
-with_libraries_pseh=yes],
- [libmangle],[
-with_libraries=libmangle
-with_libraries_winpthreads=no
-with_libraries_mangle=yes
-with_libraries_pseh=no],
- [pseh],[
-with_libraries=pseh
-with_libraries_winpthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=yes],
- [winpthreads],[
-with_libraries=winpthreads
-with_libraries_winpthreads=yes
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [no],[
-with_libraries_winpthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [MW64_OPTION_ERROR([with-libraries])])
+for l in winpthreads mangle pseh; do
+ res=`echo ${with_libraries} | grep $l /dev/null echo yes || echo
no`
+ AS_CASE([$with_libraries],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_libraries_$l], [res])
+done
AM_CONDITIONAL([LIBRARIES_MANGLE],[test x$with_libraries_mangle = xyes])
AM_CONDITIONAL([LIBRARIES_PSEH],[test x$with_libraries_pseh = xyes])
AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test x$with_libraries_winpthreads
= xyes])
@@ -96,23 +76,12 @@ AC_ARG_WITH([tools],
[Build the extra mingw-w64 tools, where ARG is one of gendef, genidl,
or all])],
[],
[with_tools=no])
-AS_CASE([$with_tools],
- [yes|all],[
-with_tools=gendef,genidl
-with_tools_gendef=yes
-with_tools_genidl=yes],
- [gendef],[
-with_tools=gendef
-with_tools_gendef=yes
-with_tools_genidl=no],
- [genidl],[
-with_tools=genidl
-with_tools_gendef=no
-with_tools_genidl=yes],
- [no],[
-with_tools_gendef=no
-with_tools_genidl=no],
- [MW64_OPTION_ERROR([with-tools])])
+for t in gendef genidl; do
+ res=`echo ${with_tools} | grep $t /dev/null echo yes || echo no`
+ AS_CASE([$with_tools],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_tools_$t], [res])
+done
AM_CONDITIONAL([TOOLS_GENDEF],[test x$with_tools_gendef = xyes])
AM_CONDITIONAL([TOOLS_GENIDL],[test x$with_tools_genidl = xyes])
AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
--
2.3.6
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] build: autoconf: enable multiple tools and libs
Sorry, I did search my mail and I did waited for your response, I also
ping you few times, including this week.
And apart of your statements that this is a bad patch, you do not
address the actual problem of building crt using older toolchain in
order to upgrade the crt.
Your statements are not helpful for me to understand what is wrong, I
did modify what I did understand from your general comments.
These patches are applied and used successfully in Gentoo now, and
provide working solution, I do need to understand what can be
improved, but telling me that these are bad patches while they solve
actual problem is not helpful.
Please help me to improve this.
On 28 May 2015 at 21:18, NightStrike nightstr...@gmail.com wrote:
I did respond, and your patch brings things steps away from usable,
not closer. Check your email, I explained how to do what you are
trying to do. Your patch is a really bad patch. Sorry.
On Thu, May 28, 2015 at 9:53 AM, Alon Bar-Lev alon.bar...@gmail.com wrote:
Quoting my-self:
Hi,
I do not have a response from NightStrike, this patch set is modifying the
top level autoconf to work properly. Can you please consider it?
For all who are not using the top level autoconf, it should not matter, as
you do not use it anyway.
For these who are, it bring us one step closer to something that is usable.
Thanks,
Alon
On 4 May 2015 at 22:47, Alon Bar-Lev alon.bar...@gmail.com wrote:
this somewhat reduces the error checking, but makes code and usage nicer.
Signed-off-by: Alon Bar-Lev alon.bar...@gmail.com
---
configure.ac | 55 ---
1 file changed, 12 insertions(+), 43 deletions(-)
diff --git a/configure.ac b/configure.ac
index 468d1b1..1b59821 100644
--- a/configure.ac
+++ b/configure.ac
@@ -56,32 +56,12 @@ AC_ARG_WITH([libraries],
[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh,
winpthreads, or all])],
[],
[with_libraries=no])
-AS_CASE([$with_libraries],
- [yes|all],[
-with_libraries=libmangle,pseh,winpthreads
-with_libraries_winpthreads=yes
-with_libraries_mangle=yes
-with_libraries_pseh=yes],
- [libmangle],[
-with_libraries=libmangle
-with_libraries_winpthreads=no
-with_libraries_mangle=yes
-with_libraries_pseh=no],
- [pseh],[
-with_libraries=pseh
-with_libraries_winpthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=yes],
- [winpthreads],[
-with_libraries=winpthreads
-with_libraries_winpthreads=yes
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [no],[
-with_libraries_winpthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [MW64_OPTION_ERROR([with-libraries])])
+for l in winpthreads mangle pseh; do
+ res=`echo ${with_libraries} | grep $l /dev/null echo yes || echo
no`
+ AS_CASE([$with_libraries],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_libraries_$l], [res])
+done
AM_CONDITIONAL([LIBRARIES_MANGLE],[test x$with_libraries_mangle = xyes])
AM_CONDITIONAL([LIBRARIES_PSEH],[test x$with_libraries_pseh = xyes])
AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test
x$with_libraries_winpthreads = xyes])
@@ -96,23 +76,12 @@ AC_ARG_WITH([tools],
[Build the extra mingw-w64 tools, where ARG is one of gendef, genidl,
or all])],
[],
[with_tools=no])
-AS_CASE([$with_tools],
- [yes|all],[
-with_tools=gendef,genidl
-with_tools_gendef=yes
-with_tools_genidl=yes],
- [gendef],[
-with_tools=gendef
-with_tools_gendef=yes
-with_tools_genidl=no],
- [genidl],[
-with_tools=genidl
-with_tools_gendef=no
-with_tools_genidl=yes],
- [no],[
-with_tools_gendef=no
-with_tools_genidl=no],
- [MW64_OPTION_ERROR([with-tools])])
+for t in gendef genidl; do
+ res=`echo ${with_tools} | grep $t /dev/null echo yes || echo no`
+ AS_CASE([$with_tools],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_tools_$t], [res])
+done
AM_CONDITIONAL([TOOLS_GENDEF],[test x$with_tools_gendef = xyes])
AM_CONDITIONAL([TOOLS_GENIDL],[test x$with_tools_genidl = xyes])
AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
--
2.3.6
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Re: [Mingw-w64-public] GCCG with C++11
On 05/28/2015 09:24 AM, Hotmail (ArbolOne) wrote: If I am not mistaken _MSC_VER = 1600 is the version that started implementing C++11. So, I test for that version of the compiler in my code, i.e. #ifdef _MSC_VER = 1600 #endif I would like to do the same for __GNUG__, but what version of g++ started implementing C++11? The standard specifies that implementations conforming to C++ 11 must define the __cplusplus macro to 201103L, and recommends that non-conforming compilers (presumably those that aim to be C++11 conforming but whose support is incomplete) should use a value with at most five decimal digits. C++ 98 defines __cplusplus to 199711L, and C++ 14 to 201402L. With that, the following should cover past and future cases: #if __cplusplus == 199711L // C++ 98 conforming implementation #elif __cplusplus == 201103L // C++ 11 conforming implementation #elif __cplusplus == 201402L // C++ 14 conforming implementation #elif __cplusplus 201402L // future C++ implementation #elif 0 __cplusplus __cplusplus 10L // non-conforming C++ implementation #else // not C++ or a non-conforming C++ implementation #endif Though it seems to me that the recommendation in the footnote below quoted from 16.8 Predefined Macros, blurs the distinction between incomplete C++ implementations targeting C++ 11 and 14 (and 17). 157) It is intended that future versions of this standard will replace the value of this macro with a greater value. Non-conforming compilers should use a value with at most five decimal digits. Martin -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCCG with C++11
On 05/28/2015 10:31 AM, Jonathan Wakely wrote: On 28 May 2015 at 16:51, Martin Sebor wrote: The standard specifies that implementations conforming to C++ 11 must define the __cplusplus macro to 201103L, and recommends that non-conforming compilers (presumably those that aim to be C++11 conforming but whose support is incomplete) should use a value with at most five decimal digits. C++ 98 defines __cplusplus to 199711L, and C++ 14 to 201402L. With that, the following should cover past and future cases: #if __cplusplus == 199711L // C++ 98 conforming implementation #elif __cplusplus == 201103L // C++ 11 conforming implementation #elif __cplusplus == 201402L // C++ 14 conforming implementation #elif __cplusplus 201402L // future C++ implementation #elif 0 __cplusplus __cplusplus 10L // non-conforming C++ implementation #else // not C++ or a non-conforming C++ implementation #endif Until GCC 4.7.0 __cplusplus was always defined to 1, even though C++11 support in 4.6.4 was OK, and C++98 support was mostly complete. Those versions would have to be handled under the 0 __cplusplus __cplusplus 10L block by either querying the __GNUC__ macros, along with others like it, and/or some implementation specific feature test macros(*). This approach is in line with the recommendation in the footnote but it highlights the problem of distinguishing between partial (even mostly complete) support for any of the existing versions of C++. Martin [*] The Feature Testing Recommendations For C++ proposal (N4440 being the latest I could find) tries to alleviate it by providing test macros for individual features. I know Clang implements parts of it but don't know what its status is in GCC. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCCG with C++11
I googled and found this: #if __cplusplus = 199711L #error This library needs at least a C++11 compliant compiler #endif On Thu, May 28, 2015 at 8:24 AM, Hotmail (ArbolOne) arbol...@hotmail.ca wrote: If I am not mistaken _MSC_VER = 1600 is the version that started implementing C++11. So, I test for that version of the compiler in my code, i.e. #ifdef _MSC_VER = 1600 #endif I would like to do the same for __GNUG__, but what version of g++ started implementing C++11? Thanks -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCCG with C++11
On 28 May 2015 at 18:22, Martin Sebor wrote: [*] The Feature Testing Recommendations For C++ proposal (N4440 being the latest I could find) tries to alleviate it by providing test macros for individual features. I know Clang implements parts of it but don't know what its status is in GCC. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html 4.9 and above define those macros. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [[ noreturn ]]
Read the error message and make your function never return. That is all. Paste a testcase next time. -- Best regards, lh_mouse 2015-05-29 - 发件人：Hotmail \(ArbolOne\) arbol...@hotmail.ca 发送日期：2015-05-29 10:46 收件人：gcc-help Mailing List,MinGW-64 Mailinglist 抄送： 主题：[Mingw-w64-public] [[ noreturn ]] Hi! When using this the [[ noreturn ]] attribute like this: - void f [[ noreturn ]] (); - I get a warning that reads: warning: 'noreturn' function does return ( http://www.stroustrup.com/C++11FAQ.html#attributes ) What can I do to remove this warning? Thanks -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [[ noreturn ]]
Hi! When using this the [[ noreturn ]] attribute like this: - void f [[ noreturn ]] (); - I get a warning that reads: warning: 'noreturn' function does return ( http://www.stroustrup.com/C++11FAQ.html#attributes ) What can I do to remove this warning? Thanks -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Preferred build system, installation methods and download page links.
Hi, I had been using the builds as a part of MSYS2 for a while now, and I believe this is the most robust and easiest way to install mingw-w64. Also, due to the inherent nature of the system, it also provides the most up-to-date builds on par with the Linux builds. The build I see on winbuilds is actually older than the one on MSYS2. I'm just wondering if it would be in the best interests of the entire community that MSYS2 be promoted as the preferred build from the website instead of winbuilds. While win-builds seem to provide a GUI and switchable toolchain, MSYS2 just feels a lot more robust with, especially pacman. Pacman integration at its crux, seems to be the most brilliant package management strategy for windows, so far. By the looks of the websites, I believe I can assume that the maintainers of winbuilds and mingw-w64 are the same or perhaps at the least linked. But I would very much like to think that it would be better to focus the efforts on one if so, and perhaps may be even implement winbuilds over msys2's excellent convergence work. But until then, I think it may make a lot more sense to converge with MSYS2 for official sources, rather than use the winbuilds system. Windows GCC (MinGW) builds of libraries have historically been a pain, because of the numerous different possible configuration the default build could have had, and due to the nature of the various sources, and none to be so-called official (or at-least a de-facto standard). Having winbuilds, and MSYS2 could again promote such problems, while converging them could very easily become the de-facto standard. I'd like to hear what the maintainers' thought are on these. Regards, Prasanna V. Loganathar -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] how do I remove this window
On 20/05/15 23:50, Hotmail (ArbolOne) wrote: When running a Win32 program, I get a prompt window, how do I remove this window? Use -mwindows flag when linking, as explained in http://mingw.org/wiki/FAQ#toc6 -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] I am in a in-path
On 28/05/15 00:15, Hotmail (ArbolOne) wrote: This creates another problem, what if the exception is std::mem_alloc, I would ran out of memory, thus I wouldn't be able to create another object. You could use placement new and a custom memory pool of exception objects. Andrew. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add some missing IMAGE_DLLCHARACTERISTICS_* constants
On Mon, May 25, 2015 at 7:47 PM, İsmail Dönmez ism...@donmez.ws wrote: Hi, . Noticed while trying to compile the application from http://blogs.msdn.com/b/oldnewthing/archive/2015/05/18/10615339.aspx . Patch attached. ping? -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] I am in a in-path
On 28 May 2015 at 00:15, Hotmail (ArbolOne) wrote: I know, I know, this is not a C++ question, but, as I said, I am in a in-path, I don't know what to do in this case. I have no idea what an in-path is (impasse?) but you've sent another off-topic post that is not about GCC. For general programming questions please find somewhere like StackOverflow.com to seek help. This list is for questions about using GCC. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] I am in a in-path
... another off-topic ... ?? I think this is my second or third posting, but, hey! sorry for the posting and thanks for the welcoming comments. Yes, it is impasse. That's one of the problem of being multilingual, sometimes two or three languages get mixed and this kind of mistakes occur, most often when one gets as old as I am, he he he. I really appreciate your dazzling observations, please, keep up the good work!! -Original Message- From: Jonathan Wakely Sent: Thursday, May 28, 2015 5:22 AM To: Hotmail (ArbolOne) Cc: gcc-help Mailing List ; MinGW-64 Mailinglist Subject: Re: I am in a in-path On 28 May 2015 at 00:15, Hotmail (ArbolOne) wrote: I know, I know, this is not a C++ question, but, as I said, I am in a in-path, I don't know what to do in this case. I have no idea what an in-path is (impasse?) but you've sent another off-topic post that is not about GCC. For general programming questions please find somewhere like StackOverflow.com to seek help. This list is for questions about using GCC. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/2] build: autoconf: enable multiple tools and libs
Quoting my-self:
Hi,
I do not have a response from NightStrike, this patch set is modifying the
top level autoconf to work properly. Can you please consider it?
For all who are not using the top level autoconf, it should not matter, as
you do not use it anyway.
For these who are, it bring us one step closer to something that is usable.
Thanks,
Alon
On 4 May 2015 at 22:47, Alon Bar-Lev alon.bar...@gmail.com wrote:
this somewhat reduces the error checking, but makes code and usage nicer.
Signed-off-by: Alon Bar-Lev alon.bar...@gmail.com
---
configure.ac | 55 ---
1 file changed, 12 insertions(+), 43 deletions(-)
diff --git a/configure.ac b/configure.ac
index 468d1b1..1b59821 100644
--- a/configure.ac
+++ b/configure.ac
@@ -56,32 +56,12 @@ AC_ARG_WITH([libraries],
[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh,
winpthreads, or all])],
[],
[with_libraries=no])
-AS_CASE([$with_libraries],
- [yes|all],[
-with_libraries=libmangle,pseh,winpthreads
-with_libraries_winpthreads=yes
-with_libraries_mangle=yes
-with_libraries_pseh=yes],
- [libmangle],[
-with_libraries=libmangle
-with_libraries_winpthreads=no
-with_libraries_mangle=yes
-with_libraries_pseh=no],
- [pseh],[
-with_libraries=pseh
-with_libraries_winpthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=yes],
- [winpthreads],[
-with_libraries=winpthreads
-with_libraries_winpthreads=yes
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [no],[
-with_libraries_winpthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [MW64_OPTION_ERROR([with-libraries])])
+for l in winpthreads mangle pseh; do
+ res=`echo ${with_libraries} | grep $l /dev/null echo yes || echo no`
+ AS_CASE([$with_libraries],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_libraries_$l], [res])
+done
AM_CONDITIONAL([LIBRARIES_MANGLE],[test x$with_libraries_mangle = xyes])
AM_CONDITIONAL([LIBRARIES_PSEH],[test x$with_libraries_pseh = xyes])
AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test x$with_libraries_winpthreads
= xyes])
@@ -96,23 +76,12 @@ AC_ARG_WITH([tools],
[Build the extra mingw-w64 tools, where ARG is one of gendef, genidl, or
all])],
[],
[with_tools=no])
-AS_CASE([$with_tools],
- [yes|all],[
-with_tools=gendef,genidl
-with_tools_gendef=yes
-with_tools_genidl=yes],
- [gendef],[
-with_tools=gendef
-with_tools_gendef=yes
-with_tools_genidl=no],
- [genidl],[
-with_tools=genidl
-with_tools_gendef=no
-with_tools_genidl=yes],
- [no],[
-with_tools_gendef=no
-with_tools_genidl=no],
- [MW64_OPTION_ERROR([with-tools])])
+for t in gendef genidl; do
+ res=`echo ${with_tools} | grep $t /dev/null echo yes || echo no`
+ AS_CASE([$with_tools],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_tools_$t], [res])
+done
AM_CONDITIONAL([TOOLS_GENDEF],[test x$with_tools_gendef = xyes])
AM_CONDITIONAL([TOOLS_GENIDL],[test x$with_tools_genidl = xyes])
AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
--
2.3.6
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 1/2] build: autoconf: support winpthreads library
Hi, I do not have a response from NightStrike, this patch set is modifying the top level autoconf to work properly. Can you please consider it? For all who are not using the top level autoconf, it should not matter, as you do not use it anyway. For these who are, it bring us one step closer to something that is usable. Thanks, Alon On 4 May 2015 at 22:47, Alon Bar-Lev alon.bar...@gmail.com wrote: Signed-off-by: Alon Bar-Lev alon.bar...@gmail.com --- Makefile.am | 6 +- configure.ac | 15 +-- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index 26a7606..308b6fd 100644 --- a/Makefile.am +++ b/Makefile.am @@ -14,6 +14,10 @@ if LIBRARIES_PSEH MAYBE_LIBRARIES_PSEH = mingw-w64-libraries/pseh endif +if LIBRARIES_WINPTHREADS + MAYBE_LIBRARIES_WINPTHREADS = mingw-w64-libraries/winpthreads +endif + if TOOLS_GENDEF MAYBE_TOOLS_GENDEF = mingw-w64-tools/gendef endif @@ -22,7 +26,7 @@ if TOOLS_GENIDL MAYBE_TOOLS_GENIDL = mingw-w64-tools/genidl endif -SUBDIRS = $(MAYBE_HEADER) $(MAYBE_CRT) $(MAYBE_LIBRARIES_MANGLE) $(MAYBE_LIBRARIES_PSEH) $(MAYBE_TOOLS_GENDEF) $(MAYBE_TOOLS_GENIDL) +SUBDIRS = $(MAYBE_HEADER) $(MAYBE_CRT) $(MAYBE_LIBRARIES_MANGLE) $(MAYBE_LIBRARIES_PSEH) $(MAYBE_LIBRARIES_WINPTHREADS) $(MAYBE_TOOLS_GENDEF) $(MAYBE_TOOLS_GENIDL) DISTCHECK_CONFIGURE_FLAGS = --with-headers --with-crt --with-libraries=all --with-tools=all diff --git a/configure.ac b/configure.ac index 4bb3926..468d1b1 100644 --- a/configure.ac +++ b/configure.ac @@ -53,30 +53,41 @@ AC_MSG_RESULT([$with_crt]) AC_MSG_CHECKING([whether to build the optional libraries]) AC_ARG_WITH([libraries], [AS_HELP_STRING([--with-libraries=ARG], -[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh, or all])], +[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh, winpthreads, or all])], [], [with_libraries=no]) AS_CASE([$with_libraries], [yes|all],[ -with_libraries=libmangle,pseh +with_libraries=libmangle,pseh,winpthreads +with_libraries_winpthreads=yes with_libraries_mangle=yes with_libraries_pseh=yes], [libmangle],[ with_libraries=libmangle +with_libraries_winpthreads=no with_libraries_mangle=yes with_libraries_pseh=no], [pseh],[ with_libraries=pseh +with_libraries_winpthreads=no with_libraries_mangle=no with_libraries_pseh=yes], + [winpthreads],[ +with_libraries=winpthreads +with_libraries_winpthreads=yes +with_libraries_mangle=no +with_libraries_pseh=no], [no],[ +with_libraries_winpthreads=no with_libraries_mangle=no with_libraries_pseh=no], [MW64_OPTION_ERROR([with-libraries])]) AM_CONDITIONAL([LIBRARIES_MANGLE],[test x$with_libraries_mangle = xyes]) AM_CONDITIONAL([LIBRARIES_PSEH],[test x$with_libraries_pseh = xyes]) +AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test x$with_libraries_winpthreads = xyes]) AM_COND_IF([LIBRARIES_MANGLE],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/libmangle])]) AM_COND_IF([LIBRARIES_PSEH],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/pseh])]) +AM_COND_IF([LIBRARIES_WINPTHREADS],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/winpthreads])]) AC_MSG_RESULT([$with_libraries]) AC_MSG_CHECKING([whether to build the optional tools]) -- 2.3.6 -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add some missing IMAGE_DLLCHARACTERISTICS_* constants
On Thu, May 28, 2015 at 6:51 PM, Jacek Caban ja...@codeweavers.com wrote: On 05/28/15 17:29, İsmail Dönmez wrote: On Thu, May 28, 2015 at 4:49 PM, Jacek Caban ja...@codeweavers.com wrote: On 05/28/15 11:06, İsmail Dönmez wrote: On Mon, May 25, 2015 at 7:47 PM, İsmail Dönmez ism...@donmez.ws wrote: Hi, . Noticed while trying to compile the application from http://blogs.msdn.com/b/oldnewthing/archive/2015/05/18/10615339.aspx . Patch attached. ping? Looks good to me. Could you please apply it? Thanks! I committed the change, but I noticed that you modified winnt.h from widl directory. I removed that part because that's just an internal side effect of importing it from Wine. The one we care about is in mingw-w64-headers/include. Thanks! Also, I can see that we already forked ddk fro ReactOS, but it would be nice to contribute the change to them. I'll send a patch to them too. ismail -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCCG with C++11
On 28 May 2015 at 16:51, Martin Sebor wrote: The standard specifies that implementations conforming to C++ 11 must define the __cplusplus macro to 201103L, and recommends that non-conforming compilers (presumably those that aim to be C++11 conforming but whose support is incomplete) should use a value with at most five decimal digits. C++ 98 defines __cplusplus to 199711L, and C++ 14 to 201402L. With that, the following should cover past and future cases: #if __cplusplus == 199711L // C++ 98 conforming implementation #elif __cplusplus == 201103L // C++ 11 conforming implementation #elif __cplusplus == 201402L // C++ 14 conforming implementation #elif __cplusplus 201402L // future C++ implementation #elif 0 __cplusplus __cplusplus 10L // non-conforming C++ implementation #else // not C++ or a non-conforming C++ implementation #endif Until GCC 4.7.0 __cplusplus was always defined to 1, even though C++11 support in 4.6.4 was OK, and C++98 support was mostly complete. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
Hi, This worked, the program compiles fine now. It crashes with a SegFault shortly after starting a new thread (via QThread), with a message: RTTI symbol not found for class 'SimClientPrivate' Are there incompatibilities of flto and cases where it cannot work? Thanks FWIW, you can try moving virtual function definitions out of header files, as defining virtual functions inside headers is generally a bad idea. (The story is much longer than that. Since the RTTI data of a polymorphic class is linked/exported/whatever with one of its virtual functions, specific mechanisms that rely on RTTI - dynamic_cast, exceptions, etc - might fail if RTTI of the same class is used across dynami clibrary boundaries.) -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCCG with C++11
http://en.cppreference.com/w/cpp/compiler_support Function testing macros: __GNUC__ and __GNUC_MINOR__ Example: #if __GNUC__ * 100 + __GNUC_MINOR__ = 407 // compile iff we are on g++ 4.7 or later -- Best regards, lh_mouse 2015-05-28 - 发件人：Hotmail \(ArbolOne\) arbol...@hotmail.ca 发送日期：2015-05-28 23:24 收件人：gcc-help Mailing List,MinGW-64 Mailinglist 抄送： 主题：[Mingw-w64-public] GCCG with C++11 If I am not mistaken _MSC_VER = 1600 is the version that started implementing C++11. So, I test for that version of the compiler in my code, i.e. #ifdef _MSC_VER = 1600 #endif I would like to do the same for __GNUG__, but what version of g++ started implementing C++11? Thanks -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] GCCG with C++11
If I am not mistaken _MSC_VER = 1600 is the version that started implementing C++11. So, I test for that version of the compiler in my code, i.e. #ifdef _MSC_VER = 1600 #endif I would like to do the same for __GNUG__, but what version of g++ started implementing C++11? Thanks -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] GCCG with C++11
On 28 May 2015 at 16:24, Hotmail (ArbolOne) arbol...@hotmail.ca wrote: If I am not mistaken _MSC_VER = 1600 is the version that started implementing C++11. So, I test for that version of the compiler in my code, i.e. #ifdef _MSC_VER = 1600 #endif I would like to do the same for __GNUG__, but what version of g++ started implementing C++11? 4.3 (see https://gcc.gnu.org/projects/cxx0x.html) but it's not much use knowing when support started appearing if you need to use a feature that wasn't supported until later. GCC 4.8.1 has complete C++11 language support, 5.1 has complete C++11 library support. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add some missing IMAGE_DLLCHARACTERISTICS_* constants
On Thu, May 28, 2015 at 4:49 PM, Jacek Caban ja...@codeweavers.com wrote: On 05/28/15 11:06, İsmail Dönmez wrote: On Mon, May 25, 2015 at 7:47 PM, İsmail Dönmez ism...@donmez.ws wrote: Hi, . Noticed while trying to compile the application from http://blogs.msdn.com/b/oldnewthing/archive/2015/05/18/10615339.aspx . Patch attached. ping? Looks good to me. Could you please apply it? Thanks! -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Add some missing IMAGE_DLLCHARACTERISTICS_* constants
On 05/28/15 17:29, İsmail Dönmez wrote: On Thu, May 28, 2015 at 4:49 PM, Jacek Caban ja...@codeweavers.com wrote: On 05/28/15 11:06, İsmail Dönmez wrote: On Mon, May 25, 2015 at 7:47 PM, İsmail Dönmez ism...@donmez.ws wrote: Hi, . Noticed while trying to compile the application from http://blogs.msdn.com/b/oldnewthing/archive/2015/05/18/10615339.aspx . Patch attached. ping? Looks good to me. Could you please apply it? Thanks! I committed the change, but I noticed that you modified winnt.h from widl directory. I removed that part because that's just an internal side effect of importing it from Wine. The one we care about is in mingw-w64-headers/include. Also, I can see that we already forked ddk fro ReactOS, but it would be nice to contribute the change to them. Cheers, Jacek -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
