Re: [Mingw-w64-public] Migration from SF and port from Autotools

On Thu, Mar 30, 2023, 06:45 Jacek Caban via Mingw-w64-public < mingw-w64-public@lists.sourceforge.net> wrote: > On 3/20/23 16:44, مهدي شينون wrote: > > Hi everyone, > > > > > > Could you please consider migrating your project to another host other > > than sourcefoge where people could file bugs,

Re: [Mingw-w64-public] Migration from SF and port from Autotools

‪On Mon, Mar 20, 2023 at 11:45 AM ‫مهدي شينون‬‎ wrote:‬ > > Hi everyone, > > > Could you please consider migrating your project to another host other > than sourcefoge where people could file bugs, propose changes and > discuss things (like GitHub ot GitLab). Sourceforge allows all of those

Re: [Mingw-w64-public] [PATCH] winpthreads: Add a missing (void) in the parameters for pthread_getevent

On Thu, Feb 17, 2022 at 8:27 AM Martin Storsjö wrote: > > This avoids warnings if building code including it, with > -Wstrict-prototypes. (Latest Clang defaults to enabling this warning > by default.) > > Signed-off-by: Martin Storsjö > --- > mingw-w64-libraries/winpthreads/include/pthread.h |

Re: [Mingw-w64-public] SJLJ GCC

I forgot to do this. What's your SF username? On Sat, Sep 18, 2021 at 1:44 AM Ralph Engels wrote: > > sure :) that would make it a litle easier. > > Ralph Engels > > Den 17-09-2021 kl. 20:20 skrev NightStrike: > > Do you want upload access? There's already

Re: [Mingw-w64-public] Patches for GCC

On Thu, Nov 11, 2021 at 2:43 PM David Grayson wrote: > > Here is my recipe for building a GCC 8.2.0 cross-compiler targeting > mingw-w64. It includes 6 patches, and comments about why they were > needed. It looks like one of those patches did fix an internal compiler > error that happened when

Re: [Mingw-w64-public] SJLJ GCC

t;https://go.microsoft.com/fwlink/?LinkId=550986> for > > Windows > > > > *From: *NightStrike <mailto:nightstr...@gmail.com> > > *Sent: *Thursday, September 16, 2021 22:24 > > *To: *Ralph Engels <mailto:ralpheng...@gmail.com> > > *Cc: *mingw-w64-public@list

Re: [Mingw-w64-public] SJLJ GCC

On Thu, Sep 16, 2021 at 10:12 PM Ralph Engels wrote: > > dunno ? he might need it for building some library for msvc in which > case sjlj is pretty much the only thing that works besides maybe seh. > sjlj is extensively tested on windows it was the first exception model > avaliable to us with

Re: [Mingw-w64-public] SJLJ GCC

On Wed, Sep 15, 2021 at 5:52 PM Kacvinsky, Tom wrote: > I find I am in need of building a GCC with Ada and UCRT support, but this > time with SJLJ > exception handling instead of SEH. Does there exist a gcc package for MSYS2 > that has > SJLJ support? Why do you need SJLJ? It's slower and

Re: [Mingw-w64-public] contributions

On Mon, Sep 6, 2021 at 7:27 AM Glenn Burkhardt wrote: > Why won't anyone answer my question about how to submit patches or pull > requests, instead of making spurious, erroneous comments on the merits > of a submission? Wasn't the rigidity of Earnie //Boyd to accept > contributions and

Re: [Mingw-w64-public] contributions

On Mon, Sep 6, 2021 at 11:25 AM Zach Bacon wrote: > > I'm pretty sure mingw-w64 is going for more with windows compatibility than > POSIX compatibility, so having functions like that wouldn't be in line with > the project where as cygwin is the project that allows you to use full > POSIX

Re: [Mingw-w64-public] [PATCH] headers: Add headers for host compute system APIs

On Mon, Aug 30, 2021 at 8:59 AM LIU Hao wrote: > > 在 8/30/21 2:42 PM, NightStrike 写道: > > > > All of those function parameters need to be uglified or removed. I > > personally prefer removing them when they provide no additional > > context. Example: >

Re: [Mingw-w64-public] [PATCH] headers: Add headers for host compute system APIs

It's required by the language standard. On Sun, Aug 29, 2021, 23:03 Biswapriyo Nath wrote: > IMHO, I don't see any proper reason to "uglify" every header file. Some > issues: > 1. If parameters are removed the function declarations will look cryptic. > 2. If I want to see a function prototype

Re: [Mingw-w64-public] [PATCH] headers: Add headers for host compute system APIs

On Sun, Aug 29, 2021 at 5:39 AM LIU Hao wrote: > > 在 2021-08-27 03:22, Biswapriyo Nath 写道: > > From d8b3fa8e4c2ddaede22ca0b134b5dcccd34aa87f Mon Sep 17 00:00:00 2001 > > From: Biswapriyo Nath > > Date: Fri, 27 Aug 2021 00:51:06 +0530 > > Subject: [PATCH] headers: Add headers for host compute

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. >

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] 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] 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] 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] 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] 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] 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, 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] 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

[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] 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

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] 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

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,

[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] [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] [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

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: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] 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] [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] [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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] [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] 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] 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

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] 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

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

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] 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] 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] 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] [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] 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] [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] 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] 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] 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] [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] 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] 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] 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] 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] [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] 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] 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] 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] [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] [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] 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] 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] [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] [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 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] 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

  1   2   3   4   >