Re: [Mingw-w64-public] size of binaries (32 and 64 bits)

On Fri, Dec 7, 2012 at 6:34 AM, Vincent Torri vincent.to...@gmail.com wrote: On Fri, Dec 7, 2012 at 4:48 PM, Kai Tietz ktiet...@googlemail.com wrote: Hello, yes, this size different - *especially* for *small* apps - is to be expected. As exactly for those *small* applications differences in

Re: [Mingw-w64-public] gendef - why?

On Tue, Dec 11, 2012 at 6:22 PM, Алексей Павлов alex...@gmail.com wrote: Sorry for the noise! Running autereconf before configure solve the problem You shouldn't have to run autoreconf on a checkout from trunk. We keep everything checked in just for that reason.

Re: [Mingw-w64-public] half-missing API

Can either of you provide a patch? On Sun, Dec 23, 2012 at 12:07 AM, Joshua Boyce raptorfac...@raptorfactor.com wrote: On Sat, Dec 22, 2012 at 6:21 PM, Jim Michaels jmich...@yahoo.com wrote: these do not exist. they are used for fixing and getting specialfolder paths in vista+

Re: [Mingw-w64-public] build boxes

On Sat, Jan 5, 2013 at 12:08 AM, Jim Michaels jmich...@yahoo.com wrote: http://exxactcorp.com/index.php/solution/solu_list/53 http://exxactcorp.com/index.php/solution/solu_detail/42 this one I don't know if it runs windows or not. but it is an HPC server with up to 40 cores and 80 threads,

Re: [Mingw-w64-public] Sleep redeclare

On Fri, Jan 4, 2013 at 9:44 PM, Алексей Павлов alex...@gmail.com wrote: Ping? 2013/1/3 Алексей Павлов alex...@gmail.com I rephrase the question. Why gcc-4.7.2 build this without problem, but gcc-4.6.3 has error? 2013/1/3 Алексей Павлов alex...@gmail.com But with gcc-4.7.2 it build ok

Re: [Mingw-w64-public] [Mingw-users] Thoughts on how to build a linux / visual studio project (QuickFIX) with mingw

On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly mingw.andr...@gmail.com wrote: I've had a quick look at the source code and it's littered with stuff like: Kudos for looking at the source! :) #ifdef _MSC_VER #include Winsock2.h ... So the fact is that the code itself conflates Windows builds

Re: [Mingw-w64-public] Several GCC issues

On Wed, Jun 11, 2008 at 11:40 AM, Grant Pedersen m...@razorbyte.com.au wrote: Hi NightStrike Kai, Have you had any luck with issues 2 - 5 below? Issue 5 is a showstopper for me at the moment. Which of these are still a problem? At least a few have been fixed. Thanks, Grant

Re: [Mingw-w64-public] Link with static libwinpthread problem

2013/1/26 Алексей Павлов alex...@gmail.com: Hi! I try to build static program and pass to LDFLAGS: -Wl,-Bstatic -lwinpthread -Wl,-Bdynamic -static -s But it link with dynamic libwinpthreads-1.dll. What I doing wrong? Can you show the output of adding -v to that command line?

Re: [Mingw-w64-public] [PATCH] winsvc.h: add missing defines for ChangeServiceConfig2()

Committed r5579 On Tue, Feb 5, 2013 at 7:02 AM, Kai Tietz ktiet...@googlemail.com wrote: Thanks, patch is ok for apply. I will apply it during this week, or maybe somebody else want to apply it sooner. Thanks, Kai 2013/1/30 Christian Franke christian.fra...@t-online.de: Hi, winsvc.h

Re: [Mingw-w64-public] Cross-compiling BASH

On Wed, Feb 13, 2013 at 8:32 PM, Алексей Павлов alex...@gmail.com wrote: Hi! I work on MSYS2 and now built mingw-msys2 cross compiler. Also I successfully build native toolchain for msys2 and some 3rdparty libs. Now I need to cross-compiling BASH but I got error on start building: Are you

Re: [Mingw-w64-public] Install MinGW w64

On Tue, Feb 5, 2013 at 10:31 AM, Jorge F. Hernandez jor...@fsbcomputers.com wrote: By the way, I tried using the MinGW 64-bit that comes with Cygwin, but when I tried to run configure and it tries to check if gcc will compile what I'm trying to, it says it cannot create executables, what

Re: [Mingw-w64-public] [PATCH] TLS support fixes

On Tue, Feb 19, 2013 at 2:41 AM, David Nadlinger c...@klickverbot.at wrote: Hi all, please find two patches to fix/improve TLS support in mingw-w64-crt attached. Do you have commit rights? Also, please let me know if there is another preferred method to submit patches. This works. We can

Re: [Mingw-w64-public] Success building 64 bit vim and gvim with perl [was: windres: unexpected version string length 68 != 32 + 8]

On Thu, Feb 21, 2013 at 5:22 PM, Suresh Govindachar sgovindac...@yahoo.com wrote: I used to build 32 bit Vim with perl support using mingw regularly, but stopped when I got 64 bit Windows 7 since my attempts at building a 64 bit version failed. Some hours ago, I got the latest vim sources

Re: [Mingw-w64-public] cross compile problem

On Sun, Mar 3, 2013 at 11:40 AM, Larry Pottle shark.at.ni...@gmail.com wrote: On Sun, Mar 3, 2013 at 3:34 AM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Did you add /opt/mingw64/bin to PATH? Great! I added /bin to PATH and now it wants to cross compile. Now I had issues with libraries

Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers

On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com wrote: Hi, I'd like to resurrect a patch which has been refused last year, but I think it's still helpful and maybe the opinions have changed a bit. Sorry.. did I refuse it? Can you link to the mailing list archive (I

Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers

On Thu, Mar 14, 2013 at 5:13 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Mar 13 16:18, NightStrike wrote: On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc...@redhat.com wrote: Hi, I'd like to resurrect a patch which has been refused last year, but I think it's still

Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers

On Thu, Mar 14, 2013 at 11:27 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Mar 14 10:53, NightStrike wrote: On Thu, Mar 14, 2013 at 5:13 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Mar 13 16:18, NightStrike wrote: On Wed, Mar 13, 2013 at 7:22 AM, Corinna Vinschen vinsc

Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers

On Thu, Mar 14, 2013 at 1:26 PM, John E. / TDM tdra...@tdragon.net wrote: On 3/14/2013 1:00 PM, NightStrike wrote: On Thu, Mar 14, 2013 at 11:27 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Mar 14 10:53, NightStrike wrote: When you say full mingw tree, do you mean that you are building

Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers

On Thu, Mar 14, 2013 at 4:22 PM, John E. / TDM tdra...@tdragon.net wrote: On 3/14/2013 6:26 PM, NightStrike wrote: On Thu, Mar 14, 2013 at 1:26 PM, John E. / TDM tdra...@tdragon.net wrote: Just to throw another data point out there, I use top-level configure for TDM-GCC (i.e. an x86_64-w64

Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers

On Fri, Mar 15, 2013 at 12:55 AM, John E. / TDM tdra...@tdragon.net wrote: On 3/14/2013 8:54 PM, NightStrike wrote: On Thu, Mar 14, 2013 at 4:22 PM, John E. / TDM tdra...@tdragon.net wrote: $(RUNTIME_SRC)/configure --build=x86_64-w64-mingw32 --enable-lib32 --enable-sdk=all --with-libraries

Re: [Mingw-w64-public] [patch] Prefer to use local headers over installed headers

On Fri, Mar 15, 2013 at 3:24 PM, John E. / TDM tdra...@tdragon.net wrote: On 3/15/2013 8:14 AM, NightStrike wrote: On Fri, Mar 15, 2013 at 12:55 AM, John E. / TDM tdra...@tdragon.net wrote: The headers seem to get built along with all the other subtrees... ? Curious... when configuring the crt

Re: [Mingw-w64-public] Using Python and Mingw64

On Thu, Mar 14, 2013 at 8:00 PM, Theuns Heydenrych theunsheydenr...@gmail.com wrote: Hi sorry, i made references in the previous mail, to line numbers here is the pastebin link to the cygwinccompiler.py http://pastebin.com/jucBgjpQ One other thing , i configure Sip with python configure.py

Re: [Mingw-w64-public] New Rubenvb GC 4.8.0 Personal build

On Sun, Mar 24, 2013 at 5:33 PM, Zouzou inter...@123gen.com wrote: On 23/03/2013 17:49, Ruben Van Boxem wrote: ... Hi, Thanks a lot for this quick release. If I may be pedantic, the -dw2 one should no longer be -dw2 but -dw4, as GCC has now switched to generating DWARF 4 debug info by

Re: [Mingw-w64-public] GCC 4.8 and -fPIC warning being treated as error

On Fri, Mar 22, 2013 at 9:52 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2013/3/23 Ruben Van Boxem vanboxem.ru...@gmail.com /home/ruben/mingw-w64/src/gcc/libbacktrace/dwarf.c:1:0: error: -fPIC ignored for target (all code is position independent) [-Werror] /* dwarf.c -- Get file/line

Re: [Mingw-w64-public] [Notice] gendef, genidl and genpeimg is now GPLv3 or later

On Sat, Mar 30, 2013 at 9:28 PM, JonY jo...@users.sourceforge.net wrote: On 3/31/2013 04:35, Jon wrote: With respect to http://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL is it true that gendef, genidl, and genpeimg do not copy any part of themselves into their output? That is

Re: [Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Move compiler intrinsics to libkernel32.a

On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen vinsc...@redhat.com wrote: Hi, today we got a report on the cygwin-developers mailing list, which reported that linking a certain library fails, because some of the inline functions in winnt.h can't be resolved by the linker under Cygwin:

Re: [Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Move compiler intrinsics to libkernel32.a

On Tue, Apr 2, 2013 at 9:48 AM, Corinna Vinschen vinsc...@redhat.com wrote: On Apr 2 03:00, NightStrike wrote: On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen vinsc...@redhat.com wrote: Ok, done. The order of the variables is different between 32 and 64 bit. I did it the same way

Re: [Mingw-w64-public] I am a member.

On Fri, Apr 5, 2013 at 4:28 AM, wynfi...@gmail.com wrote: My mail is being held and I'm getting a non-member message. I am a member, albeit a new one, but one none the same. Is there some problem? You didn't actually subscribe to the mailing list, so your messages sit in a bucket waiting for

Re: [Mingw-w64-public] winpthreads testsuite

On Sun, Apr 14, 2013 at 9:09 AM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14.04.2013 10:54, LRN wrote: This patch should integrate the testsuite imported from pthreads with winpthreads. (includes re-generated configure and Makefile.in - it is very sad

Re: [Mingw-w64-public] Lack test-driver when make check mingw64-crt svn 5830

On Mon, Apr 29, 2013 at 8:34 AM, xunxun xunxun1...@gmail.com wrote: It shows: make check-TESTS make[2]: Entering directory `/e/gnu/mingw64/svn/mingw-w64-crt' make[3]: Entering directory `/e/gnu/mingw64/svn/mingw-w64-crt' /bin/sh: ./build-aux/test-driver: No such file or directory make[3]:

Re: [Mingw-w64-public] MinGW-builds scrips now provide the ability to build Python only!

On Wed, Apr 24, 2013 at 9:36 AM, niXman i.nix...@gmail.com wrote: Hi, According to numerous questions about how to build Python using mingw/mingw-w64, I decided to add in MinGW-builds cripts key '--python-only=x.y.z', which allows to use MinGW-builds scripts to build Python only. Examples:

Re: [Mingw-w64-public] [OT] top posting from yahoo [WAS: format check broken]

On Friday, May 3, 2013, Earnie Boyd ear...@users.sourceforge.net wrote: On Thu, May 2, 2013 at 10:05 PM, Jim Michaels jmich...@yahoo.com wrote: sorry, my yahoo mail can only top-post, so don't email me about that. still investigating this problem. Yahoo mail has nothing to do with TOP

Re: [Mingw-w64-public] Mingw-builds

On Jun 7, 2013 2:17 AM, Алексей Павлов alex...@gmail.com wrote: Hi everyone! We release on-line installer for our builds. You can download it from mingw-builds-install.exe. This installer automatically receive file with all our builds and you can choose what version you want to install.

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

On Jun 12, 2013 11:53 AM, Rainer Emrich sf.rai...@emrich-ebersheim.de wrote: Am 12.06.2013 17:33, schrieb LRN: On 12.06.2013 17:50, Corinna Vinschen wrote: On Jun 12 16:00, LRN wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.06.2013 14:47, Corinna Vinschen wrote: Hi

Re: [Mingw-w64-public] End of rubenvb builds

On Mon, Jun 24, 2013 at 1:37 AM, Ozkan Sezer seze...@gmail.com wrote: On Sun, Jun 23, 2013 at 4:15 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Hi everyone, I have come to the conclusion that my MinGW-w64 builds bring too little to the table for me to continue maintaining them. I

Re: [Mingw-w64-public] Fwd: SourceForge Project Upgrade - Code Repo Complete

On Thu, Jun 6, 2013 at 7:35 AM, Earnie Boyd ear...@users.sourceforge.net wrote: On Thu, Jun 6, 2013 at 1:20 PM, Kai Tietz wrote: Hello everybody, Please be aware. Project update happend by SourceForge recently. It wasn't wished by us. Nevertheless we have to live by that. Since I've

Re: [Mingw-w64-public] OpenGL headers

On Wed, Jul 3, 2013 at 10:36 AM, Ozkan Sezer seze...@gmail.com wrote: On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz ktiet...@googlemail.com wrote: 2013/7/3 LRN lrn1...@gmail.com: On 03.07.2013 00:43, Christer Solskogen wrote: On 01.07.2013 16:02, LRN wrote: mingw-w64 should supply GL headers

Re: [Mingw-w64-public] OpenGL headers

On Wed, Jul 3, 2013 at 11:13 AM, LRN lrn1...@gmail.com wrote: On 03.07.2013 19:10, NightStrike wrote: On Wed, Jul 3, 2013 at 10:36 AM, Ozkan Sezer seze...@gmail.com wrote: On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz ktiet...@googlemail.com wrote: 2013/7/3 LRN lrn1...@gmail.com: On 03.07.2013 00

Re: [Mingw-w64-public] [RFC] Single filename per line in Makefiles

On Fri, Aug 2, 2013 at 2:59 PM, Derek Buitenhuis derek.buitenh...@gmail.com wrote: As it stands right now, the grouping and wrapping of filenames in MinGW-w64's Makefiles makes tracking or viewing changes in version control very very hard, and makes it non-obvious what has changed. I propose

Re: [Mingw-w64-public] mingw-w64 may move to git in the future

Wow, I really have been away for a long time. I found this thread while cleaning things out now that my 578493578943 projects at work are finally finishing. Also, I'm trying to see if we can incorporate winpthreads in one project :) I have to say, this is kind of sad, mostly because of 1)

Re: [Mingw-w64-public] mingw-w64 may move to git in the future

Responding to both of you inline... sort it out :P On Sun, May 4, 2014 at 10:24 AM, Adrien Nader adr...@notk.org wrote: On Sun, May 04, 2014, JonY wrote: On 5/4/2014 12:17, NightStrike wrote: Now... that said, there's a few things that I didn't see addressed anywhere in this thread. 1

Re: [Mingw-w64-public] Where are the sources for windres?

On Aug 17, 2014 7:07 PM, Baruch Burstein bmburst...@gmail.com wrote: I can't seem to find them, and I am getting a very strange bug that I would like to try to track down (as an exercise) Wind res is provided by the binutils project, as you can see here:

Re: [Mingw-w64-public] [PATCH] [PROTOTYPE] build crt using locally provided headers

I know I've been silent for a long time, but I do still read the lists, and I felt the need to comment on what I consider a bad change. Feel free to ignore me. I understand the intent, and the intent is good (that is, to make top level work again). I still have some local patches to that effect

Re: [Mingw-w64-public] [PATCH 2/2] build: autoconf: enable multiple tools and libs

On Tue, May 5, 2015 at 9:50 AM, JonY jo...@users.sourceforge.net wrote: On 5/5/2015 03:47, Alon Bar-Lev wrote: this somewhat reduces the error checking, but makes code and usage nicer. Hi, Thanks for the patch, but I'm rather ambivalent about keeping the top-level configure. It doesn't

Re: [Mingw-w64-public] how to use ld.gold as the linker?

On May 17, 2015 8:40 PM, zhangxinghai zxh19750...@163.com wrote: Mm I have some another questions 1.As the ld.gold only supports elf format,why it is included in the binutils for build target windows?Does that mean I will never touch this tool under windows. It should not be included in a

Re: [Mingw-w64-public] [PATCH 2/2] build: autoconf: enable multiple tools and libs

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

Re: [Mingw-w64-public] Building GCC on mingw-w64

On Sat, Oct 3, 2015 at 6:46 PM, FX wrote: >> MSYS2 distributes the gcc fortran package based on mingw-w64 (see the >> output of pacman -Ss fortran). You can inspect how it is built by >> consulting its PKGBUILD recipe. It is here, along with the necessary >> patches:

Re: [Mingw-w64-public] PATCH for autootools to use genlib

alone <martellmal...@gmail.com> > wrote: >> >> Updated to reflect Nightstrike's feedback >> >> On Wed, Nov 4, 2015 at 2:00 PM, NightStrike <nightstr...@gmail.com> wrote: >>> >>> Use AM_CONDITIONAL, not DEFINE_UNQUOTED >>> >>>

Re: [Mingw-w64-public] PATCH for autootools to use genlib

for that checking. On Mon, Nov 9, 2015 at 1:02 AM, NightStrike <nightstr...@gmail.com> wrote: > Sorry, missed this the first time around... this should be a with- > option, not enable. genlib is an external tool for the crt, not an > internal feature that is getting compiled in. You s

Re: [Mingw-w64-public] PATCH for autootools to use genlib

t; Thanks for your input and help on this. > Please review :) > > On Sun, Nov 8, 2015 at 10:05 PM, NightStrike <nightstr...@gmail.com> wrote: >> >> ...and, as such, you have to provide a way to set the name. >> --with-genlib=mygenlib. You can find examples of this els

Re: [Mingw-w64-public] PATCH for autootools to use genlib

ndif >> after the WITH_GENLIB conditional. > > Yeah I knew I done that. I thought the variable name could have stayed the > same. > Laziness on my part there. > > Anyway here is an updated patch to address your comments. > It is in .txt format :) > > On Mon, Nov 9, 201

Re: [Mingw-w64-public] Fix def file generation during parallel build

This is a bad change. Make should be managing dependencies. It's bad form to force a call to mkdir for every iteration, when it only needs to be called once (especially on msys/cygwin, where that extra call is non-trivial.) The correct way to do it is to set the destination directory as a

Re: [Mingw-w64-public] PATCH for autootools to use genlib

Use AM_CONDITIONAL, not DEFINE_UNQUOTED On Wed, Nov 4, 2015 at 1:56 PM, Martell Malone wrote: > Be warned I am no autotools expert. > A review would be very helpful. :) > > CC+ alexey for help on that :) > > >

Re: [Mingw-w64-public] Fix def file generation during parallel build

On Nov 18, 2015 4:39 AM, "JonY" <jo...@users.sourceforge.net> wrote: > > On 11/17/2015 22:13, NightStrike wrote: > > This is a bad change. Make should be managing dependencies. It's bad > > form to force a call to mkdir for every iteration, when it only needs

Re: [Mingw-w64-public] AVX support is broken in 64-bit mode! Will there ever be a fix?

How does visual studio support AVX? On Sep 12, 2015 6:40 AM, "Kai Tietz" wrote: > Hello, > > first thanks for interesting in this subject, but sadly I have > disappoint you about it, I fear. The cause for the inability to align > to 32-byte alignment is neither to seek

Re: [Mingw-w64-public] AVX support is broken in 64-bit mode! Will there ever be a fix?

Isn't this that? https://msdn.microsoft.com/en-us/library/jj620901.aspx On Thu, Sep 17, 2015 at 1:56 PM, Kai Tietz <ktiet...@googlemail.com> wrote: > It doesn't. At least not as compiler-builtin. > > 2015-09-17 19:47 GMT+02:00 NightStrike <nightstr...@gmail.com>: >

Re: [Mingw-w64-public] [Mingw-users] GCC-4.9.3 is now our current release

On Mar 7, 2016 2:51 AM, "ralph engels" wrote: > > Allthough not needed for building i uploaded the patched winpthreads > library used in building gcc-5.3.0. Please remember that you are obligated by the license to provide the source for the changes to your derived work of

Re: [Mingw-w64-public] mingw-w64-public silently drops my posts

Why do you need to pgp sign your message at all? On Apr 22, 2016 1:24 PM, "LRN" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > This is a recent development. Last of my message that got through (apart > from a couple of test messages that i've sent today) was: >

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

On Aug 10, 2016 5:44 PM, "dw" wrote: > > The checked-in mingw-w64-crt/Makefile.in was generated with 1.15. > However the associated aclocal.m4 is generated with 1.14.1. I don't > know much about the build files, but is mixing and matching like this a > good idea? Nope

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

On Sun, Aug 14, 2016 at 9:02 AM, Martin Storsjö wrote: > On Sat, 13 Aug 2016, dw wrote: > >> I still have some more fixes for ARM, but this patch is getting too big. >> This is a logical point to break. > > Yes, that's probably for the best. > > If/when committing (iirc someone

Re: [Mingw-w64-public] Patches

On Mon, Aug 8, 2016 at 11:55 PM, dw wrote: > Aha! > > Apparently the reason SF has been eating my patches is that they are being > sent with mime type "text/x-patch." By default, SF strips attachments that > aren't of types "multipart/mixed" "multipart/alternative" or

Re: [Mingw-w64-public] Confirmation of a potential bug of g++ 6.1 targeting i686 requested

What happens if you use the built in version? On Jul 2, 2016 10:19 AM, "lh mouse" wrote: > Have you guys got g++ 6.1? I am now suffering from an ICE, but > I am not sure whether it is a bug of GCC. I am looking forward to > your opinions. If this is indeed a GCC bug I will file

Re: [Mingw-w64-public] double-check memory functions for proper multiplication like memcpy, malloc, free, etc

Why do you send messages like these to the various mingw and gcc mailing lists? There's no context at all, no explanation of what's in your head. It's like you are only putting a fraction of your thoughts in these emails, expecting the community to figure out what you mean. When people don't, then

Re: [Mingw-w64-public] gcc bugs, gnu folk won't acknowledge

I really suggest you find a general c++ resource to use. Most of your "sky is falling" problems are due to your own lack of knowledge regarding how to write code. This is the same. The GNU folks won't acknowledge your complaint because your code is malformed. The compiler is not broken here. In

Re: [Mingw-w64-public] sinl/cosl/tanl accuracy problem

What does gcc's __builtin_sinl() do? On Wed, Sep 7, 2016 at 11:37 PM, lhmouse wrote: > If performance is the problem there are a number of solutions such as > inline assembly, static lookup tables, etc. `fsinl()` is apparently not one > of them. > But yes, I am all ears > >

Re: [Mingw-w64-public] aclocal.m4 and Makefile.am out of sync

t; > >>>> Use format-patch -D to ommit the contents of the deleted > >>>> files. > >>> Patch attached. > >> Looks good to me. > >> > > Done. > > Ok. With that change in place, I have run > > autoreconf -fiv > > in the ro

Re: [Mingw-w64-public] std::regex not fulfilling standard? missing templates

On Fri, Nov 4, 2016 at 11:37 PM, Jim Michaels wrote: > that page's description of regex_match has got to be wrong. what good use > is there to match the entire line to the regex? seriously, think about it. > I would substitute the abiguous term "target" for some other

Re: [Mingw-w64-public] std::regex not fulfilling standard? missing templates

On Wed, Nov 2, 2016 at 9:07 PM, Jim Michaels wrote: > #include > #include > int main(void) { > std::cout<<(std::regex_match("abcdefg",std::regex("def",std::regex_constants::extended))?"true":"false")< return 0;} > > corrected some more bugs in that

Re: [Mingw-w64-public] std::regex not fulfilling standard? missing templates

On Wed, Nov 2, 2016 at 8:09 PM, Jim Michaels wrote: > namespace str { > std::string str::localestringlower(std::string s) { > //not sure if std::locale:: will solve conflicting namespaces > between and > for (size_t i=0; i < s.size(); i++)

Re: [Mingw-w64-public] std::regex not fulfilling standard? missing templates

On Tue, Nov 1, 2016 at 2:14 PM, Jim Michaels wrote: > problem with std::regex not fulfilling standard? > for this code I got the below > > for (intmax_t i=0; i < > regexPatterns.size()&&(findit=findIt||!std::regex_match(sline, > std::regex(findstr,

Re: [Mingw-w64-public] Cannot build ming64 for windows

On Dec 24, 2016 6:48 PM, "Michele Bucca" wrote: Il 25 dic 2016 12:44 AM, "JonY" ha scritto: > > On 12/24/2016 04:53 PM, Michele Bucca wrote: > > 2016-12-24 17:36 GMT+01:00 Michele Bucca : > >> Hello, I'm trying to

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

On Mar 14, 2017 11:08 PM, "Riot" wrote: As you say, I'm not entirely enthused by the prospect of digging into ld's code, and if the issue is indeed upstream, I don't see much hope of having it fixed in the case of an issue I can only manifest on Windows, and where the

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

On Mar 16, 2017 1:40 PM, "Liu Hao" wrote: On 2017/3/17 0:51, David Grayson wrote: > I was trying to compile Qt and I ran into an error because Qt is > passing a const pointer to the first argument of VerQueryValue, which > is not properly marked as const in the mingw-w64 header

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

On Mon, Mar 20, 2017 at 9:23 AM, David Grayson wrote: > Oops, that was the problem then. It was "application/octet-stream" because > I was constructing the email with the Ruby "mail" gem that doesn't > recognize ".patch" files as being text. I'll use better methods in

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

On Mon, Mar 20, 2017 at 9:34 AM, Mateusz Mikuła wrote: > It explains why my patches created with `git format-patch` couldn't > make it. > > Their mime type is `text/x-diff`. I added text/x-diff to the list. Give it a shot.

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

On Mon, Mar 20, 2017 at 9:42 PM, David Wohlferd wrote: > >> I don't think application/octet-stream is something we would want to >> enable. Doesn't that sound like something that would be abused? > > I suppose application/octet-stream might be useful if we commonly

Re: [Mingw-w64-public] [PATCH] Use LPCVOID instead of 'const LPVOID' for VerQueryValue

add anything you like. On Sun, Mar 19, 2017 at 10:30 PM, David Grayson <davidegray...@gmail.com> wrote: > NightStrike, > > The mailing list swallowed the patch in the message I sent on March 16th. > I can see in GMail that I did have a patch attached to my message, but no >

Re: [Mingw-w64-public] Fwd: Fix for winreg.h

On Tue, Mar 14, 2017 at 6:50 AM, Liu Hao wrote: > On 2017/3/14 18:57, JonY wrote: >> Looks like LH has already applied this to master. > Yes I pushed it a couple of days ago. He said his mails were suspended > on this ML (and it seemed so). > > Best regards, > LH_Mouse As a

Re: [Mingw-w64-public] gendef updates in git, one configury issue

und those failures. Probably we need >> to add -L/some/path/lib to LDFLAGS before those checks, but >> I'd like to leave that to Nightstrike who used to handle those >> stuff (I guess he still does, yes?) > > Well, moving the --with-mangle checks to after all other checks > works

Re: [Mingw-w64-public] w64 cross, testsuite under wine, escape sequences

On Thu, Sep 6, 2018 at 4:58 PM NightStrike wrote: > > On Thu, Sep 6, 2018 at 9:08 AM NightStrike wrote: > > > > Host: x86_64-pc-linux (Cent 6) > > Target: x86_64-w64-mingw32 (wine) > > > > When I build the linux > w64 cross compiler under linux and r

[Mingw-w64-public] w64 cross, testsuite under wine, escape sequences

Host: x86_64-pc-linux (Cent 6) Target: x86_64-w64-mingw32 (wine) When I build the linux > w64 cross compiler under linux and run the testsuite under wine, it all basically works for the most part. However, the log files get filled with what appears to be ANSI escape sequences of the form:

Re: [Mingw-w64-public] w64 cross, testsuite under wine, escape sequences

On Thu, Sep 6, 2018 at 9:08 AM NightStrike wrote: > > Host: x86_64-pc-linux (Cent 6) > Target: x86_64-w64-mingw32 (wine) > > When I build the linux > w64 cross compiler under linux and run the > testsuite under wine, it all basically works for the most part. > However,

Re: [Mingw-w64-public] [PATCH] crt: Add "volatile" to all inline assembly snippets under math

> > Well, if it'd be inline functions in a header, I'd be inclined to agree. > All of these are in non-inline functions (e.g. like the sqrt function, > where you expect it to always produce one "fsqrt" instruction), so I > don't expect any losses there. > Is that always the case? I'm pretty sure

Re: [Mingw-w64-public] Many kernel32 functions are missing

On Sat, Jan 12, 2019, 9:48 AM Biswapriyo Nath Many kernel32 functions are missing. How can I add those functions? Those > are also redirected with api-ms- virtual dll redirection. > I'd start with providing updates defs and headers in a patch. > ___

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

On Wed, Jun 5, 2019, 3:43 PM Martin Storsjö wrote: > On Wed, 5 Jun 2019, Francois Gouget wrote: > > >> 3. Build a few projects - to make sure they build. > >> > >> Wine, Wine Gecko, VLC should give a good coverage. > > > > That sounds like long running tasks so we will likely need new hardware >

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

On Wed, May 22, 2019 at 3:44 PM Jacek Caban wrote: > > Hi all, > > [I'm addressing it to both mingw-w64-public and wine-devel] > > As most of you know, Wine and mingw-w64 have a lot in common and > cooperate to some extend for quite a while. There have been talks about > tightening this

Re: [Mingw-w64-public] Update OpenGL headers

Why remove them? On Fri, May 10, 2019, 5:24 AM LRN wrote: > TBH, i'm starting to think that we should radically cut the GL headers > down and > only ship GL.h and GLU.h, just like MS does (and also glaux.h, probably). > The > rest can be installed separately. > > In case anyone still thinks

Re: [Mingw-w64-public] [PATCH] Fix potential deadlock in pthread condition variable

On Mon, Apr 8, 2019, 10:37 AM Liu Hao wrote: > > I reformatted the code to a consistent layout to improve readability > > whilst I was trying to figure out how it worked. The original code had a > > variety of styles. Is there a "preferred" style? I noticed that other > > source have different

[Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

FYI, Eric posted this today to the GCC patches list. This may be of great interest to many who would prefer native threads instead of the winpthreads posix style interface. Great work, Eric! I look forward to trying this out! -- Forwarded message - From: Eric Botcazou Date:

Re: [Mingw-w64-public] MB_CUR_MAX breaks 2K/NT4 applications

On Tue, Jul 16, 2019 at 2:53 AM Martin Storsjö wrote: > > What I don't understand is why there isn't a simple "#if WINVER >= > > 0x0501" so that applications that are specifically built to run on > > older systems can still run. > > Why? Because it was everybody's expectation that we only needed

Re: [Mingw-w64-public] CRT uses POSIX functions.

On Fri, May 31, 2019 at 11:54 AM Gravis wrote: > > I'm a huge fan of POSIX but POSIX functions should not be used in the > MinGW-w64 CRT code as they are now. Using them in this way creates > mandatory dependencies on additional libraries (e.g. MSVCRT). Since > all libraries ultimately rely on

Re: [Mingw-w64-public] CRT uses POSIX functions.

On Fri, Jun 28, 2019 at 11:17 AM Jean-Baptiste Kempf wrote: > > On Fri, May 31, 2019, at 17:53, Gravis wrote: > > I'm a huge fan of POSIX but POSIX functions should not be used in the > > MinGW-w64 CRT code as they are now. Using them in this way creates > > mandatory dependencies on additional

Re: [Mingw-w64-public] Generating new directx headers

On Sun, Dec 8, 2019, 12:35 PM Biswapriyo Nath wrote: > The files in Windows SDK are too big to add (but not impossible). I am also > eager to do it but afraid of any copyright laws which may be applied for > big chunk of copy-pasting code. > You can't copy and paste copyrighted code. You have

Re: [Mingw-w64-public] HTTPS certificate for mingw-w64.org expired

You're downloading from sf.net, not the doku wiki. On Tue, Feb 4, 2020, 9:12 PM Alex wrote: > The certificate is past its expiration date by several months. Please > update it! > > Downloading a toolchain from a non-https site is not a good idea... > > -- > Sincerely, > Alex Parrill > > >

Re: [Mingw-w64-public] HTTPS certificate for mingw-w64.org expired

eb 4, 2020 at 9:21 PM NightStrike wrote: > > > You're downloading from sf.net, not the doku wiki. > > > > On Tue, Feb 4, 2020, 9:12 PM Alex wrote: > > > > > The certificate is past its expiration date by several months. Please > > > update it! > >

Re: [Mingw-w64-public] Proposal to add a code formatting rule

On Sat, Apr 4, 2020 at 1:04 AM Biswapriyo Nath wrote: > > The coding style is different in many files in mingw-w64 headers and crt. > Is it possible to add a rule to enforce a consistent coding style across > all the source file? For example, using clang-fromat, editorconfig etc. > lightweight

Re: [Mingw-w64-public] dwrite_3.h regression fix

On Thu, Sep 24, 2020 at 12:03 PM Jacek Caban wrote: > > Hi, > > > I sent this as a patch earlier, but it got stuck on moderation due to > the size. Please review commit: I increased the message size limit from 512KB to 999KB, which appears to be a sourceforge limit. If you think we need larger,

Re: [Mingw-w64-public] a possible bug in mingw-w64

No attachment On Wed, Aug 5, 2020, 12:01 PM Takashi Inoue wrote: > Hi All, > > This is my first post to here. Nice to meet you. > > I may found a bug in mingw-w64. > In particular, it is in OpenMP schedule(dynamic, chunk-size). > Let me ask your opinion. > > One of my fortran program with

Re: [Mingw-w64-public] MINGW trademark claims

On Sat, May 8, 2021, 01:28 Joachim Wuttke wrote: > Keith Marshall argues at https://stackoverflow.com/a/62865466/1017348 > that you are doing illegal things, and that perhaps I am rendering > myself culpable by recommending use of your software. > > What is your position on this? > > Kind

Re: [Mingw-w64-public] Windows 95 crashes

On Sun, May 30, 2021, 10:05 unlvsur unlvsur wrote: > Compiling programs for Windows 95 and Pentium in 2021 | GL1zdA's Weblog ( > wordpress.com)< > https://glizda.wordpress.com/2021/05/19/compiling-programs-for-windows-95-and-pentium-in-2021/ > > > We never claimed to support windows 95. >

<    1   2   3   4   >