Keith Marshall | 29 Oct 22:52 2014

*.s vs. *.S vs. *.sx file naming

Given that the case-insensitive nature of the Windows file system means
that dir/foo.s and dir/foo.S would be one and the same file, and that
GCC now promotes the convention that represents a case agnostic
alternative to foo.S, we really shouldn't be using the foo.S form.

With this in mind, and given that both git and Mercurial, unlike CVS,
can readily accommodate renamed files, I was going to rename all of the
*.S files in mingwrt/mingwex/math to their equivalent *.sx names.
However, before committing the change, I took a quick peek at their
content, and I can't see a single one which needs to be anything other
than a simple *.s file; not one of them needs the C preprocessor, so why
were they ever named *.S, in the first place?

Although I have developed the necessary infrastructure for configure and
make, to support the *.sx convention, (and will need it later), I think
it best to rename all existing *.S files with the correct *.s extension.




Cesar Strauss | 23 Oct 23:06 2014

Preserving CVS history

Hi Keith,

On the ChangeLog of the legacy branch of mingw-org-wsl, you wrote:

> 	* w32api: New directory; use w32api-3.17-2 release as baseline for
> 	import; once again, original CVS history is NOT preserved.

> 	* mingwrt: New directory; use mingwrt-3.20-2 release as baseline
> 	for import; original CVS history is NOT preserved.

The authoritative CVS repository for mingwrt and w32api seems to be:

What do you think of importing the full CVS history as two separated git 
repositories? It could be for historical purposes or even for starting 
again from a clean state.



David Gressett | 29 Sep 19:04 2014

Going forwards to gcc 4.9

What do we need to do to move towards a release of MinGW gcc 4.9?
Now that avys has reported a successful build of 4.9.1 and used it to
build binutils and gcc for ARM (with a few problems), gcc 4.9.1 looks
to be very close to being generally usable.
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
David Gressett | 1 Sep 22:17 2014

Successful build of gcc 4.9.1

My efforts to build gcc 4.9.1 have succeeded. The makefile tweak that
corrected the references to the 4.8.1 version number seem to have fixed
the 4.9.1 build failure.

So,  here is a summary of what it takes to build  a 4.9.1 gcc:

The building compiler must have no trace of the V4 runtime and Win32 api.
It is insufficient to replace them with the V3 versions; the building 
compiler itself must be built without them; The first building compiler 
that worked for my gcc 4.9.1 build was was gcc 4.8.3; it was built with
the version 3 runtime and win32 api, installed, and then built again and
installed. I expect that a similar rebuild of 4.8.1 would have worked
just as well, but after I found that 4.8.3 produced better error messages,
I stayed with it.

The MinGW package builder  environments that I used for my most recent
4.8.3 and 4.9.1 builds are attached. I have deleted the "pristine source"
tarballs to make them small enough for e-mail.

Note that my 4.9.1 build is done with no patches whatsoever - it truly is
a "pristine source" build. My 4.8.3 build includes the additional patch
to fix the Ada bug caused by use of a 64-bit time_t C type. The patch is
a no-op for a 32-bit time_t type, but I am keeping it in my builds, as it
will make Ada immune to a future return to a 64-bit time_t. A similar
patch will go into my next 4.9.1 build. I have filed a bug report for 
this with the upstream gcc project.

I Am now using gcc 4.8.3 as my production compiler suite  at work. It has 
build two very large Ada packages from the GNAVI Sourceforge project
that I use heavily at work, as well as another one that I wrote to
(Continue reading)

Keith Marshall | 25 Aug 23:16 2014

mingw-dist: issue.log file attributes corrupt

This seems to happen on every update of dos2unix: Erwin, every time you
push, every issue.log file you touch gets its executable attribute set
to "on".  This is wrong, and seems to cause spurious scheduling of the
republication of various related XML files.

Please investigate, and rectify the issue, at your end.



Slashdot TV.  
Video for Nerds.  Stuff that matters.
David Gressett | 25 Aug 04:03 2014

Update on gcc 4.9.1 build project

I have continued to work on gcc 4.9 (as free time allows) and am making
some progress.

I had previously built and installed gcc 4.8.3 using the V4 runtime and 
win32 api. 

That version of gcc 4.8.3 failed to build 4.9.1 with a failure to 
compile gcc/ada/adaint.c, as I reported in a previous message.

I then used mingw-get to remove and replace the V4 runtime and win32 api
with mingwrt 3.20 and w32api 3.17. I then made another attempt to build
gcc 4.9.1.

That one failed again, but adaint.c was not the problem. It compiled with
no problems. The build proceeded much farther - it made it into the next
stage of the build, when the result of the first stage, xgcc, was the
compiler doing the work. The failure was again an Ada problem, but this
one was an ada tool: gnatmake.exe. Had it been consistently named with
xgcc, it would have been xgnatmake.exe. It was unable to open a file
named I was able to extract it, and its equivalent from the 
4.8.3 build into test directories and run both with gdb to see where
their behavior differed. gdb had problems displaying Ada variable 
contents, but it was obvious that there was very little difference
between the 4.8.3 and 4.9.1 source code in gnatmake. 

The offending gnatmake could also not get its own name from the  command
line; it displayed in Chinese characters.

At this point, things were not looking good for the V4 runtime and 
win32 api.
(Continue reading)

David Gressett | 31 Jul 21:30 2014

Debugging gcc 4.9 build failure

2nd attempt to post to list; 1st one was rejected

My first submission to the list - a progress report on my
efforts to build gcc 4.9

The gcc 4.9.1 build fails in the same place as the 4.9.0
build did; I have abandoned 4.9.0 and will 
concentrate on 4.9.1. 

The problem occurs when building the Ada runtime library.
The offender is gcc/ada/adaint.c, which fails to compile because the definitions

#define UNICODE
#define _UNICODE

in the dependent include file mingw32.h seem to have no

I stripped adaint.c and all dependent include files into
a test directory and shrank adaint.c into a minimal demo of the compile error
using the command line from the log file that was used to compile it for the
main build. I renamed and copied dependent system include files into the test
directory and renamed them in the including files so that I could make any
necessary tweaks to them without disturbing the original include files.

The final result is that there is nothing wrong with
anything in the gcc/ada directory that is causing the build failure. The
UNICODE and _UNICODE definitions in the dependent include file mingw32.h are
meaningless; they do not reach _mingw32.h because a previous inclusion of
<sys/stat.h> pulls in _mingw32.h at a point where UNICODE and _UNICODE
(Continue reading)

Keith Marshall | 20 Jan 19:40 2014

Re: mingw-pkg vs mgwport

On 19/01/14 20:48, Sebastian Schuberth wrote:
> Would you mind sharing mingw-pkg, at least privately, with me so that I 
> can evaluate it against mgwport (which does not seem to be maintained 
> anymore) for building the packages at [1]?

Sure.  I've created a git repository here:

FYI, I manage this using Mercurial, (git's only mitigating feature,
AFAIAC, being that I can do this).  Hence, there's an .hgignore file,
but currently no .gitignore, and I've provided an hg plugin to track
patches -- somewhat kludgey ATM, but I intend to rework it to use
Mercurial Queues.  I won't write it myself, but I will be happy to
consider patches to add a similar git plugin.

FWIW, my $HOME/.mingw-pkgrc is attached.


# Initialisation preferences for mingw-pkg tool.

AUTHOR="Keith Marshall"
AUTHOR_EMAIL="keithmarshall <at>"


(Continue reading)

Keith Marshall | 18 Dec 12:52 2013

Our GCC-4.8 is broken


IMO, our release of gcc-4.8.1 has been an unmitigated disaster!  Broken
packages; bugs such as

This doesn't do a lot for our credibility; (the more so, since it now
seems that Earnie is remaining silent regarding the issues).  We need a
high priority plan to fix this.

In the short term, I'm inclined to suggest rolling back to GCC-4.7, as
our default offering, and ripping all of the broken packages out of the
on-line catalogue.



Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
Aaron Gray | 30 Nov 15:25 2013

Building bison-3.0.1 via Cygwin MinGW32 cross compilation

Following :- 
I have built bison 3.0.1 with a few source mods and using Cygwin :-
    export lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32
    export lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32
    export PATH="/c/MinGW/bin:${PATH}"
    ../../src/bison-3.0.1/configure --build=i686-pc-mingw32 --host=i686-pc-mingw32
On running bison.exe I am getting an error message in a popup:-
   The procedure entry point _set_invalid_parameter_handler could not be
   located in the dynamic library C:\MinGW\msys\1.0\bin\bison.exe
Am I using the right procedure ?
Many thanks in advance,
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
MinGW-dvlpr mailing list
Keith Marshall | 19 Oct 00:00 2013



What is your rationale for defining both of these?  Apart from a
syntactic inconsistency in their definitions, (which should be
eliminated), the two appear to be strictly equivalent.



October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >