Keith Marshall | 20 Nov 17:41 2014

Please vote: should we fix or drop the usleep() function?


Looking in ChangeLog, I see that (a broken) implementation of usleep()
was added to mingwrt in 2008, just about the time that POSIX.1003-1
dropped it, and removed all references to it from the standard.  So...

1) Should we go along with POSIX, and similarly drop it, or...
2) Retain it, but mark it as deprecated?

I'm of two minds, but if we do decide on (2), then we should also fix
the currently broken error return; those earlier versions of POSIX which
did specify it said that it *may* fail if the requested delay is
1,000,000 microseconds or more, it which case it should set errno to
EINVAL, and return -1; our implementation does not set errno, but
returns EINVAL instead of -1.

Furthermore, if we do vote to keep usleep(), it seems kind of anomalous
that we don't also provide an implementation of sleep(), (which remains
a mandatory POSIX function today).




Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
(Continue reading)

Keith Marshall | 20 Nov 16:54 2014

Re: Bug found in math.h (mingwrt)

On 20/11/14 13:08, Thomas Uhle wrote:
> as I am rather unsure where to send a bug report with a patch,


When you go looking for the "Official CVS Repository", note that it's
now a git repository, and there is a reference link (in bold type) at
the top of the reference page ... (note to maintainers: one of us really
needs to find time to update that page properly).  For both mingwrt and
w32api, please ensure that you use the legacy branch -- the master and
development branches are currently unmaintained and unusable.

> to ask whether mingw-dvlpr@... is the right place

No, it isn't, but if you are interested in a more formal association
with the project ...

> and if so, how could I subscribe to that list.

... see



Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
(Continue reading)

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!