On Wed, Apr 9, 2025, 07:16 Martin Storsjö wrote:
> This adds an optional github actions workflow, with a number of
> smoke test verifications of mingw-w64:
> - With an existing release of llvm-mingw, rebuild all the runtimes
> - This done for the CRT configurations ucrtbase, ucrt and msvcrt
> -
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,
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 thing
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 | 2
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 a
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 c
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
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 ming
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 les
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 suggestio
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 implement
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:
> >
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 qu
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 syst
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.
>
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 regards
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,
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 "!$om
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 too
> On Tue, Feb 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
> > >
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
>
>
> __
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 to
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
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 l
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 K
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: Fri
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
>
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 relationsh
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 that
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 st
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.
>
___
M
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
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,
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:
^[[?1h^
On Wed, Jul 11, 2018, 1:20 PM Hugo Beauzée-Luyssen wrote:
> On Wed, Jul 11, 2018, at 7:12 PM, Martin Storsjö wrote:
> > On Wed, 11 Jul 2018, Hugo Beauzée-Luyssen wrote:
> >
> > > RtlAddFunctionTable is only available on those. Moreover, so are the
> > > (P)RUNTIME_FUNCTION types
> >
> > No, it's
>
> 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 t
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 worked
> with binary files for
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.
---
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 the
> future.
I don't thin
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 non-member, he should
add anything you like.
On Sun, Mar 19, 2017 at 10:30 PM, David Grayson 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
> attachment is visible in t
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 files. This
> pat
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 minimal testcase appears to
dd -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 fine: a patch is attached, Ok to apply?
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 build a mingw64 compiler for windows, The host is
> >> Linux Debian Jessie
> >>
>
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 more specific
> variable name
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 example and got "false". not sure why
> this is
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++) {
> s[i]=std
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, std::regex(regexPatterns[i],
> std::regex_con
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 root directory of mingw-w64.
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
>
> --
> B
On Sep 4, 2016 6:50 PM, "Adrien Nader" wrote:
>
> Additionaly, the list of projects using mingw-w64 is now sorted and
> always displayed in full.
This was always randomized on purpose, and for very good reason: we don't
want to give preferential treatment to projects based on names starting
with
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 had already ok'd it
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 "text/plain".
> This can be
On Thu, Aug 11, 2016 at 2:05 AM, dw wrote:
> I have been told that "autoreconf -fiv" regenerates all the files using
> the current version. But after seeing the dozen files it changed and
> realizing I didn't actually know what any of them were, I chickened out.
>
> If there's something I can do
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
> Since I need to regenera
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 an
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
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 it soon.
>
> ** No
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-publ
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 our library. You are al
On Nov 18, 2015 4:39 AM, "JonY" 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
> > to be called once
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 depend
H_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, 2015 at 11:47 PM, NightStrike
on this.
> Please review :)
>
> On Sun, Nov 8, 2015 at 10:05 PM, NightStrike wrote:
>>
>> ...and, as such, you have to provide a way to set the name.
>> --with-genlib=mygenlib. You can find examples of this elsewhere in
>> the build system. This means that you do
e for that checking.
On Mon, Nov 9, 2015 at 1:02 AM, NightStrike 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 should just have to
> chan
dated to reflect Nightstrike's feedback
>>
>> On Wed, Nov 4, 2015 at 2:00 PM, NightStrike wrote:
>>>
>>> Use AM_CONDITIONAL, not DEFINE_UNQUOTED
>>>
>>> On Wed, Nov 4, 2015 at 1:56 PM, Martell Malone
>>> wrote:
>>> > Be
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 :)
>
>
> --
>
>
On Thu, Jun 11, 2015 at 2:17 AM, Luke Allardyce wrote:
> Building the crt with -j4 or higher fails when make executes the
> recipe for lib64/msvcrt.def. Creating the lib64 dir (or lib32 for
> i686) before running make fixes the issue.
Is this still a problem? I used to routinely test with infini
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: https://github.com/Alexpux/MIN
Isn't this that?
https://msdn.microsoft.com/en-us/library/jj620901.aspx
On Thu, Sep 17, 2015 at 1:56 PM, Kai Tietz wrote:
> It doesn't. At least not as compiler-builtin.
>
> 2015-09-17 19:47 GMT+02:00 NightStrike :
>> How does visual studio support AVX?
>>
&
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 in gcc, nor in mingw-w64
>
This should make a number of users happy.
-- Forwarded message --
From: "Paolo Bonzini"
Date: Aug 14, 2015 6:24 PM
Subject: [PATCH] Remove pointless -fPIC warning on Windows platforms
To:
Cc:
There are plenty of targets that do not require -fPIC because they always
generate posit
On Wed, Aug 5, 2015 at 10:19 AM, Adrien Nader wrote:
> Hi,
>
> On Wed, Aug 05, 2015, JonY wrote:
>> Hello all,
>>
>> v4.0.4 is released! (v4.0.3 had a major bug, therefore skipped)
>>
>> This release fixes a couple of bugs found in the last release:
>> * Major performance to winpthread mutex and s
;>
>> I do not have a response from NightStrike, this patch set is modifying the
>> top level autoconf to work properly. Can you please consider it?
>>
>> For all who are not using the top level autoconf, it should not matter, as
>> you do not use it anyway.
&
On May 17, 2015 8:40 PM, "zhangxinghai" 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 tool chain targ
On May 6, 2015 11:27 AM, "niXman" wrote:
>
> Ruben Van Boxem 2015-05-06 12:07:
> > Guys,
>
> Hi,
>
> > this issue is popping up from time to time. I can understand it might
> > be
> > hard to solve, but this is not good advertising for the project:
> >
> >
http://stackoverflow.com/questions/300698
On Wed, May 6, 2015 at 10:39 AM, Alon Bar-Lev wrote:
> On 6 May 2015 at 17:34, NightStrike wrote:
>> On Wed, May 6, 2015 at 10:08 AM, Alon Bar-Lev wrote:
>>>> On Wed, May 6, 2015 at 6:25 AM, Alon Bar-Lev wrote:
>>>> > this effects only top level pack
On Wed, May 6, 2015 at 10:08 AM, Alon Bar-Lev wrote:
>> On Wed, May 6, 2015 at 6:25 AM, Alon Bar-Lev wrote:
>> > this effects only top level package, if crt is to be built:
>> > 1. install headers into builddir for staging
>> > 2. adjust CPPFLAGS for tools and libraries to find local headers
>>
>
On Tue, May 5, 2015 at 9:50 AM, JonY 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 quite work as it is
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
f
On Aug 17, 2014 7:07 PM, "Baruch Burstein" 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:
https://sourceware.org/binutils/docs/binutils/windres.
Svn
On May 9, 2014 9:54 AM, "JonY" wrote:
> Hi all,
>
> You may also use the other thread for further discussion, please keep
> this thread for votes only.
>
> For mingw-w64 developers, state your SF ID; for the registered voters,
> simply reply with the same email address you registered with.
>
Responding to both of you inline... sort it out :P
On Sun, May 4, 2014 at 10:24 AM, Adrien Nader 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 a
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)
misinf
On Sun, Aug 4, 2013 at 3:12 PM, NightStrike wrote:
> On Fri, Aug 2, 2013 at 2:59 PM, Derek Buitenhuis
> 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 ver
On Fri, Sep 6, 2013 at 11:25 AM, Erik van Pienbroek
wrote:
> JonY schreef op vr 06-09-2013 om 18:43 [+0800]:
>> We will be releasing v3 from trunk soon. Testers, please check with the
>> latest trunk version if any of the changes break your applications!
>
> Hi Jon and other mingw-w64 devs,
>
> It
On Fri, Aug 2, 2013 at 2:59 PM, Derek Buitenhuis
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 that it move to a so
On Wed, Jul 3, 2013 at 11:13 AM, LRN wrote:
> On 03.07.2013 19:10, NightStrike wrote:
>> On Wed, Jul 3, 2013 at 10:36 AM, Ozkan Sezer wrote:
>>> On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz wrote:
>>>> 2013/7/3 LRN :
>>>>> On 03.07.2013 00:43, Christe
On Wed, Jul 3, 2013 at 10:36 AM, Ozkan Sezer wrote:
> On Wed, Jul 3, 2013 at 5:22 PM, Kai Tietz wrote:
>> 2013/7/3 LRN :
>>> On 03.07.2013 00:43, Christer Solskogen wrote:
On 01.07.2013 16:02, LRN wrote:
>
> mingw-w64 should supply GL headers from [1].
> Specifically - GL/glext.h
On Thu, Jun 6, 2013 at 7:35 AM, Earnie Boyd
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 lived through this
On Mon, Jun 24, 2013 at 1:37 AM, Ozkan Sezer wrote:
> On Sun, Jun 23, 2013 at 4:15 PM, Ruben Van Boxem
> 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 strongly encourage you to use
On Jun 12, 2013 11:53 AM, "Rainer Emrich"
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 Алексей,
>
On Jun 7, 2013 2:17 AM, "Алексей Павлов" 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.
>
Thanks for
On Friday, May 3, 2013, Earnie Boyd wrote:
> On Thu, May 2, 2013 at 10:05 PM, Jim Michaels 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 posting. You have to configure
> and maneuv
On Wed, Apr 24, 2013 at 9:36 AM, niXman 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:
> $> ./bui
On Mon, Apr 29, 2013 at 8:34 AM, xunxun 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]: *** [testcases
On Sun, Apr 14, 2013 at 9:09 AM, LRN 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 that those
On Sat, Mar 23, 2013 at 2:34 AM, Christer Solskogen
wrote:
>
>
> On 23/3/13 8:47 AM, Ruben Van Boxem wrote:
>
>> What gives?
>
> Don't know. I reported the same error on gcc-help the 10th of January
> this year.
Link?
--
On Fri, Apr 5, 2013 at 4:28 AM, 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 an admin to ap
1 - 100 of 483 matches
Mail list logo
