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 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=48808831&iu=/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 wrote: > Hi, > > On Fri, Jul 12, 2013, Jon wrote: >> On Fri, 12 Jul 2013 19:43:04 +0200 >> Kai Tietz 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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/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 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=48808831&iu=/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
-
-/* 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
-
-/* 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
-
-/* 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
-
-/* 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
-
-/* for __x86_64 only */
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 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=48808831&iu=/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" : > 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=48808831&iu=/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=48808831&iu=/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 wrote: > 于 2013/7/4 17:18, Kai Tietz 写道: >> 2013/7/4 Dongsheng Song : >>> 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 > 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=48808831&iu=/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=48808831&iu=/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" : > > > 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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
