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

[NightStrike]

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, propose changes and
> > discuss things (like GitHub ot GitLab).
> >
> > Using mailing-list for that is a way that's not suitable for young
> > generation (including me).
> >
> > Many people try to report bugs or propose changes but ended up ignored
> > because of this insist on using this outdated technology!
>
>
> We had similar talks in Wine for years and we finally decided decided to
> migrate to Gitlab last year. I think it was a good choice. We had it
> running parallel to ML as an experiment first, here is the summary:
>
> https://www.winehq.org/pipermail/wine-devel/2022-June/220008.html
>
> I think most of it would apply to mingw-w64 as well. I'd like to
> especially point CI: Gitlab makes it easy to set up CI and mingw-w64
> could really use one. It's esp. nice for reviewers: by the time you look
> at the patch, you already know that it doesn't break the build.
>

The use of a hosted solution vs making lists for patches is orthogonal to
not using SF. We could use any of the many services SF offers, and I pushed
this hard over the years, but people like mailing list patches. Part of it
is old habits, part of it is accessibility. Patch commenting on a website
with markdown is neat and useful, but not very accessible.

As for CI, remember that to have effective CI for us requires building the
whole toolchain. We used to do this daily with a buildbot service set up by
Mook and me, served by ReactOS, and run on donated hardware. Mook left,
react stopped giving us the server, and donors stopped donating.

I'm working with MJW to get a builder running on the SW BB. That should
take care of this requirement, but mind you that native builds can take
days to finish.

Wine uses self-hosted Gitlab instance, which solves the problem of
> dependence on third party host. Having its own self-hosted instance just
> for mingw-w64 would probably be too much overhead for mingw-w64 project,
> so if we decided to migrate, we'd need to pick one of externally hosted
> solutions.


BTW, SF mailing lists are especially not friendly for patches with its
> automatic footer messing inline patches and some attachments being
> silently dropped, depending on their extensions.


That's configurable. If there's a mime type that needs adding, I can add it.

That combined with
> other controversies (see https://en.wikipedia.org/wiki/SourceForge
> Controversies paragraph) makes me think that SF is not an optimal host
> for the project.
>

That's very old news, and has since been rectified. The reality is that the
SF administrative staff has been incredibly helpful to us over the years,
they are easily reachable, and they believe in what we do.

> Could you also port the project to a better buildsystem, like cmake or
> > meson.
> >
> > Autotools is not a buildsystem to choose to develop for Windows.
>
> The honest true is that autotools work well for a number of people,
> mostly those who cross compile mingw-w64. This does not seem to be true
> when building natively on Windows. I don't have experience with building
> on Windows (so I'm one of those for whom it works well), but I think
> that if there is anything we can do to improve native experience, we
> should seriously consider it. Windows support should obviously be
> important for the project. I'd be open to discuss changing build system,
> but the bottom line is that it's a lot of work, it's not something we
> can do easily.
>

As I pointed out previously, the use of auto tools by mingw-w64 doesn't
stop anyone from using whatever they want in their own project. If you're
building mingw-w64, you're building gcc anyway, so what difference does it
make? You need a GNU environment (that's the G in our name after all!), so
running a configure script isn't really an additional requirement. Whereas
cmake would absolutely be a new requirement.

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

‪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 things.  I personally prefer patch
trackers vs emailed attachments, and we can use the patch tracker, but
many more prefer the mailing list.

>> Using mailing-list for that is a way that's not suitable for young
> generation (including me).

Mailing lists allow reaching a broader range of users that aren't
able, for whatever reason, to use a fancy website based system.  It's
more accessible (for example, if a person needs various assist tools);
it's easier for those in areas where they shut off the electricity for
18 hours a day; it's easier for third parties to mirror the archives;
it's not tied to a single corporate host (the email isn't; obviously
SF is just as corporate as GH/MS).  There's a lot more to it than just
"I like pretty websites."

> Many people try to report bugs or propose changes but ended up ignored
> because of this insist on using this outdated technology!

Do you have data to quantify "many"?

Generally speaking, we don't actively ignore our users.  In fact, this
project was founded on the principle of the opposite.  However, there
are finite limits on volunteer time to respond to everything, and
things fall through the cracks (whether it's an email or an issue in a
tracker).

> Could you also port the project to a better buildsystem, like cmake or
> meson.

Those are not better build systems.

> Autotools is not a buildsystem to choose to develop for Windows.

How do you expect to build GCC without the ability to run shell scripts?

In any case, I think you might be confused.  The choice of autotools
for mingw-w64 doesn't preclude you from using cmake in your own
project.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 +-
>  mingw-w64-libraries/winpthreads/src/thread.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mingw-w64-libraries/winpthreads/include/pthread.h 
> b/mingw-w64-libraries/winpthreads/include/pthread.h
> index fe0e821ce..5aadb1cfa 100644
> --- a/mingw-w64-libraries/winpthreads/include/pthread.h
> +++ b/mingw-w64-libraries/winpthreads/include/pthread.h
> @@ -393,7 +393,7 @@ int WINPTHREAD_API pthread_barrierattr_getpshared(void 
> **attr, int *s);
>  /* Private extensions for analysis and internal use.  */
>  struct _pthread_cleanup ** WINPTHREAD_API pthread_getclean (void);
>  void * WINPTHREAD_API pthread_gethandle (pthread_t t);
> -void * WINPTHREAD_API pthread_getevent ();
> +void * WINPTHREAD_API pthread_getevent (void);
>
>  unsigned long long WINPTHREAD_API _pthread_rel_time_in_ms(const 
> struct timespec *ts);
>  unsigned long long WINPTHREAD_API _pthread_time_in_ms(void);
> diff --git a/mingw-w64-libraries/winpthreads/src/thread.c 
> b/mingw-w64-libraries/winpthreads/src/thread.c
> index 55361aec9..e3edbae8a 100644
> --- a/mingw-w64-libraries/winpthreads/src/thread.c
> +++ b/mingw-w64-libraries/winpthreads/src/thread.c
> @@ -1038,7 +1038,7 @@ pthread_self (void)
>
>  /* Internal helper for getting event handle of thread T.  */
>  void *
> -pthread_getevent ()
> +pthread_getevent (void)
>  {
>_pthread_v *t = __pthread_self_lite ();
>return (!t ? NULL : t->evStart);

Adding unnecessary spam because of yet another poor choice of clang is
not something we should be catering towards.  Users can compile with
-Wno-strict-prototypes if it bothers them that much.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] SJLJ GCC

[NightStrike]

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 personal build section
> >
> > On Fri, Sep 17, 2021, 02:01 Ralph Engels  wrote:
> >
> >> P.s you are welcome to link to or upload the sjlj build with ada on the
> >> mingw-w64 site if anyone else sees use for it :)  i can also provide TDM
> >> based versions which default to linking to the static gcc runtimes.
> >>
> >> The TDM versions also accept ASLR and DEP now.
> >>
> >> Den 17-09-2021 kl. 07:47 skrev sotrdg sotrdg:
> >>> C++ exception handling is a mistake. No matter it is sjlj, dwarf or SEH
> >>>
> >>> Sent from Mail <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@lists.sourceforge.net
> >>> <mailto:mingw-w64-public@lists.sourceforge.net>
> >>> *Subject: *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 mingw and many years it did its job just fine :),
> >>>> it is a bit slower but it is by no means a game breaker.
> >>> Given that I was the one identifying and testing all of the issues
> >>> sjlj caused, I can assure you it did not work well in the beginning :P
> >>>   It worked better than dw2, though.  In any case, when we got SEH,
> >>> pretty much everything dropped sjlj unless they had a 32-bit need.
> >>>
> >>>
> >>> ___
> >>> Mingw-w64-public mailing list
> >>> Mingw-w64-public@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >>> <https://lists.sourceforge.net/lists/listinfo/mingw-w64-public>
> >>>
> >> ___
> >> Mingw-w64-public mailing list
> >> Mingw-w64-public@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >>
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 compiling Qt.
>
> https://github.com/DavidEGrayson/nixcrpkgs/blob/master/mingw-w64/gcc/default.nix

Can you submit these to GCC so that local patches aren't needed?


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] SJLJ GCC

[NightStrike]

Do you want upload access? There's already a personal build section

On Fri, Sep 17, 2021, 02:01 Ralph Engels  wrote:

> P.s you are welcome to link to or upload the sjlj build with ada on the
> mingw-w64 site if anyone else sees use for it :)  i can also provide TDM
> based versions which default to linking to the static gcc runtimes.
>
> The TDM versions also accept ASLR and DEP now.
>
> Den 17-09-2021 kl. 07:47 skrev sotrdg sotrdg:
> >
> > C++ exception handling is a mistake. No matter it is sjlj, dwarf or SEH
> >
> > Sent from Mail <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@lists.sourceforge.net
> > <mailto:mingw-w64-public@lists.sourceforge.net>
> > *Subject: *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 mingw and many years it did its job just fine :),
> > > it is a bit slower but it is by no means a game breaker.
> >
> > Given that I was the one identifying and testing all of the issues
> > sjlj caused, I can assure you it did not work well in the beginning :P
> >  It worked better than dw2, though.  In any case, when we got SEH,
> > pretty much everything dropped sjlj unless they had a 32-bit need.
> >
> >
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> > <https://lists.sourceforge.net/lists/listinfo/mingw-w64-public>
> >
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] SJLJ GCC

[NightStrike]

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 mingw and many years it did its job just fine :),
> it is a bit slower but it is by no means a game breaker.

Given that I was the one identifying and testing all of the issues
sjlj caused, I can assure you it did not work well in the beginning :P
 It worked better than dw2, though.  In any case, when we got SEH,
pretty much everything dropped sjlj unless they had a 32-bit need.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] SJLJ GCC

[NightStrike]

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 less well tested, so generally
not recommended.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] contributions

[NightStrike]

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 suggestions for improvements the reason for the fork
> of MinGW-w64 from MinGW years ago?

Yes, that's exactly the reason.

You essentially followed the procedure indirectly, and so the
responses you got sort of skipped a step.

Generally, you post a patch to this ML, people review it and discuss
it, and then you commit if you have access or others commit it for
you.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] contributions

[NightStrike]

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 implementation within windows in a specific environment, things like
> posix symlinks etc.

The scope of libmingwex is poorly defined.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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:
> >
> > struct timespec * ts << "ts" is redundant here
> > int timespec << assuming it is such a thing, here, the variable name
> > tells you what the "int" is
> >
> > In your case, just about every single parameter name can just be removed.
> >
> > I'm working in a branch to do this to the crt (so that we can pass the
> > libstdc++ testsuite), but we shouldn't introduce new headers with the
> > problem.
> >
>
> I do believe there is such a requirement on CRT headers, but it should not 
> apply to Windows headers.
> CRT headers are not meant to include Windows ones.
>
> In addition, those macros,  functions, struct/union members and tags can't be 
> renamed, either, so we
> gain no more standard conformance form such uglification.

I only mentioned function parameters


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 quickly without opening a web
> browser header files are handy at that time.
> 3. If there is any wrong in code the compiler output shows the
> functions parameters which also helps.
> 4. Just asking. If a simple function parameters cause test failure,
> should not those tests need a fix? These headers are not included in
> any crt files.
>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 system APIs
> >
> > Signed-off-by: Biswapriyo Nath
> > ---
> >   mingw-w64-headers/include/computecore.h|  82 ++
> >   mingw-w64-headers/include/computedefs.h| 119 +
> >   mingw-w64-headers/include/computenetwork.h |  92 
> >   mingw-w64-headers/include/computestorage.h |  40 +++
> >   4 files changed, 333 insertions(+)
> >   create mode 100644 mingw-w64-headers/include/computecore.h
> >   create mode 100644 mingw-w64-headers/include/computedefs.h
> >   create mode 100644 mingw-w64-headers/include/computenetwork.h
> >   create mode 100644 mingw-w64-headers/include/computestorage.h
>
> Thanks, patch looks good to me. I pushed it to master.

All of those function parameters need to be uglified or removed.  I
personally prefer removing them when they provide no additional
context.  Example:

struct timespec * ts << "ts" is redundant here
int timespec << assuming it is such a thing, here, the variable name
tells you what the "int" is

In your case, just about every single parameter name can just be removed.

I'm working in a branch to do this to the crt (so that we can pass the
libstdc++ testsuite), but we shouldn't introduce new headers with the
problem.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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.

>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 and thanks for mingw-w64, Joachim
>

1) he's a troll that's upset because nobody of consequence uses his stuff
anymore

2) he registered that name 8 years after we were using ours, and it only
got approved 13 years after we started this project

3) he is assuming that a US trademark affects the global user base, which
it does not

Bottom line, his project will eventually fade away into obscurity.

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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, I can inquire
about doing so.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 "!$omp do schedule(dynamic,1)"
> produce slightly different result at time to time.
> This does not happen with GCC on FreeBSD and NAG on Windows.
> So,  I think nothing is wrong in my code. (But, I'm not 100% sure.)
> Mingw-w64 which I installed is the latest package for msys2.
>
> For those who are interested in this problem,
> I attach a sample code which reproduce the problem.
> (This may not be appropriate for mailing list. I'm sorry).
> If you run the program several times, you will get slightly
> different fort.99 at time to time.
> Perhaps this problem has root in POSIX threading in mingw-w64.
>
> Any comments and suggestions will be appreciated.
>
> Best,
> Takashi
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 tools?

Most of the code developed specifically for this project (ie,
winpthreads) is supposed to be in GNU format.  Code that is from the
header set is a mixture of inheritance from mingw.org and a result of
the whitebox porting of MS headers that was done.  Other code is
directly imported from other projects, such as Wine.  In many cases,
these self-inconsistencies are intentional to be compatible with these
external projects.  It's not a simple matter of saying "apply this
ruleset" as it might be in a small, self-contained project.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

Sadly, I don't have control over that domain :(

On Tue, Feb 4, 2020 at 9:53 PM Zach Bacon  wrote:
>
> to be fair, with the use of let's encrypt, one could easily setup an
> autorenewal of ssl certs potentially making the issue less of one if it's
> that important.
>
> 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
> > > update it!
> > >
> > > Downloading a toolchain from a non-https site is not a good idea...
> > >
> > > --
> > > Sincerely,
> > > Alex Parrill
> > >
> > >
> > > ___
> > > Mingw-w64-public mailing list
> > > Mingw-w64-public@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> > >
> >
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 reverse engineer or
white room engineer them.

>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 to support
> XP.

To be pedantic, we only ever officially supported XP64 as the base OS,
which is the 32-bit equivalent of Server 2003.  32-bit XP is actually
on an older kernel than 2k3 and XP64.

Also, to be more pedantic... the OP talks about applications built to
run on older systems.  You can certainly change the header in your own
version and build for an older system and it should work.  You're just
on your own for support.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 libraries (e.g. MSVCRT).  Since
> > all libraries ultimately rely on Kernel32, it only makes sense to
> > replace these POSIX functions with those from Kernel32, especially
> > since they have almost identical substitutes.  See also:
> > https://support.microsoft.com/en-us/help/99456/win32-equivalents-for-c-run-time-functions
>
> If you can manage to do that, that would be very nice, indeed.
> Also, maybe the compilers have builtins for some of those.

A number of builtins do some cursory optimization before calling out
to the library anyway.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 Kernel32, it only makes sense to
> replace these POSIX functions with those from Kernel32, especially
> since they have almost identical substitutes.  See also:
> https://support.microsoft.com/en-us/help/99456/win32-equivalents-for-c-run-time-functions
>
> Compling the most simplistic program tells you about everything missing.
>
> > emptymain.c
> int main(int argc,char** argv) { return 0; }
>
> > compilation command
> i686-w64-mingw32-gcc -o emptymain.exe emptymain.c -nodefaultlibs
> -lmingw32 -lkernel32
>
> > examples of undefined POSIX symbols
> mingw-w64-crt/crt/crtexe.c:423: `malloc'
> mingw-w64-crt/crt/crtexe.c:428: `strlen'
> mingw-w64-crt/crt/crtexe.c:429: `malloc'
> mingw-w64-crt/crt/crtexe.c:430: `memcpy'
> mingw-w64-crt/crt/crtexe.c:342: `exit'
> mingw-w64-crt/crt/merr.c:72: `fprintf'
> mingw-w64-crt/crt/pseudo-reloc.c:149: `fwrite'
> mingw-w64-crt/crt/pseudo-reloc.c:150: `vfprintf'
> mingw-w64-crt/crt/pseudo-reloc.c:156: `abort'
> mingw-w64-crt/crt/crt_handler.c:many: `signal'
> mingw-w64-crt/crt/tlsthrd.c:48: `calloc'
> mingw-w64-crt/crt/pesect.c:88: `strncmp'
> mingw-w64-crt/crt/tlsthrd.c:87: `free'
> mingw-w64-crt/crt/tlsthrd.c:141: `free'
> mingw-w64-crt/crt/pesect.c:75: `strlen'
> mingw-w64-crt/crt/pesect.c:88: `strncmp'

If you would like to demonstrate this change, you will have better
luck by supplying a patch.  A cursory glance shows that there aren't
universale drop in replacements for everything like you suggest.
fprintf and vfprintf, for instance, are listed as "none" on that page
you linked.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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, Jun 28, 2019 at 6:51 AM
Subject: [patch] Reimplement GNU threads library on native Windows
To: 
Cc: 


Hi,

this reimplements the GNU threads library on native Windows (except for the
Objective-C specific subset) using direct Win32 API calls, in lieu of the
implementation based on semaphores.  This base implementations requires
Windows XP/Server 2003, which is the default minimal setting of MinGW-W64.
This also adds the support required for the C++11 threads, using again direct
Win32 API calls; this additional layer requires Windows Vista/Server 2008 and
is enabled only if _GTHREADS_USE_COND is defined to 1.

This also changes libstdc++ to setting _GTHREADS_USE_COND to 1 when the switch
--enable-libstdcxx-threads is passed, which means that C++11 threads are still
disabled by default on native Windows and that you need to explicitly pass the
switch to enable them.  The 30_threads chapter of the testsuite is clean.

Tested on i686-pc-mingw32 and x86_64-pc-mingw32, OK for the mainline?


2019-06-28  Eric Botcazou  

libgcc/
* config.host (i[34567]86-*-mingw*): Add thread fragment after EH one
as well as new i386/t-slibgcc-mingw fragment.
(x86_64-*-mingw*): Likewise.
* config/i386/gthr-win32.h: If _GTHREADS_USE_COND is 1, define both
__GTHREAD_HAS_COND & __GTHREADS_CXX0X to 1 and _WIN32_WINNT to 0x0600.
Error out if _GTHREAD_USE_MUTEX_TIMEDLOCK is 1.
Include stdlib.h instead of errno.h and do not include _mingw.h.
(CONST_CAST2): Add specific definition for C++.
(ATTRIBUTE_UNUSED): New macro.
(__UNUSED_PARAM): Delete.
Define WIN32_LEAN_AND_MEAN before including windows.h.
(__gthread_objc_data_tls): Use TLS_OUT_OF_INDEXES instead of (DWORD)-1.
(__gthread_objc_init_thread_system): Likewise.
(__gthread_objc_thread_get_data): Minor tweak.
(__gthread_objc_condition_allocate): Use ATTRIBUTE_UNUSED.
(__gthread_objc_condition_deallocate): Likewise.
(__gthread_objc_condition_wait): Likewise.
(__gthread_objc_condition_broadcast): Likewise.
(__gthread_objc_condition_signal): Likewise.
Include sys/time.h.
(__gthr_win32_DWORD): New typedef.
(__gthr_win32_HANDLE): Likewise.
(__gthr_win32_CRITICAL_SECTION): Likewise.
(__gthr_win32_CONDITION_VARIABLE): Likewise.
(__gthread_t): Adjust.
(__gthread_key_t): Likewise.
(__gthread_mutex_t): Likewise.
(__gthread_recursive_mutex_t): Likewise.
(__gthread_cond_t): New typedef.
(__gthread_time_t): Likewise.
(__GTHREAD_MUTEX_INIT_DEFAULT): Delete.
(__GTHREAD_RECURSIVE_MUTEX_INIT_DEFAULT): Likewise.
(__GTHREAD_COND_INIT_FUNCTION): Define.
(__GTHREAD_TIME_INIT): Likewise.
(__gthr_i486_lock_cmp_xchg): Delete.
(__gthr_win32_create): Declare.
(__gthr_win32_join): Likewise.
(__gthr_win32_self): Likewise.
(__gthr_win32_detach): Likewise.
(__gthr_win32_equal): Likewise.
(__gthr_win32_yield): Likewise.
(__gthr_win32_mutex_destroy): Likewise.
(__gthr_win32_cond_init_function): Likewise if _GTHREADS_USE_COND is 1.
(__gthr_win32_cond_broadcast): Likewise.
(__gthr_win32_cond_signal): Likewise.
(__gthr_win32_cond_wait): Likewise.
(__gthr_win32_cond_timedwait): Likewise.
(__gthr_win32_recursive_mutex_init_function): Delete.
(__gthr_win32_recursive_mutex_lock): Likewise.
(__gthr_win32_recursive_mutex_unlock): Likewise.
(__gthr_win32_recursive_mutex_destroy): Likewise.
(__gthread_create): New inline function.
(__gthread_join): Likewise.
(__gthread_self): Likewise.
(__gthread_detach): Likewise.
(__gthread_equal): Likewise.
(__gthread_yield): Likewise.
(__gthread_cond_init_function): Likewise if _GTHREADS_USE_COND is 1.
(__gthread_cond_broadcast): Likewise.
(__gthread_cond_signal): Likewise.
(__gthread_cond_wait): Likewise.
(__gthread_cond_timedwait): Likewise.
(__GTHREAD_WIN32_INLINE): New macro.
(__GTHREAD_WIN32_COND_INLINE): Likewise.
(__GTHREAD_WIN32_ACTIVE_P): Likewise.
Define WIN32_LEAN_AND_MEAN before including windows.h.
(__gthread_once): Minor tweaks.
(__gthread_key_create): Use ATTRIBUTE_UNUSED and TLS_OUT_OF_INDEXES.
(__gthread_key_delete): Minor tweak.
(__gthread_getspecific): Likewise.
(__gthread_setspecific): Likewise.
(__gthread_mutex_init_function): Reimplement.
(__gthread_mutex_destroy): Likewise.

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

[NightStrike]

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
> > so the TestBot can run them for every patch that gets submitted: if
> > patches come at a rate of about one per hour, then the TestBot needs to
> > process the resulting jobs at a rate of at least one per hour. That said
> > we already need new hardware for PCI-passthrough for Wine (though the
> > exact details are not set yet).
>
> Those projects are rather large, so either you need quite beefy hardware,
> or you just run some smaller test setup for each patch (rebuild mingw-w64
> and build a few smoketests maybe?) and then run a full build of those
> projects e.g. nightly (e.g. with a known good pinned version of those
> projects, which can be updated regularly). That requires a bit more manual
> intervention every time there's a regression though.
>

For the build bot I used to run, a full build of gcc and its test suite
would take several days for the cygwin target and host.

I mention that because in my experience, it's far more important to test
against the breakages due to compiler changes rather than the comparatively
small things that change day to day on mingw. Very few people on gcc test
their changes on w64 (Jonathan Wakely is a recent notable exception), and
this tends to cause entire languages to break (see Ada for example).

>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 relationship for years. Recent Wine move to using PE
> files for its builds led us to revisit those ideas. My feeling so far is
> that there is an agreement among people I heard from that it's a good
> direction for both projects to have mingw-w64 under an umbrella of the
> Wine project.

I've never heard this before, but I would tend to disagree that this
is a good direction.  For some history here, I will highlight that I
am a huge proponent of collaboration.  If you recall, Jacek, it was me
that wandered into your IRC channel over ten years ago now begging for
your help on this project, and it's been a very long (and productive!)
road since then.  Admittedly, my participation has dropped off
considerably given my current occupation, but I pushed hard for the
same collaboration with many other projects: Firefox, ReactOS, Fedora,
Ubuntu, Cygwin, every open source game I could find, even Chromium
(that one didn't work out).  In all cases, we pushed for
collaboration, not takeovers.  A prime example of this is msys2, which
was incubated as a subproject under mingw-w64, but rapidly grew into
its own.

> It would be great to move forward with this. Let me discuss a few
> aspects of the idea.
>
> - Infrastructure
>
> mingw-w64 currently mostly depends heavily on SourceForge. While I'm
> thankful to SF for years of free support, it's doesn't feel like an
> optimal choice those days.

Why not?  SF provides a tremendous amount of service for free, with
impeccable uptime.  There was a point in time where we were uploading
several terabytes a day to the file storage area, for instance.  They
supported this with no issue.  They provide near immediate service via
IRC, and offer a lot of additional capability that we could take
advantage of if we needed to.

> Wine has its own infrastructure that
> mingw-w64 could use right away. Moving things like mailing list, bug
> tracker, etc. is straightforward to do, except for one thing... how
> should it be called? Which brings us to the next item.

What functionality does Wine provide that exceeds what we currently
have that we couldn't take advantage of today?

> - mingw-w64 name
>
> There have been talks about rebranding mingw-w64 for a long time (longer
> than I am in joined the project). While it's a good name for a branch,
> an established project that is no longer related to mingw.org could have
> a better branding. Kai mentioned that ironcrate was considered as some
> point, but to my knowledge no action was taken at that time. Alexandre
> offered lately that Wine brand could be used for mingw-w64 as well. I
> personally like the idea. Wine is already well recognised brand and
> brings roughly right associations. So... how about WineSDK?

Absolutely not.  First, ironcrate was a codename for development
efforts of subprojects within mingw-w64, the largest of which was
winpthreads.  But second, mingw-w64 is a well established brand that
is today significantly more recognizable than the predecessor
mingw.org.  There is a very high cost of changing names, which is why
we haven't done it yet.  I don't see any upside of doing so.

> - Source code sharing
>
> Technically, we could share much more code than we currently do.
> Duplicating efforts is quite suboptimal for everyone. Right now
> mingw-w64 imports a number of platform headers and widl tool from Wine
> via wine-import.sh script. Wine has a few headers imported from
> mingw-w64 as well. It works to some extend, but the fact is that we
> still duplicate more than we share. I'm not yet sure how to fix that
> entirely, but I'd like us to have a workflow that would limit the
> duplication.

This has nothing to do with the stated goals of the email.  We could
share code better today without changing anything.

> - Testing
>
> Wine has a TestBot and a number of test cases, which is a great tool for
> developers to make sure their patches are right. mingw-w64 does not have
> such thing and mostly depends on developers doing their own testing and
> regression reports after the patch is committed. We could integrate
> mingw-w64 testing with Wine TestBot to make sure that we don't break
> things (well, at least limit that possibility). I believe that it would
> nicely accelerate mingw-w64 development workflow as well as ensure that
> mingw-w64+Wine don't regress.

This also has nothing to do with the stated goals of the email.  We
could use the TestBot today without changing anything.  As a concrete
example, we did this for YEARS with the reactOS buildbot until
interest in that waned and ReactOS stopped providing the buildbot
server.  We did daily builds of mingw, gcc, and binutils, and ran the
full testsuite of all of them weekly (natively 

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

[NightStrike]

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 shipping a full set of OpenGL headers in
> MinGW-w64-headers is a good idea, here's the patch that updates the
> headers to
> a fresh git revision.
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 styles.
>
> I am afraid not. Our repository has been developing for many years with
> contributions from many people; it is almost impossible to have all
> people agree on a specific coding style. When people start to agree on
> such divergence, the crucial thing is to make you ideas clear and easy
> to be understood. In addition, a single commit altering more code is
> more subject to likelihood of conflicts, should it be backported.
>

Generally speaking, winpthreads was made to use the GNU style.

>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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.

>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 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^[=^[[?1l^[>
> >
> > For instance:
> >
> > ^[[?1h^[=^[[?1l^[>PASS: gcc.dg/ipa/ipa-pta-1.c execution test
> >
> > This generally doesn't cause a problem, except in the case of some
> > fortran output pattern tests that try to patch ^string$.  In that
> > case, the regex fails, as it pulls in the escape sequences as part of
> > "string".
> >
> > To run the testsuite under wine, I created a simulator board that uses
> > "wine64" as the simulator that prefixes every spawned test.  I ran
> > this manually myself, and I do not get any extra characters, so I do
> > not think that it's wine related.
> >
> > Does anyone have any experience with this, or suggestions on what to do?
>
> It looks like this is definitely wine.  Running it standalone under
> strace shows this towards the end:
>
> stat("/etc/terminfo", {st_mode=S_IFDIR|0755, st_size=2, ...}) = 0
> access("/etc/terminfo/x/xterm-256color", R_OK) = -1 ENOENT (No such
> file or directory)
> stat("/usr/share/terminfo", {st_mode=S_IFDIR|0755, st_size=22, ...}) = 0
> access("/usr/share/terminfo/x/xterm-256color", R_OK) = 0
> open("/usr/share/terminfo/x/xterm-256color", O_RDONLY) = 10
> read(10, "\32\1%\0&\0\17\0\235\1\251\5xterm-256color|xterm"..., 4097) = 3322
> close(10)   = 0
> ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B38400 opost isig icanon echo ...}) = 0
> ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B38400 opost isig icanon echo ...}) = 0
> ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
> TCGETS, {B38400 opost isig icanon echo ...}) = 0
> ioctl(1, TIOCGWINSZ, {ws_row=68, ws_col=209, ws_xpixel=0, ws_ypixel=0}) = 0
> open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 10
> fstat(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7ff2b72f9000
> read(10, "MemTotal:   297772936 kB\nMem"..., 1024) = 1024
> close(10)   = 0
> munmap(0x7ff2b72f9000, 4096)= 0
> write(1, "\33", 1 = 1
> write(1, "[", 1[)= 1
> write(1, "?", 1?)= 1
> write(1, "1", 11)= 1
> write(1, "h", 1h)= 1
> write(1, "\33", 1 = 1
> write(1, "=", 1=)= 1
>
>
>
> Any idea how to tell dejagnu to strip this out?

I rebuilt wine with --without-curses, and it looks like the problem
has gone away.  Success!

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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, the log files get filled with what appears to be ANSI escape
> sequences of the form:
>
> ^[[?1h^[=^[[?1l^[>
>
> For instance:
>
> ^[[?1h^[=^[[?1l^[>PASS: gcc.dg/ipa/ipa-pta-1.c execution test
>
> This generally doesn't cause a problem, except in the case of some
> fortran output pattern tests that try to patch ^string$.  In that
> case, the regex fails, as it pulls in the escape sequences as part of
> "string".
>
> To run the testsuite under wine, I created a simulator board that uses
> "wine64" as the simulator that prefixes every spawned test.  I ran
> this manually myself, and I do not get any extra characters, so I do
> not think that it's wine related.
>
> Does anyone have any experience with this, or suggestions on what to do?

It looks like this is definitely wine.  Running it standalone under
strace shows this towards the end:

stat("/etc/terminfo", {st_mode=S_IFDIR|0755, st_size=2, ...}) = 0
access("/etc/terminfo/x/xterm-256color", R_OK) = -1 ENOENT (No such
file or directory)
stat("/usr/share/terminfo", {st_mode=S_IFDIR|0755, st_size=22, ...}) = 0
access("/usr/share/terminfo/x/xterm-256color", R_OK) = 0
open("/usr/share/terminfo/x/xterm-256color", O_RDONLY) = 10
read(10, "\32\1%\0&\0\17\0\235\1\251\5xterm-256color|xterm"..., 4097) = 3322
close(10)   = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or
TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCGWINSZ, {ws_row=68, ws_col=209, ws_xpixel=0, ws_ypixel=0}) = 0
open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 10
fstat(10, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7ff2b72f9000
read(10, "MemTotal:   297772936 kB\nMem"..., 1024) = 1024
close(10)   = 0
munmap(0x7ff2b72f9000, 4096)= 0
write(1, "\33", 1 = 1
write(1, "[", 1[)= 1
write(1, "?", 1?)= 1
write(1, "1", 11)= 1
write(1, "h", 1h)= 1
write(1, "\33", 1 = 1
write(1, "=", 1=)= 1



Any idea how to tell dejagnu to strip this out?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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^[=^[[?1l^[>

For instance:

^[[?1h^[=^[[?1l^[>PASS: gcc.dg/ipa/ipa-pta-1.c execution test

This generally doesn't cause a problem, except in the case of some
fortran output pattern tests that try to patch ^string$.  In that
case, the regex fails, as it pulls in the escape sequences as part of
"string".

To run the testsuite under wine, I created a simulator board that uses
"wine64" as the simulator that prefixes every spawned test.  I ran
this manually myself, and I do not get any extra characters, so I do
not think that it's wine related.

Does anyone have any experience with this, or suggestions on what to do?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

>
> 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 that if they compiler can deduce
any optimization, it'll take it. For instance, if it knows you want the
square root of 4, it'll remove the instruction entirely and just use the
number 2.

There's also unsafe math optimizations to consider.

>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 patches.  But I agree with you, don't do it.
>
> A google search turned up a few other hits:
>
>   * text/x-diff
>   * application/x-patch

text/x-diff is there as of 36 minutes ago.

We have text/x-patch, not application/x-patch.  I don't understand the
difference.  Do you?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 think application/octet-stream is something we would want to
enable.  Doesn't that sound like something that would be abused?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 have gotten an email stating that his
messages were being held in a moderation queue.  It should have given
him the option to either wait for one of us to allow it, or subscribe
to the list.  Eventually, they were released.

I try to check it daily, but sometimes others beat me to it.  This is
a courtesy to encourage contributions from those who don't want to
subscribe.  The cost of that courtesy is latency.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

Do you know what content type you attached as?  We have to explicitly
allow each type.  The current list is:

application/pgp-signature
multipart/mixed
multipart/alternative
multipart/signed
text/plain
text/x-patch

If the content type is left unspecified, then the attachment is
deleted.  I can 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
> attachment is visible in the archive here:
>
> https://sourceforge.net/p/mingw-w64/mailman/message/35729302/
>
> --David Grayson
>
> On Sun, Mar 19, 2017 at 7:03 PM, NightStrike <nightstr...@gmail.com> wrote:
>
>> On Mar 16, 2017 1:40 PM, "Liu Hao" <lh_mo...@126.com> 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
>> > patch fixes that.
>> Please send the patch both inline and as an attachment, since SF mailing
>> lists swallow attachments frequently.
>>
>>
>> It shouldn't. If it does, tell me and I'll address it. I believe I already
>> fixed one issue you brought up a while ago. I haven't seen any since.
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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
> patch fixes that.
Please send the patch both inline and as an attachment, since SF mailing
lists swallow attachments frequently.


It shouldn't. If it does, tell me and I'll address it. I believe I already
fixed one issue you brought up a while ago. I haven't seen any since.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 be a project with ~700MB of (closed)
source.


You should try at least opening a bugzilla report and emailing the list.
The binutils people are very friendly and eager to help. They don't
typically take the approach of not helping just because you are on windows.

You mentioned a Mingw-w64 64bit to 32bit cross-compiler; it sounds like
that may avoid any such issues in future for us - do you happen to know if
anyone is building such a thing regularly and where?


Would you be interested in learning how to build it yourself? It's pretty
straightforward, and doing so would allow you to test any potential fixes
that the upstream projects might come up with. Since as you say you are
closed source, nobody else can test fixes. If you cross compile from Linux,
the build process of the toolchain goes much faster. In fact, if you can
demonstrate the problem with a Linux hosted toolchain, then it's much
easier to troubleshoot.

Additionally, if you learn to build the toolchain yourself, and you build
the problematic host/ target combination, you can build with tools like the
address sanitizer that will possibly help fix the problem.

To that end, have you tried running with tools like perfmon.exe to check
the total virtual memory in use across both private and shared memory? This
may be of more value than trying to catch the poling interval of task
manager (though task manager does allow showing better memory statistics
than the default).
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

On Tue, Mar 7, 2017 at 11:38 AM, Ozkan Sezer <seze...@gmail.com> wrote:
> On 3/7/17, Ozkan Sezer <seze...@gmail.com> wrote:
>> Several gendef updates were pushed to the git repo, one to fix
>> a use-after-free, one to sig a segfault (bug#592), one to fix an
>> unbalanced #pragma pack, etc.
>>
>> There is one configury issue I didn't touch: If I configure with
>>  --with-mangle=/some/path switch, the library functions checks
>> i.e. memset, strdup, strlwr and strrchr fail. config.log says that
>> it cannot find -lmangle around 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 fine: a patch is attached, Ok to apply?

I don't quite understand why moving those header checks earlier makes
it all work, but there's nothing inherently wrong with the patch, so
go for it.

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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
> >>
> >> I've successfully compiled a cross compiler that runs on linux. Now
> >> I'm using that compiler to produce a GNU Toolchain that  executes on
> >> windows.
> >>
> >> I exported the PATH to point it to the location of the toolchain and
> >> I've made managed to reach the last step: build the final version of
> >> GCC. However I get this error:
> >>
> >> ../../../gcc-6.2.0/libgcc/libgcc2.c:557:1: warning: control reaches
> >> end of non-void function [-Wreturn-type]
> >>  }
> >>  ^
> >> Makefile:467: set di istruzioni per l'obiettivo "_muldi3.o" non
riuscito
> >> make[1]: *** [_muldi3.o] Errore 1
> >> make[1]: uscita dalla directory
> >> "/home/michele/MinGW-Win32/gcc-build/i686-w64-mingw32/libgcc"
> >> Makefile:13034: set di istruzioni per l'obiettivo "all-target-libgcc"
> >> non riuscito
> >> make: *** [all-target-libgcc] Errore 2
>
> That is just a warning, the error message is printed earlier. And please
> disable the internationalization so it prints in English.

How do I disable it? I can tranalate errors in English if you want


/configure --disable-nls
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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

Ok, you're either extremely confused, or simply trolling.  Either way,
I can't help you any longer.  Please take your misunderstandings of
C++ elsewhere.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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. sorry for the bumpy ride.

This is, like your previous issue, due to your lack of understanding
the rules of C++ (specifically, the C++ Standard Library).  You should
make use of cppreference.com, as it's a very good information source
here.  If you did, you'd see this:

http://en.cppreference.com/w/cpp/regex/regex_match
"...Determines if there is a match between the regular expression e
and the entire target character sequence [first,last)"

What you really want is this:

http://en.cppreference.com/w/cpp/regex/regex_search
"Determines if there is a match between the regular expression e
and some subsequence in the target character sequence"

Notice the difference?  The function you are using matches on the
entire string, and thus only returns true if the regex is true for the
entire string.  The second function operates on a substring, which is
what you want here.  It's more like "grep" in this regard, if that
analogy works for you.

Please try to read the documentation of the language.

> the function below is an old namespace clash bug between user-defined str
> and compiler's std for string and maybe algorithm.

No, it was your incorrect use of namespace syntax.  The compiler is fine.

> I could suppose it might be 10 years for a fix for that to reach gcc...
> :-( I know you folks are really busy. I just want a working and hopefully
> up-to-date compiler from somewhere for windows that isn't waving the
> dragon flag (you've *got* to be serious folks, those things are nasty).

I think you should update your knowledge of the language.  I also
think you should ask these basic, fundamental language questions in a
forum that is geared toward this sort of thing.  You have been
emailing this list for years now, and aside from one or two exceptions
(you did point out a valid bug or two), every email has been off
topic.  We are generally pretty lenient, and try to be a helpful
audience.  But then, you aren't very nice about it, either.  Honestly,
you're kind of a mean, highly insulting person that demands basic
"google search" help on the wrong topic from the wrong people.  I
don't understand why you do this repeatedly, year after year.

I hope you realize what mingw-w64 is and is not:  It is a project that
provides headers and imports to the Windows APIs.  As a nicety, we
also host some compiler toolchains that kind people build as a
convenience ONLY.  We are *NOT* GCC.  You can find that project at
gcc.gnu.org, whereas we are at mingw-w64.sf.net.  We are also not a
general programming help forum.  We tend to be nice people that help
each other out, and I myself have asked lots of questions over the
years that are unrelated to mingw-w64, both on the list and mainly in
IRC.  But just like you wouldn't try to buy postage stamps at a
restaurant, you are really barking up the wrong tree here.  I think,
honestly, what you really need is a good programming resource or
tutor.  Perhaps lynda.com can be of help here, or
irc://irc.freenode.net/##C++-general

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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::tolower(s[i]);
> }
> return s;
> }
> }
> here's another one, compile that and see if it throws error messages about
> declaring a std::string in an arg. it's in a namespace str.

You aren't using the language correctly here.  When you do something like this:

namespace str {
// .
}

Everything inside there implicitly is part of the str namespace.  So doing this:

namespace str {
int str::i();
}

is not doing what you think it's doing.  That's creating essentially this:

::str::str::i();

So basically, to fix your code snippet, change this:

 std::string str::localestringlower(std::string s) {

to:

 std::string localestringlower(std::string s) {

Or, define it outside of the namespace str { } block and leave the
namespace qualifier in tact.


I suggest you read up on the syntax of the language, and specifically
how names in C++ are qualified.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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_constants::extended |
> (icase?std::regex_constants::icase:0)); i++);

What are you trying to accomplish with this code?  It's difficult to
read.  You'll probably increase your likelihood of getting help if you
provide a clear, easily understood example that demonstrates a
problem, and specify exactly what that problem is.  Putting the
contents of your loop in an unreadable forloop while condition means
that we have to untangle your snippet to even start to help you.  I
doubt that anyone will be willing to help you unless you clean up your
question.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

On Sep 23, 2016 8:08 PM, "David Wohlferd" <d...@limegreensocks.com> wrote:
>
> On 9/23/2016 5:08 AM, JonY wrote:
> > On 9/23/2016 09:50, David Wohlferd wrote:
> >> On 9/22/2016 5:53 AM, JonY wrote:
> >>> On 9/22/2016 20:23, JonY wrote:
> >>>> just remove the mpdecimal directory, the dfp/*.c stuff should
> >>>> still work, likewise for the pformat.c changes. I'm doing just
> >>>> that since yesterday, running build tests. SF ate my GPG signed
> >>>> mail.
> >>>>
> >>>> 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 root directory of mingw-w64.  That regenerated a bunch of files.
>
> To test this, I have run configure, make and make install for each of
> x86, x64 and arm.  These all seem to build correctly.
>
> Nightstrike: Running "make distcheck" now runs a bit further than
> before.  However:
>
> - For x86, all the initial checks complete, but when it tries doing its
> own VPATH build, it fails because of include path issues (it tries to
> build mingw-w64-crt in isolation from mingw-w64-headers). But since the
> normal build succeeds, I don't believe this is a problem.
> - For x64, it fails because pseh is "missing."  Obviously it is missing
> because it's not supported on x64.  I'm not sure why distcheck doesn't
> skip it.
> - For arm, it fails because libmangle is missing.  Not sure how to get
> it to skip this either.

Use AM_DISTCHECK_CONFIGURE_FLAGS to set configure options specifically used
for the distcheck target. For instance, maybe --disable-pseh  (if that's a
thing, I don't know)
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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
>
> --
> Best regards,
> lh_mouse
> 2016-09-08
>
> -
> 发件人：Riot 
> 发送日期：2016-09-08 04:00
> 收件人：mingw-w64-public
> 抄送：
> 主题：Re: [Mingw-w64-public] sinl/cosl/tanl accuracy problem
>
> Some of us (game developers especially) greatly prefer a minor inaccuracy
> to a potentially major slowdown; I would personally opposed this change, as
> you're noticeably increasing the cost of something that's used heavily in
> tightly looped code.  Perhaps an appropriately named #ifdef switch would be
> a way to please everyone here?
>
> Regards,
> Riot
>
>
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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?),

Who ok'd it?

> I think it'd be
> even better to split it further, to one commit per issue.

> There also seems to be a few other changes in the patch not directly
> related to getting rid of warnings:
> - gs_support.c, only whitespace change in UNW_FLAG_NHANDLER, nothing else
>changed on that line?
> - _vswprintf_p.c, _vscwprintf_p.c - these also add a comment that wasn't
>there before. Probably ok, but I guess it's preferrable to have such
>changes split out.
> - aviriff.h, I see no other changes than adding in leading zeros
> - basetyps.h, also only fixing whitespace?
> - mfidl.h, changing hex constants from upper case to lower?
> - winnt.h, removing leading zeros in hex constants?
>
> So I think it'd be better to commit the fixes for each issue (not per
> file, but per issue) separately, with an explanation on what warning/issue
> it fixes, or why it stylistically is preferrable. (E.g. the list of files
> and changes you have only mention "redefine errors" for winnt.h.)

Yes, definitely split it up into smaller commits as described here.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Patches

[NightStrike]

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 configured by someone who knows the mingw-w64-public list
> password.

FWIW, there's a patch tracker on SF that you can upload to:

https://sourceforge.net/p/mingw-w64/patches/

But in any case, I added text/x-patch to the allowed list.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 regenerate Makefile.in, I need to decide what to do:

Make one commit that updates aclocal to v1.15. Make a second commit that
applies your desired changes to both Makefile.am and Makefile.in.

> d) I could regenerate all the build files in the entire project to 1.15
> (some are as old as 1.11.6).

I used to maintain this regularly. In reality, automake doesn't have a
current maintainer, so one more update would be the last for a while.

> But honestly, I'm not particularly comfortable doing any of these.
>
> I generally assume that newer versions fix problems or have other
> benefits, but sometimes they can introduce other issues.  For all I know
> there's a good reason things are the way they are.  And I'm certainly
> not going to be the best qualified to answer any questions or fix any
> problems that may arise as a result of c or d.

When Ralf was the maintainer, it was much easier to blindly update. Now,
new versions do break stuff. But, breakages are typically easy to deal with
swiftly.

> Hopefully someone who knows more about this stuff than I do can check in
> the 'right' fix to get things back in sync.

I can take a crack at it, at least to make everything consistent. There are
ways to force a minimum version, too, to prevent regressions.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 any case, the gcc list and this list are not for general programming
questions. Though we are lax in that rule, you take it pretty far.
On Jun 23, 2016 1:16 AM, "Jim Michaels"  wrote:

> http://www.cpp.sh/4lycn
> bugs in gcc, won't compile
> -
>  Jim Michaels http://www.JesusnJim.com (computer
> repair info, programming)
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 you get angry and aggressive, attacking people for not supporting your
crazy whims. And finally, when the community does sometimes manage to
figure out what is going on in your head, you are often completely way off
in left field somewhere.

I would suggest that you think more carefully before displaying what
appears to be troll behavior. Maybe you'd do well to reread your emails
before you send them, from the standpoint of someone who isn't sitting next
to you and is unaware of what you are actively pursuing.
On Jul 1, 2016 1:13 AM, "Jim Michaels"  wrote:

> double-check memory functions for proper multiplication like memcpy,
> malloc, free, etc.
>
> also check std::string.size() and .length() for proper functionality please
>
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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.
>
> ** Note: the function `memcpy` is declared manually to avoid
> #include'ing any system headers. The prototype MUST match
> the one in the standard library. Renaming it or changing its
> parameters is not allowed in order to reproduce the ICE. **
> ```
> D:\Desktop>cat test.cpp
> extern "C" void *__attribute__((__cdecl__)) memcpy(void *, const void *,
> unsigned);
> auto p = 
>
> D:\Desktop>i686-w64-mingw32-gcc test.cpp
> test.cpp:2:11: internal compiler error: Segmentation fault
>  auto p = 
>^~
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
>
> test.cpp:2:11: internal compiler error: Aborted
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> i686-w64-mingw32-gcc: internal compiler error: Aborted (program cc1plus)
> ```
>
> --
> Best regards,
> lh_mouse
> 2016-07-02
>
>
>
> --
> Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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] Differentiate on MinGW-w64 and TDM-gcc
> on March 15.
>
> After some testing (thanks, lh_mouse) i've discovered that the list drops
> my messages that are signed with PGP/MIME. Messages that are signed with
> inline PGP, as well as unsigned messages, do come through though.
>
> Please fix. While inline PGP signatures work well enough, they add a lot
> of cruft that would be better left out.
>
> Anyway, i'll re-sent a few messages with inline signatures and keep
> sending with inline signatures, until one of the list admins does something
> .
>
> - --
> O< ascii ribbon - stop html email! - www.asciiribbon.org
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJXGl21AAoJEOs4Jb6SI2CwJsUH/2GOo1aCvERaEHgV852zIIUI
> RUE3FTopXspu6cJUK1Bnk/Aj1ZtDB4ZqRWXrTa4DfK5KTVlIJ0E9XVH4NvCslTcW
> pWOQfTmc9LPiaNvtYhQ+FAY0N2f9vBWzJ6kg81O61ZHnXNi0pTkh+LG8CtUcDIxl
> Dt4P5UOfpEp498Fp74Xzyd2jvk0cwzQNFTyL6XC+ZfHwJmGaFgpD6p8FlJBBpErW
> H6+WvQhahKRWOQ0If5321RUv/Nbzoog/76wM78SG3j2hzXDF/vRcFkyon9kXTpII
> xDGC2up6LVjVweZnP7E2fdcKVcqoyWRLU9chOrnMAOHdL22zW+RzcSBD9o2/XB4=
> =ijc4
> -END PGP SIGNATURE-
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 also
obligated to include the license text in your distribution.  You are doing
neither of these, and are in violation of the extremely liberal MIT-style
license.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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
> > 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 dependency, to make a rule for that, and then go ahead
> > with the normal rules.  Something like this:
> >
> > $(directoryname):
> > $(MKDIR_P) $@
> >
> > %.def: $(directoryname)
> >
> > %.def: %.def.in
> > ...as before
> >
> >
> > You could probably even combine those two rules:
> >
> > %def: %.def.in $(directoryname)
> > ...as before
> >
>
> As in literally "directoryname"? I tried $(@D), but end up with "/" as
> directory name.

Hehe, no, whatever represents the directory they are being installed into.
It is probably $(libdir), but again I'd have to look at the code. When I
browse the file in the online repository viewer, I get an unknown error
from sf.
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 dependency, to make a rule for that, and then go ahead
with the normal rules.  Something like this:

$(directoryname):
$(MKDIR_P) $@

%.def: $(directoryname)

%.def: %.def.in
...as before


You could probably even combine those two rules:

%def: %.def.in $(directoryname)
...as before

since the rule uses $^ to grab the first prerequisite, which should be
the def.in file.

Also, presumably the directory name here is already handled by
automake (I'm assuming it's just $(libdir)).  Which would simplify
things even further.  But, I can't get to the code right now to see or
prove that.  In any case, this is a much cleaner approach.




On Sat, Nov 14, 2015 at 11:22 PM, JonY  wrote:
> Patch OK?
>
> diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
> index a137750..48bdfd3 100644
> --- a/mingw-w64-crt/Makefile.am
> +++ b/mingw-w64-crt/Makefile.am
> @@ -1416,7 +1416,7 @@ endif
>  # ##
>
>  %.def: %.def.in
> -   $(CPP) -x c $< -Wp,-w -I$(top_srcdir)/def-include | $(SED) 's/^#/;/' 
> >$@
> +   $(MKDIR_P) $(@D) && $(CPP) -x c $< -Wp,-w -I$(top_srcdir)/def-include 
> | $(SED) 's/^#/;/' > $@
>
>  # Don't compile these, but install as is:
>  #
>
> --
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

LGTM, thanks for taking the time to do it well!
On Nov 11, 2015 2:24 AM, "Martell Malone" <martellmal...@gmail.com> wrote:

> You changed from --enable to --with, but left the conditional name as
>> ENABLE_GENLIB.  Change to WITH_GENLIB.
>> Makefile.am:
>> Don't test WITH_GENLIB twice.  Test it once and set all the variables
>> there.  Move:
>> +  AM_DLLTOOLFLAGS=-o $@
>> and its twin into the respective conditional paths.  Move:
>>  if DELAY_IMPORT_LIBS
>>AM_DLLTOOLFLAGS += --output-delaylib $@.delayimp.a
>>  endif
>> 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, 2015 at 11:47 PM, NightStrike <nightstr...@gmail.com>
> wrote:
>
>> configure.ac:
>>
>> You missed AS_VAR_SET:
>> [GENLIB=$with_genlib]
>> [AS_VAR_SET([GENLIB], [$with_genlib])]
>>
>> This handles quoting very portably, and is more usable wrt indirection
>> for when someone copies this code elsewhere to do a similar change.
>>
>> You also forgot to remove AC_SUBST, which is redundant with AC_CHECK_TOOL.
>>
>> You changed from --enable to --with, but left the conditional name as
>> ENABLE_GENLIB.  Change to WITH_GENLIB.
>>
>> Makefile.am:
>> Don't test WITH_GENLIB twice.  Test it once and set all the variables
>> there.  Move:
>>
>> +  AM_DLLTOOLFLAGS=-o $@
>>
>> and its twin into the respective conditional paths.  Move:
>>
>>  if DELAY_IMPORT_LIBS
>>AM_DLLTOOLFLAGS += --output-delaylib $@.delayimp.a
>>  endif
>>
>> after the WITH_GENLIB conditional.
>>
>>
>> Send patches as .txt, as google screws up the encoding / mime type.
>>
>>
>> On Tue, Nov 10, 2015 at 2:08 AM, Martell Malone <martellmal...@gmail.com>
>> wrote:
>> > 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 elsewhere in
>> >> the build system.  This means that you don't call AC_CHECK_TOOL until
>> >> after the with- processing, and only if with_genlib is not set to no.
>> >> AS_CASE is appropriate 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 should just have
>> to
>> >> > change to AC_ARG_WITH and from enable_ to with_.
>> >> >
>> >> > On Mon, Nov 9, 2015 at 12:46 AM, Martell Malone
>> >> > <martellmal...@gmail.com> wrote:
>> >> >> Here is the final patch after running autoreconf -fi and only
>> applying
>> >> >> relevant changes.
>> >> >> I would like to apply this if there are no objections ?
>> >> >>
>> >> >> Kind Regards
>> >> >> Martell
>> >> >>
>> >> >> On Fri, Nov 6, 2015 at 3:39 PM, Martell Malone
>> >> >> <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
>> >> >>>>
>> >> >>>> On Wed, Nov 4, 2015 at 1:56 PM, Martell Malone
>> >> >>>> <martellmal...@gmail.com>
>> >> >>>> wrote:
>> >> >>>> > Be warned I am no autotools expert.
>> >> >>>> > A review would be very helpful. :)
>> >> >>>> >
>> >> >>>> > CC+ alexey for help on that :)
>> >> >>>> >
>> >> >>>> >
>> >> >>>> >
>> >&g

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

[NightStrike]

configure.ac:

You missed AS_VAR_SET:
[GENLIB=$with_genlib]
[AS_VAR_SET([GENLIB], [$with_genlib])]

This handles quoting very portably, and is more usable wrt indirection
for when someone copies this code elsewhere to do a similar change.

You also forgot to remove AC_SUBST, which is redundant with AC_CHECK_TOOL.

You changed from --enable to --with, but left the conditional name as
ENABLE_GENLIB.  Change to WITH_GENLIB.

Makefile.am:
Don't test WITH_GENLIB twice.  Test it once and set all the variables
there.  Move:

+  AM_DLLTOOLFLAGS=-o $@

and its twin into the respective conditional paths.  Move:

 if DELAY_IMPORT_LIBS
   AM_DLLTOOLFLAGS += --output-delaylib $@.delayimp.a
 endif

after the WITH_GENLIB conditional.


Send patches as .txt, as google screws up the encoding / mime type.


On Tue, Nov 10, 2015 at 2:08 AM, Martell Malone <martellmal...@gmail.com> wrote:
> 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 elsewhere in
>> the build system.  This means that you don't call AC_CHECK_TOOL until
>> after the with- processing, and only if with_genlib is not set to no.
>> AS_CASE is appropriate 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 should just have to
>> > change to AC_ARG_WITH and from enable_ to with_.
>> >
>> > On Mon, Nov 9, 2015 at 12:46 AM, Martell Malone
>> > <martellmal...@gmail.com> wrote:
>> >> Here is the final patch after running autoreconf -fi and only applying
>> >> relevant changes.
>> >> I would like to apply this if there are no objections ?
>> >>
>> >> Kind Regards
>> >> Martell
>> >>
>> >> On Fri, Nov 6, 2015 at 3:39 PM, Martell Malone
>> >> <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
>> >>>>
>> >>>> On Wed, Nov 4, 2015 at 1:56 PM, Martell Malone
>> >>>> <martellmal...@gmail.com>
>> >>>> wrote:
>> >>>> > Be warned I am no autotools expert.
>> >>>> > A review would be very helpful. :)
>> >>>> >
>> >>>> > CC+ alexey for help on that :)
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> >
>> >>>> > ___
>> >>>> > Mingw-w64-public mailing list
>> >>>> > Mingw-w64-public@lists.sourceforge.net
>> >>>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>> >>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> ___
>> >>>> Mingw-w64-public mailing list
>> >>>> Mingw-w64-public@lists.sourceforge.net
>> >>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Presto, an open source distributed SQL query engine for big data,
>> >> initially
>> >> developed by Facebook, enables you to easily query your data on Hadoop
>> >> in a
>> >> more interactive manner. Teradata is also now providing full enterprise
>> >> support for Presto. Download a free open source copy now.
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
>> >> _

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

[NightStrike]

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
change to AC_ARG_WITH and from enable_ to with_.

On Mon, Nov 9, 2015 at 12:46 AM, Martell Malone <martellmal...@gmail.com> wrote:
> Here is the final patch after running autoreconf -fi and only applying
> relevant changes.
> I would like to apply this if there are no objections ?
>
> Kind Regards
> Martell
>
> On Fri, Nov 6, 2015 at 3:39 PM, Martell Malone <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
>>>
>>> On Wed, Nov 4, 2015 at 1:56 PM, Martell Malone <martellmal...@gmail.com>
>>> wrote:
>>> > Be warned I am no autotools expert.
>>> > A review would be very helpful. :)
>>> >
>>> > CC+ alexey for help on that :)
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > ___
>>> > Mingw-w64-public mailing list
>>> > Mingw-w64-public@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>> >
>>>
>>>
>>> --
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>>
>
>
> --
> Presto, an open source distributed SQL query engine for big data, initially
> developed by Facebook, enables you to easily query your data on Hadoop in a
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open source copy now.
> http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

...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 don't call AC_CHECK_TOOL until
after the with- processing, and only if with_genlib is not set to no.
AS_CASE is appropriate 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 should just have to
> change to AC_ARG_WITH and from enable_ to with_.
>
> On Mon, Nov 9, 2015 at 12:46 AM, Martell Malone <martellmal...@gmail.com> 
> wrote:
>> Here is the final patch after running autoreconf -fi and only applying
>> relevant changes.
>> I would like to apply this if there are no objections ?
>>
>> Kind Regards
>> Martell
>>
>> On Fri, Nov 6, 2015 at 3:39 PM, Martell Malone <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
>>>>
>>>> On Wed, Nov 4, 2015 at 1:56 PM, Martell Malone <martellmal...@gmail.com>
>>>> wrote:
>>>> > Be warned I am no autotools expert.
>>>> > A review would be very helpful. :)
>>>> >
>>>> > CC+ alexey for help on that :)
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > ___
>>>> > Mingw-w64-public mailing list
>>>> > Mingw-w64-public@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>> >
>>>>
>>>>
>>>> --
>>>> ___
>>>> Mingw-w64-public mailing list
>>>> Mingw-w64-public@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>>>
>>
>>
>> --
>> Presto, an open source distributed SQL query engine for big data, initially
>> developed by Facebook, enables you to easily query your data on Hadoop in a
>> more interactive manner. Teradata is also now providing full enterprise
>> support for Presto. Download a free open source copy now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>

--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 :)
>
>
> --
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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/MINGW-packages/tree/master/mingw-w64-gcc
>
> Thanks for the pointer. It’s sad that mingw has regressed, when GCC trunk 
> used to build perfectly with no patch and configure options.
>
> I’m trying now to force the build triplet to x86_64-w64-mingw32, rather than 
> the detected value (x86_64-pc-mingw64).
> So I have another question: which is the expected/canonical build triplet?

Was that a typo, or did it really detect -mingw64 instead of mingw32?

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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>:
>> How does visual studio support AVX?
>>
>> On Sep 12, 2015 6:40 AM, "Kai Tietz" <ktiet...@googlemail.com> 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
>>> itself.  It is a consequence of the SEH-information required by the
>>> x64 ABI (see here as reference either msdn, or ibm's IA64
>>> exception-specification).  Sadly there is no way to express by it any
>>> kind of stack-alignment.  So it is impossible to write code, which
>>> brings AVX to proper stack-location within x64-ABI.  The ABI itself
>>> makes sure that on function-entry stack has a 16-byte alignment, so
>>> 64-bit sse-registers can be stored aligned.  Another weakness in this
>>> prologue-description used by x64 is that register with more then
>>> 64-bit width can't be expressed.   This is a reason why the upper 8
>>> bytes of a ymm-register are treated as volatile.
>>>
>>> Only way to work-a-round that is to do manual alignment of function,
>>> and making sure that you won't try to unwind over such a function.
>>> The mentioned prologue/epilogue script on stack-overflow article seems
>>> to do exactly this.
>>>
>>> Regards,
>>> Kai Tietz
>>>
>>> 2015-09-11 23:53 GMT+02:00 Gabe Al-Ghalith <algh0...@umn.edu>:
>>> > Please see:
>>> >
>>> > http://stackoverflow.com/questions/5983389/how-to-align-stack-at-32-byte-boundary-in-gcc
>>> >
>>> > and
>>> >
>>> > http://stackoverflow.com/questions/32213338/gcc-vector-extensions-avx2-builtin-shuffle-crashes-when-m64-is-used
>>> >
>>> > Basically, AVX (since 2011) and now Skylake Xeon (with AVX-512) will be
>>> > completely unusable on Windows. Please fix this!
>>> >
>>> > Thanks,
>>> > Gabe
>>> >
>>> >
>>> > --
>>> >
>>> > ___
>>> > Mingw-w64-public mailing list
>>> > Mingw-w64-public@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>> >
>>>
>>>
>>> --
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>>
>> --
>> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
>> Get real-time metrics from all of your servers, apps and tools
>> in one place.
>> SourceForge users - Click here to start your Free Trial of Datadog now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
> --
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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
> itself.  It is a consequence of the SEH-information required by the
> x64 ABI (see here as reference either msdn, or ibm's IA64
> exception-specification).  Sadly there is no way to express by it any
> kind of stack-alignment.  So it is impossible to write code, which
> brings AVX to proper stack-location within x64-ABI.  The ABI itself
> makes sure that on function-entry stack has a 16-byte alignment, so
> 64-bit sse-registers can be stored aligned.  Another weakness in this
> prologue-description used by x64 is that register with more then
> 64-bit width can't be expressed.   This is a reason why the upper 8
> bytes of a ymm-register are treated as volatile.
>
> Only way to work-a-round that is to do manual alignment of function,
> and making sure that you won't try to unwind over such a function.
> The mentioned prologue/epilogue script on stack-overflow article seems
> to do exactly this.
>
> Regards,
> Kai Tietz
>
> 2015-09-11 23:53 GMT+02:00 Gabe Al-Ghalith :
> > Please see:
> >
> http://stackoverflow.com/questions/5983389/how-to-align-stack-at-32-byte-boundary-in-gcc
> >
> > and
> >
> http://stackoverflow.com/questions/32213338/gcc-vector-extensions-avx2-builtin-shuffle-crashes-when-m64-is-used
> >
> > Basically, AVX (since 2011) and now Skylake Xeon (with AVX-512) will be
> > completely unusable on Windows. Please fix this!
> >
> > Thanks,
> > Gabe
> >
> >
> --
> >
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >
>
>
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

I did respond, and your patch brings things steps away from usable,
not closer. Check your email, I explained how to do what you are
trying to do. Your patch is a really bad patch.  Sorry.

On Thu, May 28, 2015 at 9:53 AM, Alon Bar-Lev alon.bar...@gmail.com wrote:
 Quoting my-self:


 Hi,

 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.

 For these who are, it bring us one step closer to something that is usable.

 Thanks,
 Alon


 On 4 May 2015 at 22:47, Alon Bar-Lev alon.bar...@gmail.com wrote:
 this somewhat reduces the error checking, but makes code and usage nicer.

 Signed-off-by: Alon Bar-Lev alon.bar...@gmail.com
 ---
  configure.ac | 55 ---
  1 file changed, 12 insertions(+), 43 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 468d1b1..1b59821 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -56,32 +56,12 @@ AC_ARG_WITH([libraries],
  [Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh, 
 winpthreads, or all])],
[],
[with_libraries=no])
 -AS_CASE([$with_libraries],
 -  [yes|all],[
 -with_libraries=libmangle,pseh,winpthreads
 -with_libraries_winpthreads=yes
 -with_libraries_mangle=yes
 -with_libraries_pseh=yes],
 -  [libmangle],[
 -with_libraries=libmangle
 -with_libraries_winpthreads=no
 -with_libraries_mangle=yes
 -with_libraries_pseh=no],
 -  [pseh],[
 -with_libraries=pseh
 -with_libraries_winpthreads=no
 -with_libraries_mangle=no
 -with_libraries_pseh=yes],
 -  [winpthreads],[
 -with_libraries=winpthreads
 -with_libraries_winpthreads=yes
 -with_libraries_mangle=no
 -with_libraries_pseh=no],
 -  [no],[
 -with_libraries_winpthreads=no
 -with_libraries_mangle=no
 -with_libraries_pseh=no],
 -  [MW64_OPTION_ERROR([with-libraries])])
 +for l in winpthreads mangle pseh; do
 +  res=`echo ${with_libraries} | grep $l  /dev/null  echo yes || echo 
 no`
 +  AS_CASE([$with_libraries],
 +[all|yes],[res=yes])
 +AS_VAR_COPY([with_libraries_$l], [res])
 +done
  AM_CONDITIONAL([LIBRARIES_MANGLE],[test x$with_libraries_mangle = xyes])
  AM_CONDITIONAL([LIBRARIES_PSEH],[test x$with_libraries_pseh = xyes])
  AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test x$with_libraries_winpthreads 
 = xyes])
 @@ -96,23 +76,12 @@ AC_ARG_WITH([tools],
  [Build the extra mingw-w64 tools, where ARG is one of gendef, genidl, 
 or all])],
[],
[with_tools=no])
 -AS_CASE([$with_tools],
 -  [yes|all],[
 -with_tools=gendef,genidl
 -with_tools_gendef=yes
 -with_tools_genidl=yes],
 -  [gendef],[
 -with_tools=gendef
 -with_tools_gendef=yes
 -with_tools_genidl=no],
 -  [genidl],[
 -with_tools=genidl
 -with_tools_gendef=no
 -with_tools_genidl=yes],
 -  [no],[
 -with_tools_gendef=no
 -with_tools_genidl=no],
 -  [MW64_OPTION_ERROR([with-tools])])
 +for t in gendef genidl; do
 +  res=`echo ${with_tools} | grep $t  /dev/null  echo yes || echo no`
 +  AS_CASE([$with_tools],
 +[all|yes],[res=yes])
 +AS_VAR_COPY([with_tools_$t], [res])
 +done
  AM_CONDITIONAL([TOOLS_GENDEF],[test x$with_tools_gendef = xyes])
  AM_CONDITIONAL([TOOLS_GENIDL],[test x$with_tools_genidl = xyes])
  AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
 --
 2.3.6


 --
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 tool chain targeting windows

 2.As the compile/link speed is so slow under windows,I hope to speed it
up.Can I use the cross compiler (e.g. target nonwin) to compiler/link
source code to nonwin target file format(e.g. elf),then have a convert tool
converted to windows pe format.It is best that I can do that all under
windows.

How slow is slow?

 Is that possible?Is that worth to do?

You'll get the best compiling speeds by cross compiling from linux to
windows

 Great thanks.







--
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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
from before the git switch that I never committed in time, and I won't
be using git anytime soon, so it's good that someone else is doing it.
But, doing it poorly is worse than not at all.

On Wed, May 6, 2015 at 6:25 AM, Alon Bar-Lev alon.bar...@gmail.com 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

This is a very bad idea.  You are never allowed to modify the CPPFLAGS
variable.  That is a user only variable, not for use by the package.

 3. disable sysroot for crt so search path contain only local headers

This makes no sense.  Just change the sysroot that you are passing in.


 Signed-off-by: Alon Bar-Lev alon.bar...@gmail.com
 ---
  Makefile.am |  2 +-
  configure.ac| 10 --
  mingw-w64-crt/configure.ac  |  5 +++--
  mingw-w64-headers-local/Makefile.am |  9 +
  4 files changed, 21 insertions(+), 5 deletions(-)
  create mode 100644 mingw-w64-headers-local/Makefile.am

 diff --git a/Makefile.am b/Makefile.am
 index 26a7606..0cf559c 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -3,7 +3,7 @@ if HEADER
  endif

  if CRT
 -  MAYBE_CRT = mingw-w64-crt
 +  MAYBE_CRT = mingw-w64-headers-local mingw-w64-crt
  endif

  if LIBRARIES_MANGLE
 diff --git a/configure.ac b/configure.ac
 index 4bb3926..e0f7685 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -44,7 +44,13 @@ AC_ARG_WITH([crt],
[],
[with_crt=yes])
  AS_CASE([$with_crt],
 -  [yes],[AC_CONFIG_SUBDIRS([mingw-w64-crt])],
 +  [yes],[
 +AC_CONFIG_SUBDIRS([mingw-w64-crt])
 +CPPFLAGS=-I\$(top_builddir)/../mingw-w64-headers-local/headers/include 
 ${CPPFLAGS}
 +export CPPFLAGS # so will effect subpackages
 +SYSROOT_DISABLE=yes
 +export SYSROOT_DISABLE # so will effect crt
 +  ],

You are breaking formatting conventions established in all of the
other files.  You don't need two lines to set and export a variable.
You should not be writing this raw shell code anyway, as autoconf
gives you facilities to both set and propagate variables in a
portable, maintainable way.

[no],[],
[MW64_OPTION_ERROR([with-crt])])
  AM_CONDITIONAL([CRT],[test x$with_crt = xyes])
 @@ -108,6 +114,6 @@ 
 AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
  AM_COND_IF([TOOLS_GENIDL],[AC_CONFIG_SUBDIRS([mingw-w64-tools/genidl])])
  AC_MSG_RESULT([$with_tools])

 -AC_CONFIG_FILES([Makefile])
 +AC_CONFIG_FILES([Makefile mingw-w64-headers-local/Makefile])
  AC_OUTPUT

 diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
 index bcf7d0c..387380f 100644
 --- a/mingw-w64-crt/configure.ac
 +++ b/mingw-w64-crt/configure.ac
 @@ -18,7 +18,8 @@ AC_ARG_WITH([sysroot],
[AS_HELP_STRING([--with-sysroot=DIR],
  [Search for headers within DIR/include (default: prefix)])],
[],
 -  [AS_VAR_SET([with_sysroot],[yes])])
 +  [AS_VAR_IF([SYSROOT_DISABLE], [yes],
 +[AS_VAR_SET([with_sysroot],[no]], [AS_VAR_SET([with_sysroot],[yes])]))])

Generally speaking, convention is to use AS_CASE whenever possible.
The resulting shell code is faster and more portable.  It also is
easier to maintain, as the expressiveness is more powerful without
being complex.

That said, the idea behind disabling the sysroot search just to
provide your own search path that does the same thing seems misguided.

  AS_CASE([$with_sysroot],
[no],[],
[yes],[AS_VAR_SET([with_sysroot],[$prefix])],
 @@ -252,7 +253,7 @@ AC_MSG_RESULT([$enable_tests_unicode])
  #AC_FUNC_VPRINTF
  #AC_CHECK_FUNCS([alarm atexit btowc fesetround floor ftruncate gettimeofday 
 isascii localeconv mbrlen memmove memset pow rint setlocale sqrt strcasecmp 
 strchr strncasecmp strtoull strtoumax])

 -AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the 
 mingw-w64 header set and the build/host option are set properly.])])
 +AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_WARN([Please check if the 
 mingw-w64 header set and the build/host option are set properly.])])

Why are you changing this to a warn instead of error?

  #Warnings and errors, default level is 3
  AC_MSG_CHECKING([for warning levels])
 diff --git a/mingw-w64-headers-local/Makefile.am 
 b/mingw-w64-headers-local/Makefile.am
 new file mode 100644
 index 000..9047e8b
 --- /dev/null
 +++ b/mingw-w64-headers-local/Makefile.am
 @@ -0,0 +1,9 @@
 +all-local: clean-local
 +   $(MAKE) \
 +   -C $(top_builddir)/mingw-w64-headers \
 +   prefix=$(abs_builddir)/headers \
 +   includedir=$(abs_builddir)/headers/include \
 +   

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

[NightStrike]

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 quite work as it is supposed to, building everything in one
 shot, since the CRT depend on an already installed header set before it
 can even compile. Likewise for the libraries.

 Kai? Ozkan? LRN? Any thoughts?

You are correct that it doesn't build everything in one shot, but it
does in two.  And it builds almost everything in one.  Corinna used
this extensively while working on the old crt split that we put in to
accomodate cygwin needs.  Documenting that is better than removing.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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:

https://sourceware.org/binutils/docs/binutils/windres.html
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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) Jon, you had asked me to setup a mailing list for svn commits.  I
  did so.  Then SF added their own thing that just sends the commit
  message without the patch in the body.  So now we have both.  What is
  your plan with doing that for git?  Are you going to still email
  messages to a list?  Are you going to do it per commit, or per merge?
  Binutils recently tackled this same question, and they settled on 1
  email per commit.  Also, would you only want emails on a certain
  branch?
 

 Per commit please, all branches.

Just to be clear here, I was pointing out the open issue, not
volunteering to do it.  I don't have a clue how to make git do that.

  2) Seeing as how it just came up on the mingw list, how does
  authenticity verification of changes happen when someone wants to
  merge in a big change?  On said list, people made the claim that this
  project doesn't check that commits are legally safe.  Under svn, every
  change gets checked by someone before it is committed.  What will be
  the new procedure, if a person has a giant blob to merge in?
  Admittedly, the problem is still there in svn (like that time you
  merged in the vista headers... lol :) but it's more common under git,
  I think.  Consider putting some thought into how you will accept large
  changes from a was this copied from proprietary sources? standpoint.
 

 It is the same situation under SVN,

Yes, I explicitly pointed that out :)  The difference is in the likelihood.

 any developer with write access can
 simply push their changes since, by definition they do actually have
 write access, although sending for review highly recommended. Git does
 open an avenue to pull style reviews, so even the authors without
 write access have the chance to publicly host their code (eg github)
 before it is pulled into mingw-w64. The vista headers was more of a
 miscommunication, I really thought you gave the green light to commit.

 It is also possible to have users changes on a branch on the SF
 repository and have someone merge them in the master branch.
 For instance at work we have branches named
 users/${user}/${branch_name}, i.e. users/adrien/break-everything.
 It was possible to finetune the rights to such branches and to the
 master branch independently. While this was enforced by the software,
 I'm confident it could also be a process enforced through the ancestral
 method of hitting with a baseball bat people who do things wrong (in the
 event SF does not allow restriction through software).

 I'm happy with restricting the rights to the main branch because there
 is a strong guarantee the commits have been reviewed.

This idea of Adrien's is a good one.  It is common in many projects,
and usually works well.  However, am I understanding it correctly this
workflow?

A) Alice has a change, works in a branch, finishes.
B) Alice posts the change for reviewing somehow (patch to ML, link to
git repo, etc)
C) Someone with expertise approves
D1) Someone with super rights does a git pull into master
D2) Alice does a git push into master

D1 or D2?

If it's D1, you get the security, but that's going to get old real
fast for the few people allowed to do a pull.  D2 opens the door for
irrevocably butchering the whole repo (As I said, I've done this --
it's not hard.)  It also means that everyone is going to be merging
and resolving conflicts differently, based on their own style.  This
is probably the worse of two evils.

If you look at Linux, it uses D1.  There are people who pull changes
into modules, and Linus pulls changes from them into the Real Deal.
This is very different than working in svn, where after a green light
on the ML, Alice would just svn ci.

Actually, there are parallels to svn.  In svn, Alice should do:
svn copy ^/trunk ^/branches/Alice // Create branch
...work in branch...
svn merge ^trunk // Keep branch up to date
svn co ^trunk // Checkout trunk to merge back
svn merge ^/branches/Alice --reintegrate (or not reintegrate for cherry picking)
svn ci

Instead, what usually happens is:
svn co ^/trunk
svn ci

The nature of my August 2011 email was basically this -- we currently
as a project do not branch and merge correctly, or often at all.  Svn
has superb branch/merge capabilities, but they just aren't used.  Now,
what that means is that if you change the VCS to git, you have to
REALLY spell out how to change that workflow, or else you'll be stuck
in an even worse spot.  That means writing down in the wiki a set of
procedures that all developers have to follow:

0) This list is just off the top of my head, surely not exhaustive
1) how you expect changes to propagate
2) who is in charge of what branch
3) how and when

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

[NightStrike]

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)
misinformation and 2) negative treatment toward a user with a
different opinion.  I'll address a little of (1) down below.  For
(2)... Jon, why so angry?  If you have good technical reasons for
proposing a switch to git, you should be able to present them
cogently, ideally from the standpoint of We need to solve problem X;
here's my solution., and they should easily stand on their own merit.
 Users are allowed to be dicks.. they're users.  Be nice in return.
Kai taught me that a long time ago.  Some German idiom about not
plucking chickens before they hatch or something  I dunno.

On Wed, Apr 30, 2014 at 2:05 PM, JonY jo...@users.sourceforge.net wrote:
 On 4/30/2014 21:34, Rodny Spillig wrote:

 Because it was a pain to track down patches applied to other branches
 and reapply it again and again, cherry-pick is god sent. Not to mention
 merging is quick and simple. It is also far far easier to do a long term
 private branch in git than in SVN, not to mention, multi-part commit
 patches are nice.

 SVN does all of that easily.  Are you sure you aren't just using it wrong?  
 The notion that it does not branch and merge is very outdated.  There is 
 even a whole section in the manual called Cherry Picking.

 Does SVN allow you to manage a local-only branch that allow merging from
 multiple remotes?

 As far as long term branches, how is svn merge ^/trunk any different than 
 git pull ?


 Will SVN allow change tracking of said branch if it is never committed
 to the server?

The big problem here that git might actually fix is that nobody ever
used svn correctly, despite my requests.  I posted a very long email
to the developer list back in 2011 that basically said don't manually
patch files, use svn merge before making edits.  Search the list for
subject Proper merging of patches, 8/7/11.  I was aggressively shot
down by both Ozkan and Kai, who vehemently defended the notion that we
should never use the merge capabilities of the version control
software.  That's the primary reason why patches between branches are
impossible to tie together.  Fixing this would be great.

If switching to git makes people finally keep accurate merge metadata,
then that is a pretty good thing.  But to be clear, the current
difficulty in tracking down patches and applying them elsewhere is a
facet of how we chose to misuse svn, not the tool itself.  We use svn
where I work, and we branch and merge all day long.  It's wonderfully
easy to do.  It does require a net connection, but for our purposes,
that's fine.  Besides, I'd rather push my work to a server, given how
many laptops I broke this past year :)

 How will you handle all the various things that you currently distribute?
 You have a lot of stuff in your repository, and it all works nicely because
 of how svn treats each directory as essentially a separate repo.  What are
 you going to do about the branches, tags, and experimentals?


 Already mentioned in the original email.

 Not really.  The entire workflow changes drastically, and you've not 
 indicated at all how users should deal with that.


 I have already mentioned branches and tags are migrated, they're all
 there. If you haven't already noticed, git-svn migration preserves
 history fine. Experimentals are outdated and unused and has not seen any
 changes for a long time, and unlikely to see any significant changes soon.

I was about to change a few things in experimental, actually, because
I got a nagging email that buildbot can't handle the binutils switch
from git to cvs.  Although I question whether anyone actually needs
buildbot anymore.  This change will equally break buildbot, so I may
just shut it down.  I don't really maintain it, haven't seen Mook log
in in a while, and I'm not really part of this project anymore (or
haven't been in a long time, and probably haven't been missed).

Other than that, the buildroot makefile is in there, which though
being out of date is still referenced in a lot of places.  And it's
used by buildbot.  It should likewise be updated or removed, pending
what happens to buildbot.  I'll send a separate email for that.

 We chose git because it is far more familiar to the bulk of our
 contributors, namely the ReactOS and Wine developers. Some contributors
 are already using their own git band-aid over SVN. None of our
 developers have even mentioned Mercurial over the years. Bazaar is out
 of the question because SF doesn't have that option.

ReactOS uses SVN, not git.  They even have svn posting to their IRC,
like we used to have with CIA.  Maybe they use both?  This page says
svn, tho:
http://www.reactos.org/development/source-control

I looked back through a month or so of IRC 

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

[NightStrike]

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 that it move to a sorted, single-filename-per-line Makefile
 style, which will make additions/deletions/changes very easy to understand,
 and I volunteer to carry out the change if it is agreed upon.

 Comments, flames, or questions?

I have suggested this multiple times in IRC over the years, and it's
always been denied.  Usually, the reasoning is the effect on vertical
real estate.  Some people find it easier to not have to scroll
continuously to see everything they want to see.  And in truth, the
list of import libs is HUGE.  The current source listings for the
libraries support this.

In terms of making things look better, that's a bike shed that never
gets painted.  One man's blue is another's green.

I don't really buy the version control argument, either.  There's only
a few files on a line at most.  I really don't think this is very,
very hard:

-foo.c  bar.c   baz.c
+foo.c  baz.c

I mean.. honestly *two* very's ? :P

At any rate, if enough people want it, then I'm not going to stand in
your way.  But I'd like to see more than just a little support for
what is otherwise a whim of the week.  Otherwise, next week, three
more people will come along asking for it to be yellow.

I will say that one thing in particular that I would definitely want
to do now that automake 1.14 is out is to make use of the feature I've
been begging for since we started -- that is, the ability to have
subdirectory makefiles that can reference a parent directory
(%reldir%).  This would allow putting for instance all of the import
libs in lib/Makefile.am without requiring the evils of recursive make
nor requiring ../ in every file name.  Of course, people need to buy
into that, too.  Before %reldir% came out, when I floated that idea
around, I got the same kind of negative response.  Ah, well.  Such is
the fate of progress :)

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] OpenGL headers

[NightStrike]

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 from [1].
 Specifically - GL/glext.h


 Pardon my french, but why should mingw-w64 supply them?

 Good question.

 A) Because MinGW.org supplies them
 B) Because MinGW-W64 supplies other GL headers already. Those are not
 sufficient for all uses, however.
 C) Because MinGW-W64 supplies a DirectX SDK. Why not OpenGL then?


 Committed to repository at rev. 5925

 Thanks,
 Kai

 Notice that you now need to maintain them because those headers are
 constantly updated by Khronos.

We have the same problem elsewhere (wine/dx), but in that case, we
have people (Jacek) who regularly keeps us in sync.

LRN, given Ozkan's very valid point, would you be able to keep us in
sync with Khronos on some set schedule?

 This was discussed a very long time ago and it was decided that we
 need not or should not provide them because, for starters, M$ itself
 does not. I used to provide them headers only as part of my personal
 builds, but we never did that officially.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] OpenGL headers

[NightStrike]

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:43, Christer Solskogen wrote:
 On 01.07.2013 16:02, LRN wrote:

 mingw-w64 should supply GL headers from [1].
 Specifically - GL/glext.h


 Pardon my french, but why should mingw-w64 supply them?

 Good question.

 A) Because MinGW.org supplies them
 B) Because MinGW-W64 supplies other GL headers already. Those are not
 sufficient for all uses, however.
 C) Because MinGW-W64 supplies a DirectX SDK. Why not OpenGL then?


 Committed to repository at rev. 5925

 Thanks,
 Kai

 Notice that you now need to maintain them because those headers are
 constantly updated by Khronos.

 We have the same problem elsewhere (wine/dx), but in that case, we
 have people (Jacek) who regularly keeps us in sync.

 LRN, given Ozkan's very valid point, would you be able to keep us in
 sync with Khronos on some set schedule?

 I'll try.

Thanks!

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 lived through this nightmare already I have one word of
 advice; be cautious of your repository URL updates.  The old
 repositories still exist and are still accessible for now (possible
 cleanup later).  I would suggest someone go to the shell for the
 project and rename/remove the old directories containing the
 repositories.  It has bit /projects/mingw more than once.

Sorry, what does this mean?  I don't follow.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 strongly encourage you to use the plethora of toolchains in a multitude of
 configurations available at mingw-builds. Comparing download numbers they
 have a much higher visibility, and e.g. their adoption by the Qt Project
 speaks of their quality. They have succeeded in doing what I missed when I
 decided to start building GCC, so my effort spent in doing that is now
 wasted.

 That's sad. I was using your builds from time to time, too.

You used to distribute your own builds, too :)

 Perhaps you can document your build process in the project
 resources, e.g. place your scripts in the svn somewhere or
 something?

svn/experimental/buildsystem is a perfect place to upload scripts.



 I may dabble into getting Clang 3.3 to work on Windows, perhaps even with
 libc++, but I am not promising anything.

 I'll still linger around here though, don't worry.

 All the best,

 Ruben

 --
 O.S.

 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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.


Thanks for providing that service! It should be very useful for users.
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 Алексей,
 
  On Jun 11 21:10, Алексей Павлов wrote:
  MSYS includes the following changes to Cygwin to support using
  native Win32 programs: 1. Automatic path mangling of command line
  arguments and environment variables to Win32 form on the fly for
  Win32 applications inside bash.exe
 
  That's a bash change which does not affect the underlying Cygwin/MSYS
  DLL.
  You misinterpreted that.
 
  The mangling is done in msys-2.dll, it's done every time a process is
  spawned. The parent checks the dependencies of the child, and if child
  does NOT depend on msys-2.dll (that is, if child is not a MSYS
  application), the parent will spawn it with mangled environment (thus
  the child will not get POSIX paths in envvars, such as PATH) mangled
  and arguments
 
  This is default in Cygwin for a long time.  When Cygwin starts, a small
  number of variables is converted from Windows to POSIX style, namely
  PATH, HOME, LD_LIBRARY_PATH, TMPDIR, TMP, and TEMP.
 
  If a Cygwin process execve's a non-Cygwin process, the whole thing is
  done backwards.
 
  This is not done for any other variable, and in no direction, because
  trying to recognize other variable's content as path and then
converting
  it to the other style is pure speculation on the DLL's part.  The
result
  is broken as often as not.
 
  I can't say anything about variables (i can easily imagine cases where
not
  converting variables would break the build process, but i can't name a
  package that does need it - because i never tried to compile anything
  without that feature, and i don't remember it misfiring on me and
  converting something that shouldn't have been converted).
 
  However, the fact that command line arguments are not converted (at
least
  you didn't mention anything about converting arguments; i assume they
are
  left untouched; my googling also supports that assumption) means that
  command line arguments like these:
 
  -I/mingw/lib/glib-2.0/include
 
  /src/mingw-w64/mingw-w64-libraries/winpthreads/src/clock.c
 
  will not be converted, which makes it next to impossible to use W32
tools
  in conjunction with autotools (ok, the /src thing can be avoided by
  carefully using relative paths only, but i can't say how much things
will
  slip past that and bite you, if mangling is switched off).
 
  You are also incorrect in assuming that the probability of MSys
correctly
  guessing that something should be mangled is 0.5 (as often as not, as
you
  put it). In my experience, the probability of a correct guess goes up to
  0.9 and above. The logic is quite complex (see [1] for the list of rules
  MSYS1 uses; see MSYS2 source for the list of rules MSYS2 uses). There
ARE
  cases when you don't want MSys to mangle things, but it does anyway, and
  the result is unsatisfactory. In these cases buildsystem has to be
  patched.
 
  Mostly it's when something that looks like a path (such as a prefix, i.e
  /mingw) is used in a construction like -DSOMEPREFIX=\/mingw\. The
  problem is solved by using config.h instead of -D (since the contents of
  files are not mangled). The reverse is also true - sometimes
buildsystems
  will generate source files on the fly (usually - by processing .in files
  and substituting @VARIABLES@), and will insert absolute paths to files
into
  generated code, i.e. fopen (/src/libcdio/blah/blah/foobar.data, r)
  (usually it's for testcases that are not designed to be relocatable
  anyway). This can be fixed directly (using relative names explicitly),
or
  worked around by calling configure relatively (i.e. cd builddir ;
  ../srcdir/configure arguments - assuming that builddir and srcdir are
  siblings) when doing OOTSD builds (in which case all names will be
relative
  no matter what).
 
  There are also selected cases where something looks like a path, but
isn't
  one. One example that comes to mind is xmlcatalog.exe, which is given
  arguments like -//OASIS//ELEMENTS DocBook Information Pool V4.2//EN,
  which look like paths, but shouldn't be mangled. The solution is to use
  msys version of xmlcatalog (that fixes some other problems as well)
instead
  of mingw version.
 
  Same goes for git. As i mentioned earlier in this thread, one of the
things
  that msysGit devs did to their fork of MSYS1 was to slightly alter the
  mangling code to not to mangle some things (some kind of git refs, i
forgot
  the specifics). Again, this is fixed by using real msys-git that needs
no
  mangling.
 
  But most of the time things just work™
 
  [1] http://www.mingw.org/wiki/Posix_path_conversion
 
 To add a little bit to this discussion. I just did a native gcc
 x86_64-w64-mingw32 3-stage bootstrap using the MSYS2 version dated
10.06.. It
 

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

[NightStrike]

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 posting.  You have to configure
 and maneuver the cursor in the mail but it works just the same.  Sure
 the client may put the cursor at the top of the page but the editor
 allows you to maneuver within the text.  BTW, you shouldn't just do
 BOTTOM posting either, INLINE is what you want removing the unneeded
 quotes.

 --
 Earnie
 -- earnieboyd


--
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net

Earnie, keep this nonsense off of our lists. We aren't post format nazis
here at mingw-w64. We are very accepting and very open of individual user
situations. For instance, I am replying from a foreign country on a
blackberry using an old interface that doesn't allow me to modify the
message well. That's life.

Feel free to unsubscribe if you don't like our friendlier nature.
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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]: *** [testcases/tstmainc.log] Error 127
 make[3]: Leaving directory `/e/gnu/mingw64/svn/mingw-w64-crt'
 make[2]: *** [check-TESTS] Error 2
 make[2]: Leaving directory `/e/gnu/mingw64/svn/mingw-w64-crt'
 make[1]: *** [check-am] Error 2
 make[1]: Leaving directory `/e/gnu/mingw64/svn/mingw-w64-crt'
 make: *** [check] Error 2


 Maybe we should copy test-driver from winpthreads/build-aux/test-driver

Committed revision 5831.  Updated all the build-aux files.

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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:
 $ ./build --python-only=2.7.3 x32 # for building python-2.7.3, i686
 $ ./build --python-only=2.7.3 x32 x64 # for building python-2.7.3,
 i686  x86_64

 At the moment, the following Python version: 2.7.3, 2.7.4, 3.3.0

 Currently, this functional is in 'develop' branch of MinGW-builds Git
 repository:
 https://github.com/niXman/mingw-builds/tree/develop

Thanks!

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winpthreads testsuite

[NightStrike]

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 that those are tracked in SVN).


 OK, here is a better patch - split into parts, without generated
 files. Say think you to git-svn and its wonderful awesomeness!

We have two testsuite directories, test and tests.  I renamed
tests to tests-pthreads since it comes directly from them.  I
renamed test to tests and have begun integrating it with the
build.  Next step will be to integrate the other suite.

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 an admin to approve.  I just approved your
now, but you should really subscribe so that you see the replies:

https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

I'm manually CC'ing you on this message, but if you don't subscribe,
you won't get the replies to your actual question.

--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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:

   http://cygwin.com/ml/cygwin-developers/2013-04/msg00010.html

 The problem here is that the intrinsics are linked into libmingwex.a,
 but libmingwex.a doesn't exist in the w32api and thuis isn't available
 under Cygwin.

 Kai and I discussed this privatly on IRC and we came to the conclusion
 that the most generic solution is to include the intrinsics in
 libkernel32.a, rather than in libmingwex.a.  This allows to link against
 the intrinsics on both platforms, Mingw-w64 as well as Cygwin.

 It also matches the expectations of application programmers when reading
 MSDN.  Apart from the fact that the functions are implemented as
 compiler intrinsics, their documentation on MSDN claims their
 availability in kernel32.lib, see, for instance,
 http://msdn.microsoft.com/en-us/library/windows/desktop/ms683597%28v=vs.85%29.aspx,
 in the Requirements section.

 The below patch implements this.  It strips the intrinsic functions
 from the src_libmingwex variable and introduces a src_intrincs
 variable instead.  It also renames src_libmingwex32 and src_libmingwex64
 to src_intrincs32 and src_intrincs64.  Then it adds rules for building
 libkernel32.a for 32 and 64 bit targets, and includes the intrinsics
 functions to their sources.

 Is that ok to check in?

I have nothing to offer on the concept behind the patch.  However, I
do feel the need to point out that with this patch, dlltool will no
longer run to process the kernel32.def file when building
libkernel32.a.  There are two cases where we incorporate a def file
into a lib.  The easiest is when there are no other sources, and that
is handled by the general make rule, ie:

lib32/lib%.a: lib32/%.def
$(DTDEF32) $

There is a kludgier case where we have sources, too.  We do this by
overriding the AR step of building the library so that we can run
dlltool and then call AR as normal.  For instance, here we are doing
it for libksuser:

lib64_LIBRARIES += lib64/libksuser.a
lib64_libksuser_a_SOURCES = $(src_libksuser)
lib64_libksuser_a_CPPFLAGS=$(CPPFLAGS64) $(sysincludes)
lib64_libksuser_a_AR = $(DTLIB64)  $(AR) $(ARFLAGS)


Previously, libkernel32.a didn't have any sources, so it fell under
the first method.  You are now adding sources to it, and you correctly
took it out of the def list for the first rule, but in order to
incorporate the kernel32.def file, you need an accompanying AR line to
run dlltool on it.

I admit that the above situation isn't ideal, but the autotools don't
really actively support windows-isms like dlltool.  They said they
would review a patch if I wrote it, but I don't know perl yet :(


 -lib32_LIBRARIES = lib32/libshell32.a
 +lib32_LIBRARIES = lib32/libkernel32.a
 +lib32_libkernel32_a_SOURCES = $(src_intrincs) $(src_intrincs32)
 +lib32_libkernel32_a_CPPFLAGS=$(CPPFLAGS32) $(extra_include) $(AM_CPPFLAGS)

Stick it in here

 +lib64_LIBRARIES = lib64/libkernel32.a
 +lib64_libkernel32_a_SOURCES = $(src_intrincs) $(src_intrincs64)
 +lib64_libkernel32_a_CPPFLAGS=$(CPPFLAGS64) -D_SYSCRT=1 -DCRTDLL=1 
 $(extra_include) $(AM_CPPFLAGS)

And here



On a second note   the CPPFLAGS lines are different.  Why are
_SYSCRT and cRTDLL defined for the 64-bit case, but not the 32-bit
case?  And why not including sys_includes?  Do the intrinsics not
depend on mingw-w64-headers, only the internal crt headers?  Any
answer is ok to these last questions, as long as you have an answer :)

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 as in the following shell32.a rule for the
 same target to align to the surrounding style.

Ok.  I have no idea why the lib32 ordering is different than lib64.
Probably an oversight.

 On a second note   the CPPFLAGS lines are different.  Why are
 _SYSCRT and cRTDLL defined for the 64-bit case, but not the 32-bit
 case?  And why not including sys_includes?  Do the intrinsics not
 depend on mingw-w64-headers, only the internal crt headers?  Any
 answer is ok to these last questions, as long as you have an answer :)

 Uhm... well, the answer *I* have is this:  I fat-fingered my copy/paste.
 I *planned* to copy the CPPFLAGS from lib64_libmingwex_a_CPPFLAGS,
 but what I *did* was to copy the CPPFLAGS from lib64_libmingw32_a_CPPFLAGS,
 accidentally.  Sorry about that and thanks for catching.  This is fixed
 in the below updated patch.

Looks good, thanks!

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 right, the tools do not replicate themselves in anyway, nor
 create any call references to themselves. The tools being end products
 as opposed to linkable libraries provide an excellent use case for the
 GPLv3 license.

 gendef and genidl generate listings that are largely MSVC compatible,
 genpeimg modifies PE flags.

Doesn't gendef place restriction on the files it generates?

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 default (not
 sure that change applies to exception handling though).

 Also, the switch to SEH on x64 isn't mentioned on
 http://gcc.gnu.org/gcc-4.8/changes.html; should it?

Yes.  Would you mind sending a patch to the gcc lists?

--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 information from DWARF for backtraces.
  ^
 cc1: all warnings being treated as errors

 This, even though I explicitly passed --disable-werror to configure.

 Checking the readme of libbacktrace,
 https://github.com/mirrors/gcc/tree/master/libbacktrace
 it seems this should only be built for ELF targets.


 And it seems this is built because I enabled go as a language for GCC and
 libgo depends on it. The joys of trying to give more features...

IIUC, gcc's go compiler can't be used on windows.

--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 DEFINES+=MS_WIN64 -p win32-g++

 Regards

Have you got your stuff settled out yet?

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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=libmangle --with-tools=all
 --prefix=$(RUNTIME_STAGE)
 make
 make install

 If GCC or mingw-w64 introduce ABI-breaking changes (this happens often),
 I build a non-bootstrap GCC first in order to run this top-level
 mingw-w64 build before bootstrapping; otherwise I use the bootstrapped GCC.
 So no headers?  IIUC, it's only the headers package that is screwing up.

 The headers seem to get built along with all the other subtrees... ?

Curious... when configuring the crt, which headers is it checking for
_mingw_mac.h?  The soon-to-be-built ones, or the
already-installed-as-part-of-the-toolchain ones?  Similarly, which is
it compiling against?

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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, which headers is it checking for
 _mingw_mac.h?  The soon-to-be-built ones, or the
 already-installed-as-part-of-the-toolchain ones?  Similarly, which is
 it compiling against?

 I haven't ever dug into the mingw-w64 build system to be able to answer
 these questions -- it's always worked, so I haven't worried about it.

I have a hunch that it's working because you are building mingw-w64
with mingw-w64.  If you did it with, say, mingw.org, it'd probably
fail... which means, it's taking the files from the build compiler to
jimmy the tests.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 helpful and maybe the opinions have changed a bit.

 Sorry.. did I refuse it?  Can you link to the mailing list archive (I
 understand that the SF interface blows for that...)

No link?  I tried to find it and could not.

  For people building just the latest mingw64-headers and mingw64-crt,
  it's kind of surprising that mingw64-crt requires that the headers
  are already installed.  In theory, the right thing to do should be
  that mingw64-crt is build after mingw64-headers, and then prefer the
  just built in-tree headers over the already installed headers.

 I'm a little confused here.  What we require, ie, the only situation
 that we support, is when the version of the headers is the same
 version of the crt.  Ie, svn checkout revision.  Anything outside of
 that will probably work, of course, but nobody tests it.

 Sure, I'm not claiming anything else, nor am I trying to do anything
 else.  I want to build a full mingw tree, without having to have
 anything installed outside the source or build tree.

When you say full mingw tree, do you mean that you are building crt,
headers, and tools using the top level configure/make, as opposed to
building each thing you want independently?

 Now, in terms of the configure test that errors out in the case of not
 finding _mingw_mac.h, that is due to the fact that the headers are
 required to build the crt.  We don't care where they are, we just care
 that they exist.  If they don't, the crt build will be all fouled up.

 I'm puzzeled.  That has nothing to do with my patch.

Your patch changed when it errored out.

 The default, of course, is for the headers to exist in the sysroot
 that the crt is getting installed into.  This is a fairly common usage
 pattern, and modeled after the gcc build.  If they're somewhere else
 instead, you can just use --with-sysroot=some/wheres/else

 In fact, the help text for with-sysroot even says this:
  --with-sysroot=DIR   Search for headers within DIR/include

 So if you for whatever reason want to stage a build of
 mingw-w64-headers in /tmp/my/dir, you just build the crt with
 --with-sysroot=/tmp/my/dir

 Does that not work for you?

 Sorry, but I'm really confused about the unnecessary complexity.  I don't
 want to stage anything.  I would like to be able call

   configure --prefix=...
   make
   make install

Which configure are we talking about in all of this?  I thought you
were always asking about the crt configure, but I'm getting the
feeling that you're really asking about the top level configure.

 That's a pretty standard scenario.  But here's what happens: Try to
 build a full set of headers and libs for a Cygwin target:

   ${srcdir}/configure \
 --host=x86_64-w64-mingw32 \
 --prefix=/home/corinna/mingw \
 --enable-w32api

 As common as it looks, the build will fail:

   x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H \
 -I. \
 -I${srcdir}/mingw-w64-crt  \
 -m32 \
 -I/home/corinna/mingw64/include   \
 [...] -g -O2 [...] \
 -c -o libsrc/lib32_libwmcodecdspuuid_a-wmcodecdspuuid.o \
 [...]/wmcodecdspuuid.c
   ${srcdir}/mingw-w64-crt/libsrc/wmcodecdspuuid.c:8:24: fatal error: 
 wmcodecdsp.h: No such file or directory
   compilation terminated.

 The reason is obvious.  The -I don't include the headers within the
 same src tree, and they don't contain the generated headers within
 the same build tree *even though thay are available*.

 It simply doesn't make sense to require having a copy of these headers
 installed to some arbitrary sysroot dir, just to be able to build crt.


 Corinna

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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...@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
  understand that the SF interface blows for that...)

 No link?  I tried to find it and could not.

 Do we really need that?  I didn't keep a local copy and searching the
 ML archive sucks.

I just thought maybe there was more enlightening discussion.

  I'm a little confused here.  What we require, ie, the only situation
  that we support, is when the version of the headers is the same
  version of the crt.  Ie, svn checkout revision.  Anything outside of
  that will probably work, of course, but nobody tests it.
 
  Sure, I'm not claiming anything else, nor am I trying to do anything
  else.  I want to build a full mingw tree, without having to have
  anything installed outside the source or build tree.

 When you say full mingw tree, do you mean that you are building crt,
 headers, and tools using the top level configure/make, as opposed to
 building each thing you want independently?

 Exactly.  Doing that is a fairly typical scenario, isn't it?

Actually, no.  Pretty much nobody uses the top level configure.  It
was an idea that I had that nobody really wanted, and so it fell into
disuse and doesn't really work (which I guess is what you are seeing).

If you want top level configure to work again, give me some time and
I'll work on it to make it useful.  There's actually numerous problems
with it, not just the hokiness of trying to stage a headers install.

  Now, in terms of the configure test that errors out in the case of not
  finding _mingw_mac.h, that is due to the fact that the headers are
  required to build the crt.  We don't care where they are, we just care
  that they exist.  If they don't, the crt build will be all fouled up.
 
  I'm puzzeled.  That has nothing to do with my patch.

 Your patch changed when it errored out.

 Sorry?  When did my patch change?  When did it error out?  I realy don't
 understand what you're talking about.

Your patch moved the criteria for erroring out on the non-existence of
mingw_mac.h:

-AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if
the mingw-w64 header set and the build/host option are set
properly.])])
+AS_CASE([$with_headers],
+  [yes],[],
+  [AC_CHECK_HEADER([_mingw_mac.h],
+   [],
+   [AC_MSG_ERROR([Please check if the mingw-w64
header set and the build/host option are set properly.])])])

After your patch, configure won't always verify that the headers are
usable for building crt.

  The default, of course, is for the headers to exist in the sysroot
  that the crt is getting installed into.  This is a fairly common usage
  pattern, and modeled after the gcc build.  If they're somewhere else
  instead, you can just use --with-sysroot=some/wheres/else
 
  In fact, the help text for with-sysroot even says this:
   --with-sysroot=DIR   Search for headers within DIR/include
 
  So if you for whatever reason want to stage a build of
  mingw-w64-headers in /tmp/my/dir, you just build the crt with
  --with-sysroot=/tmp/my/dir
 
  Does that not work for you?
 
  Sorry, but I'm really confused about the unnecessary complexity.  I don't
  want to stage anything.  I would like to be able call
 
configure --prefix=...
make
make install

 Which configure are we talking about in all of this?  I thought you
 were always asking about the crt configure, but I'm getting the
 feeling that you're really asking about the top level configure.

 The crt configurey needs a change to be able to build a full mingw
 tree from top level.  I thought that was clear.  Only building crt
 without the headers makes only marginal sense.  My below example
 shows that:

Well, it's clear now.  Although note that until now, every user always
does configure/make/install of headers and crt independently.  Mostly
because top level doesn't really work :)

So at least now I understand your use case I'll look into it from
a different perspective and see what I can see.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 crt,
 headers, and tools using the top level configure/make, as opposed to
 building each thing you want independently?
 Exactly.  Doing that is a fairly typical scenario, isn't it?
 Actually, no.  Pretty much nobody uses the top level configure.  It
 was an idea that I had that nobody really wanted, and so it fell into
 disuse and doesn't really work (which I guess is what you are seeing).

 If you want top level configure to work again, give me some time and
 I'll work on it to make it useful.  There's actually numerous problems
 with it, not just the hokiness of trying to stage a headers install.

 Just to throw another data point out there, I use top-level configure
 for TDM-GCC (i.e. an x86_64-w64-mingw32 native bootstrap). It seems to
 work and is far easier than building each sub-tree individually.

How do you use it?

What I am finding is that there is a fundamental difference in how
AC_CONFIG_SUBDIRS works, and how we would like it to work.  Let's say
we have two packages, p1 and p2.  Both need to be configured, made and
installed (c/m/i for short).  Let's say further that we want to build
p1 and p2 serially such that we would do c1/m1/i1 followed by
c2/m2/i2.  What AC_CONFIG_SUBDIRS does instead is c1/c2, m1/m2, i1/i2.
 This means that in the case of the headers/crt packages, we will be
forcing all work on the headers to be done at configure time.
Translation -- we can't actually build the headers.  This is not
ideal.

Now, currently, we do a lot at configure time, but we do three things
at build time:
Create _mingw_directx.h
Create _mingw_ddk.h
(Optional) Run widl to convert from .widl to .h

You could argue that those three things don't need to happen before
you configure the crt, but currently, we don't have such a limitation
in place.  It's really not my place to create that limitation without
input from the people working in those areas.  I have no idea what's
planned for the future (ie, a future situation where the dependency
does exist.)  I'm open to ideas.  I'm also open to making the top
level configury smarter.

I looked at the gcc top level configury to see how that gets so smart.
 This works more like what I would expect -- serialize the c/m/i
process for each sub package.  It's also insanely complicated, and I
guess hearkens back to what people used to call the cygnus tree.


I am remembering now why I abandoned the top level idea :P

That said, it does work pretty well for the libs and tools, which have
no crazy dependencies.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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-mingw32 native bootstrap). It seems to
 work and is far easier than building each sub-tree individually.
 How do you use it?

 $(RUNTIME_SRC)/configure --build=x86_64-w64-mingw32 --enable-lib32
 --enable-sdk=all --with-libraries=libmangle --with-tools=all
 --prefix=$(RUNTIME_STAGE)
 make
 make install

 If GCC or mingw-w64 introduce ABI-breaking changes (this happens often),
 I build a non-bootstrap GCC first in order to run this top-level
 mingw-w64 build before bootstrapping; otherwise I use the bootstrapped GCC.

So no headers?  IIUC, it's only the headers package that is screwing up.

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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
understand that the SF interface blows for that...)

 For people building just the latest mingw64-headers and mingw64-crt,
 it's kind of surprising that mingw64-crt requires that the headers
 are already installed.  In theory, the right thing to do should be
 that mingw64-crt is build after mingw64-headers, and then prefer the
 just built in-tree headers over the already installed headers.

I'm a little confused here.  What we require, ie, the only situation
that we support, is when the version of the headers is the same
version of the crt.  Ie, svn checkout revision.  Anything outside of
that will probably work, of course, but nobody tests it.

Now, in terms of the configure test that errors out in the case of not
finding _mingw_mac.h, that is due to the fact that the headers are
required to build the crt.  We don't care where they are, we just care
that they exist.  If they don't, the crt build will be all fouled up.

The default, of course, is for the headers to exist in the sysroot
that the crt is getting installed into.  This is a fairly common usage
pattern, and modeled after the gcc build.  If they're somewhere else
instead, you can just use --with-sysroot=some/wheres/else

In fact, the help text for with-sysroot even says this:
 --with-sysroot=DIR   Search for headers within DIR/include

So if you for whatever reason want to stage a build of
mingw-w64-headers in /tmp/my/dir, you just build the crt with
--with-sysroot=/tmp/my/dir

Does that not work for you?




  The
 below patch does that, unless the --without-headers option is set.

 This should work in all typical scenarios:

 - cross build gcc:

   The headers have to be build first.  At the time crt gets build,
   the in-tree headers already have been built for gcc, so they
   are nicely available for the crt build.

 - native build gcc:

   The installed headers are potentially old.  Building crt with the
   latest in-tree headers is preferrable to circumnavigate potential
   bugs in the older headers.

 - native mingw-only build:

   Same as above.

 I can't come up with a scenario in which it would be bad to use the
 in-tree headers, unless you don't build the headers, but crt only.
 This should be fixable, shouldn't it?

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

[NightStrike]

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 libopengl32.a and libgl32.a. Configure gave out an
 error:

 checking GL/gl.h usability... yes
 checking GL/gl.h presence... yes
 checking for GL/gl.h... yes
 checking for glEnable in -lGL... no
 configure: error: lacking proper OpenGL support

 Apparently, the cross compiler is looking for the Unix filename equivalents
 of libopengl32.a and libgl32.a which are libGL.a and libGLU.a, so I copied
 and renamed  libopengl32.a and libgl32.a to libGL.a and libGLU.a
 respectively. This elimnated the error for those libraries, however I now
 get the same type error for glx:

 checking GL/glx.h usability... no
 checking GL/glx.h presence... no
 checking for GL/glx.h... no
 configure: error: lacking proper OpenGL support

 Unfortunately, I couldn't determine if there is a windows related library
 within the directory because there is no intuitively similar named file.
 Can you help with this?

Fedora provides cross compiler libraries.  I'm guessing ubuntu does
the same.  Use the upstream repository to your advantage, as Ruben
suggested.

--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public