Re: [Mingw-w64-public] End of rubenvb builds
Hi, On Fri, Jul 12, 2013, Jon wrote: On Fri, 12 Jul 2013 19:43:04 +0200 Kai Tietz ktiet...@googlemail.com wrote: a) yes, b) yes (we need people in charge for that and doing this reliable), c) yes, we are actual in discussion with mingw-builds venture to go together (and/or co-operate more closely). Or say The current situation is fine; mingw-w64 doesn't need an official toolchain. No, we should provide Windows native pre-build toolchain Fantastic. These days I don't get to contribute to OSS as much as I'd like, but if it would be useful, I'll carve out time to test/provide feedback on any toolchain build tool you and the mingw-builds team come up with. I'm fixated by easy-to-use port-like build automation tools that do the typical cycle of download - verify - patch - configure - build - stage - package and am continuously toying with one of my own little monsters for building common libs with mingw-w64: https://github.com/jonforums/buildlets So, I'm curious on what you guys are building and would like to help, even if it's just easy-of-use testing of the build tool. Allow me to mention yypkg again: http://yypkg.org/mingw-builds/ There are almost 70 packages, the website infrastructure is up, the package management is working and its infrastructure is up, the source-control infrastructure is also up. Everything is open and reproducible except for the download sources part for which I have a proper solution only since wednesday. The user aspect is documented and the packager one is partly-documented. If this gives a better idea of the current state, my TODO for this week-end and the next few days is: - update software to what has gotten in slackware-current - finish packaging sdl - package dbus - package ffmpeg - package gnustep which will help test the objc toolchain - patch bsdtar/libarchive to handle symlinks in packages more gracefully (symlinks if running with admin rights, junctions for dirs and copy for files otherwise; or something like that) (I'm trying to get sdl, dbus, ffmpeg and gnustep fairly quickly because they've been requested by people) PS: despite being named mingw-builds, this has nothing to do with the project on sf.net; mingw-builds is not a very specific name and I derived it from SlackBuilds: slackware's build scripts. (I plan on trying to find another name though) -- Adrien Nader -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
- package gnustep which will help test the objc toolchain Have you seen http://www.cocotron.org/ too? On Sat, Jul 13, 2013 at 12:22 PM, Adrien Nader adr...@notk.org wrote: Hi, On Fri, Jul 12, 2013, Jon wrote: On Fri, 12 Jul 2013 19:43:04 +0200 Kai Tietz ktiet...@googlemail.com wrote: a) yes, b) yes (we need people in charge for that and doing this reliable), c) yes, we are actual in discussion with mingw-builds venture to go together (and/or co-operate more closely). Or say The current situation is fine; mingw-w64 doesn't need an official toolchain. No, we should provide Windows native pre-build toolchain Fantastic. These days I don't get to contribute to OSS as much as I'd like, but if it would be useful, I'll carve out time to test/provide feedback on any toolchain build tool you and the mingw-builds team come up with. I'm fixated by easy-to-use port-like build automation tools that do the typical cycle of download - verify - patch - configure - build - stage - package and am continuously toying with one of my own little monsters for building common libs with mingw-w64: https://github.com/jonforums/buildlets So, I'm curious on what you guys are building and would like to help, even if it's just easy-of-use testing of the build tool. Allow me to mention yypkg again: http://yypkg.org/mingw-builds/ There are almost 70 packages, the website infrastructure is up, the package management is working and its infrastructure is up, the source-control infrastructure is also up. Everything is open and reproducible except for the download sources part for which I have a proper solution only since wednesday. The user aspect is documented and the packager one is partly-documented. If this gives a better idea of the current state, my TODO for this week-end and the next few days is: - update software to what has gotten in slackware-current - finish packaging sdl - package dbus - package ffmpeg - package gnustep which will help test the objc toolchain - patch bsdtar/libarchive to handle symlinks in packages more gracefully (symlinks if running with admin rights, junctions for dirs and copy for files otherwise; or something like that) (I'm trying to get sdl, dbus, ffmpeg and gnustep fairly quickly because they've been requested by people) PS: despite being named mingw-builds, this has nothing to do with the project on sf.net; mingw-builds is not a very specific name and I derived it from SlackBuilds: slackware's build scripts. (I plan on trying to find another name though) -- Adrien Nader -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Sat, Jul 13, 2013, Ray Donnelly wrote: - package gnustep which will help test the objc toolchain Have you seen http://www.cocotron.org/ too? I hadn't. It's interesting but at the same time, I'm a bit worried because they mention patching ld and gcc. =/ In any case, I'll have a look at it. Thanks. Btw, I'm looking for software using Objc++, Java, Ada, Fortran. Even when the build doesn't fail, there's no guarantee the toolchains work: last time I tried, the gcj build succeeded but the final package was missing almost everything as far as I could tell. -- Adrien Nader -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange
Erik van Pienbroek schreef op do 23-05-2013 om 23:29 [+0200]: Hi, During review of one of our Fedora packages we noticed an unexpected change in behavior in recent mingw-w64 trunk snapshots. We noticed that several libraries which were built against recent mingw-w64 trunk snapshots suddenly started to export the symbols _InterlockedCompareExchange and InterlockedCompareExchange@12 in their shared libraries. Just a heads up that this regression is resolved now in mingw-w64 trunk. This is probably due to r5949 which was committed today (which changes the way the Interlocked symbols are implemented in mingw-w4). In Fedora we've dropped our local patch which was used to temporary workaround the issue. Regards, Erik van Pienbroek Fedora MinGW SIG -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On Wed, Jul 10, 2013 at 5:30 PM, Jon jon.for...@gmail.com wrote: ...SNIP... But interpreting or implying or inferring is not useful. Explicit clarification from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why this hasn't happened is that both already have too much on their plate and don't want to set the expectation that either will be responsible for implementing and maintaining an official toolchain like JonY appears (aweome) to be doing at http://cygwin.mirrors.pair.com/release/gcc4/ The old speak-up-and-get-stuck-with-it paradox ;) Thoughts? Jon Speak-up-and-get-stuck-with-it ;) -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [Patch] __readfsbyte, __writefsbyte, __readgsbyte, __writegsbyte, etc
1) Move these functions to intrin-impl.h:
__readfsbyte, __readfsword, __readfsdword
__writefsbyte, __writefsword, __writefsdword
__readgsbyte, __readgsword, __readgsdword, __readgsqword
__writegsbyte, __writegsword, __writegsdword, __writegsqword
2) Update inline asm code:
*a) Change __write* so Data is an input. Without this, the wrong
value gets written.*
/b) Change __write* routines so they are NOT volatile./
c) Change __write* so Data uses ri constraint for
(potentially)(slightly) better performance.
d) Change __read* so they are not volatile.
e) Change __read* so offset is an input param
f) Support both att and intel asm formats for both __read* and __write*
3) Change NtCurrentTeb, GetCurrentFiber, and GetFiberData to use
existing routines instead of inline asm.
dw
Index: mingw-w64-crt/intrincs/currentfiber.c
===
--- mingw-w64-crt/intrincs/currentfiber.c (revision 5948)
+++ mingw-w64-crt/intrincs/currentfiber.c (working copy)
@@ -1,3 +1,5 @@
+/* todo - delete this file. This is not an intrinsic. It is only available
thru winnt.h
+
#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif
@@ -16,3 +18,4 @@
#endif
}
+*/
Index: mingw-w64-crt/intrincs/currentteb.c
===
--- mingw-w64-crt/intrincs/currentteb.c (revision 5948)
+++ mingw-w64-crt/intrincs/currentteb.c (working copy)
@@ -1,3 +1,5 @@
+/* todo - delete this file. This is not an intrinsic. It is only available
thru winnt.h
+
#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif
@@ -19,3 +21,4 @@
}
#endif
+*/
Index: mingw-w64-crt/intrincs/fiberdata.c
===
--- mingw-w64-crt/intrincs/fiberdata.c (revision 5948)
+++ mingw-w64-crt/intrincs/fiberdata.c (working copy)
@@ -1,3 +1,5 @@
+/* todo - delete this file. This is not an intrinsic. It is only available
thru winnt.h
+
#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif
@@ -16,4 +18,4 @@
return ret;
#endif
}
-
+*/
Index: mingw-w64-crt/intrincs/readfsbyte.c
===
--- mingw-w64-crt/intrincs/readfsbyte.c (revision 5948)
+++ mingw-w64-crt/intrincs/readfsbyte.c (working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___readfsbyte // Causes code generation in
intrin-impl.h
+
#include intrin.h
-
-/* for x86 only */
-unsigned char __readfsbyte(unsigned __LONG32 Offset)
-{
- unsigned char ret;
- __asm__ volatile (movb %%fs:%1,%0
- : =r (ret) ,=m ((*(volatile __LONG32 *) Offset)));
- return ret;
-}
-
Index: mingw-w64-crt/intrincs/readfsdword.c
===
--- mingw-w64-crt/intrincs/readfsdword.c(revision 5948)
+++ mingw-w64-crt/intrincs/readfsdword.c(working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___readfsdword // Causes code generation in
intrin-impl.h
+
#include intrin.h
-
-/* for x86 only */
-unsigned __LONG32 __readfsdword(unsigned __LONG32 Offset)
-{
- unsigned __LONG32 ret;
- __asm__ volatile (movl %%fs:%1,%0
- : =r (ret) ,=m ((*(volatile __LONG32 *) Offset)));
- return ret;
-}
-
Index: mingw-w64-crt/intrincs/readfsword.c
===
--- mingw-w64-crt/intrincs/readfsword.c (revision 5948)
+++ mingw-w64-crt/intrincs/readfsword.c (working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___readfsword // Causes code generation in
intrin-impl.h
+
#include intrin.h
-
-/* for x86 only */
-unsigned short __readfsword(unsigned __LONG32 Offset)
-{
- unsigned short ret;
- __asm__ volatile (movw %%fs:%1,%0
- : =r (ret) ,=m ((*(volatile __LONG32 *) Offset)));
- return ret;
-}
-
Index: mingw-w64-crt/intrincs/readgsbyte.c
===
--- mingw-w64-crt/intrincs/readgsbyte.c (revision 5948)
+++ mingw-w64-crt/intrincs/readgsbyte.c (working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___readgsbyte // Causes code generation in
intrin-impl.h
+
#include intrin.h
-
-/* for __x86_64 only */
-unsigned char __readgsbyte(unsigned __LONG32 Offset)
-{
- unsigned char ret;
- __asm__ volatile (movb %%gs:%1,%0
- : =r (ret) ,=m ((*(volatile __LONG32 *) (unsigned __int64) Offset)));
- return ret;
-}
-
Index: mingw-w64-crt/intrincs/readgsdword.c
===
--- mingw-w64-crt/intrincs/readgsdword.c(revision 5948)
+++ mingw-w64-crt/intrincs/readgsdword.c(working copy)
@@ -1,11 +1,4 @@
+#define __INTRINSIC_ONLYSPECIAL
+#define __INTRINSIC_SPECIAL___readgsdword // Causes code generation in
intrin-impl.h
+
#include intrin.h
-
-/* for
Re: [Mingw-w64-public] End of rubenvb builds
On Sat, Jul 13, 2013, Baruch Burstein wrote: On Wed, Jul 10, 2013 at 5:30 PM, Jon jon.for...@gmail.com wrote: But interpreting or implying or inferring is not useful. Explicit clarification from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why this hasn't happened is that both already have too much on their plate and don't want to set the expectation that either will be responsible for implementing and maintaining an official toolchain like JonY appears (aweome) to be doing at http://cygwin.mirrors.pair.com/release/gcc4/ The old speak-up-and-get-stuck-with-it paradox ;) Thoughts? It takes an awful lot of time. If you reach 100 packages (half of fedora or opensuse) and each package gets updated once every 6 months and it takes 30 minutes (when everything goes well), you're already looking at more than one hour per week. -- Adrien Nader -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ 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] __readfsbyte, __writefsbyte, __readgsbyte, __writegsbyte, etc
Hi patch looks ok to me. Beside one nit. Point 3 should not force none-inline version. Please expain why you think that is required. Kai Am 13.07.2013 15:11 schrieb dw limegreenso...@yahoo.com: 1) Move these functions to intrin-impl.h: __readfsbyte, __readfsword, __readfsdword __writefsbyte, __writefsword, __writefsdword __readgsbyte, __readgsword, __readgsdword, __readgsqword __writegsbyte, __writegsword, __writegsdword, __writegsqword 2) Update inline asm code: *a) Change __write* so Data is an input. Without this, the wrong value gets written.* *b) Change __write* routines so they are NOT volatile.* c) Change __write* so Data uses ri constraint for (potentially)(slightly) better performance. d) Change __read* so they are not volatile. e) Change __read* so offset is an input param f) Support both att and intel asm formats for both __read* and __write* 3) Change NtCurrentTeb, GetCurrentFiber, and GetFiberData to use existing routines instead of inline asm. dw -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] strange gcc 4.8 32bit windows target DLL behaviour
On Thu, Jul 4, 2013 at 8:40 PM, Dongsheng Song dongsheng.s...@gmail.com wrote: 于 2013/7/4 17:18, Kai Tietz 写道: 2013/7/4 Dongsheng Song dongsheng.s...@gmail.com: On 2013/7/4 4:49, Earnie Boyd wrote: On Wed, Jul 3, 2013 at 12:28 PM, Dongsheng Song wrote: On Thu, Jul 4, 2013 at 12:09 AM, Kai Tietz ktiet...@googlemail.com wrote: That is a known issue of ld for pe-coff. If at least one symbol is exported by dllexport, only those symbols are. If there is none, then all symbols getting exported. Just for curious, why 64 bit Windows target not affected ? Why gcc 4.7 32 bit Windows target not affected ? This behavior was added to binutils years ago by Danny Smith. I'm guessing your affect is a bit over stated. You can use --exclude-all-symbols to stop the automatic export or --export-all-symbols to always export all symbols. You'll also be interested in --warn-duplicate-exports. NO. automatic export do not explain the following test results: gcc-4.8, mingw-w64 trunk, binutils 2.23.2, 32 bit windows target: extra export InterlockedCompareExchange@12 gcc-4.8, mingw-w64 trunk, binutils 2.23.2, 64 bit windows target: OK gcc-4.7, mingw-w64 v2, binutils 2.23.2, 32 bit windows target: OK gcc-4.7, mingw-w64 v2, binutils 2.23.2, 64 bit windows target: OK I can not see any reason that binutils is the criminal, gcc 4.8 or mingw-w64 trunk looks more like the criminal. Regards, Dongsheng This issue is related to changed code for libmsvcrt.a on trunk. Yesterday was a patch for that, which should have fixed that issue. Please update trunk's crt. Which version ? I'm only see ___lc_codepage_func related changes of libmsvcrt.a on the trunk. I can confirm gcc 4.8 r200650 (2013-07-04 04:24:19 +0800) with mingw-w64 trunk r5926 (2013-07-04 00:02:29 +0800) still have an extra export InterlockedCompareExchange@12 Regards, Dongsheng Just a heads up that this issue is fixed by r5949. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ 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] __readfsbyte, __writefsbyte, __readgsbyte, __writegsbyte, etc
Point 3 should not force none-inline version. Please expain why you think that is required. While I removed the inline asm from these 3 routines, the routines themselves are still __CRT_INLINE. And the routines they call are either __CRT_INLINE or __MINGW_INTRIN_INLINE. If you examine the output generated, you'll see these routines still only generate a single line of asm code. Hard to get more efficient than that. If I weren't changing them to call existing routines, I'd still have to change the asm. As written, they don't support -masm=intel (one of my goals). Rather than duplicate the inline asm from elsewhere, calling existing routines seemed the more sensible plan. I might also point out that #3 only affects x86 code. The x64 code already does it this way. I'll wait for your final approval before committing. dw -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ 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] __readfsbyte, __writefsbyte, __readgsbyte, __writegsbyte, etc
Thank you for your explaination. Patch is ok. Thanks Kai Am 13.07.2013 20:03 schrieb dw limegreenso...@yahoo.com: Point 3 should not force none-inline version. Please expain why you think that is required. While I removed the inline asm from these 3 routines, the routines themselves are still __CRT_INLINE. And the routines they call are either __CRT_INLINE or __MINGW_INTRIN_INLINE. If you examine the output generated, you'll see these routines still only generate a single line of asm code. Hard to get more efficient than that. If I weren't changing them to call existing routines, I'd still have to change the asm. As written, they don't support -masm=intel (one of my goals). Rather than duplicate the inline asm from elsewhere, calling existing routines seemed the more sensible plan. I might also point out that #3 only affects x86 code. The x64 code already does it this way. I'll wait for your final approval before committing. dw -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [Patch] Jon's lib32_libmoldname patch
Here is the patch jon_y asked for. It contains 1 change: - Add _libm_dummy.c to lib32_libmoldname_a_SOURCES and lib64_libmoldname_a_SOURCES so the archive isn't empty. This is necessary to support tools that can't process empty archives (eg flexlink on cygwin). I'm unable to produce the makefile.in since I don't have the exact version of automake. dw Index: mingw-w64-crt/Makefile.am === --- mingw-w64-crt/Makefile.am (revision 5949) +++ mingw-w64-crt/Makefile.am (working copy) @@ -470,7 +470,7 @@ lib32_LIBRARIES += lib32/libmoldname.a lib32_libmoldname_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include) $(AM_CPPFLAGS) -lib32_libmoldname_a_SOURCES = +lib32_libmoldname_a_SOURCES = $(src_libm) lib32_LIBRARIES += lib32/libmingwthrd.a lib32_libmingwthrd_a_SOURCES = $(src_libmingwthrd) @@ -797,7 +797,7 @@ lib64_LIBRARIES += lib64/libmoldname.a lib64_libmoldname_a_CPPFLAGS=$(CPPFLAGS64) $(extra_include) $(AM_CPPFLAGS) -lib64_libmoldname_a_SOURCES = +lib64_libmoldname_a_SOURCES = $(src_libm) lib64_LIBRARIES += lib64/libmingwthrd.a lib64_libmingwthrd_a_SOURCES = $(src_libmingwthrd) -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
