NightStrike | 3 Aug 05:48 2015
Picon

mingw symlink

I tried building the toolchain for the first time in a long time, and
I see this is still an issue:

The directory that should contain system headers does not exist:
  /opt/mw64/sysroot/mingw/include

Is it at all possible to get rid of that dependency?  As I recall,
that was a holdover from mistakes made eons ago.  I get that "/mingw"
is the Windows equivalent of "/usr", but the issue here is that the
build system extends the sysroot variable.  It looks for
$sysroot/usr/include or $sysroot/mingw/include instead of just
$sysroot/include.

Does --with-build-sysroot make this go away?  Or, can it be made to do so?

------------------------------------------------------------------------------
Keith Marshall | 17 May 10:03 2015
Picon
Picon

Naming of multiple inclusion guards in MinGW headers

Guys,

I've noticed that we have some headers guarded by macros named according
to a _FOO_H_ convention (with a trailing underscore), while others
conform to _BAR_H (without the trailing underscore); we really need to
standardize on one or the other.

I have a mild preference for the latter, but can accept the former; I
cannot accept indefinite persistence of the present inconsistency.

Any strong contrary opinions, before I embark on a standardization
campaign?  (If you disagree, and don't speak up *now*, I will begin to
move toward adoption the _BAR_H style, just as soon as I find a window
of opportunity; (which may be two or three months hence).

--

-- 
Regards,
Keith.

------------------------------------------------------------------------------
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
Earnie | 6 Jan 00:04 2015
Picon
Picon

Re: What purpose does __NO_ISOCEXT serve?

> -----Original Message-----
> From: Earnie 
> Sent: Monday, December 22, 2014 4:03 PM
> To: 'MinGW Devlopers Discussion List'
> Subject: RE: [MinGW-dvlpr] What purpose does __NO_ISOCEXT serve?
> 
> > -----Original Message-----
> > From: Keith Marshall
> 
> >
> > IMO, it is an aberration.  AFAICT, it is another mechanism, in
> > addition to __STRICT_ANSI__, for suppressing declarations which are
> > not expected to be specified in the ISO-C namespace.  In the mingwrt
> > headers, I see several instances where non-ISO-C declarations are
> > conditionalized on
> !__NO_ISOCEXT,
> > but many more where !__STRICT_ANSI__ is used (abused?) for the same
> > purpose; there seems to be no rational explanation for the particular
> choice
> > made, in each instance.
> >
> > I'd like to get rid of this aberration.  Unfortunately, there seems to
> > be
> an
> > abundance of anecdotal evidence, on the internet, for it having leaked
> into user
> > space, (in spite of the double underscore prefix, which
> > *should* mark it as reserved for internal use by the runtime
> implementation).
> > Thus, I propose folding it into a _mingw.h feature test
(Continue reading)

Keith Marshall | 21 Dec 14:58 2014
Picon
Picon

What purpose does __NO_ISOCEXT serve?

IMO, it is an aberration.  AFAICT, it is another mechanism, in addition
to __STRICT_ANSI__, for suppressing declarations which are not expected
to be specified in the ISO-C namespace.  In the mingwrt headers, I see
several instances where non-ISO-C declarations are conditionalized on
!__NO_ISOCEXT, but many more where !__STRICT_ANSI__ is used (abused?)
for the same purpose; there seems to be no rational explanation for the
particular choice made, in each instance.

I'd like to get rid of this aberration.  Unfortunately, there seems to
be an abundance of anecdotal evidence, on the internet, for it having
leaked into user space, (in spite of the double underscore prefix, which
*should* mark it as reserved for internal use by the runtime
implementation).  Thus, I propose folding it into a _mingw.h feature
test initialization, (_POSIX_C_SOURCE perhaps?), and replacing its use
elsewhere, with the appropriate *enabling* feature test.

Thoughts?  Objections?

--

-- 
Regards,
Keith.

------------------------------------------------------------------------------
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
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
Keith Marshall | 20 Nov 17:41 2014
Picon
Picon

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

Guys,

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

Thoughts?

--

-- 
Regards,
Keith.

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

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,

See http://www.mingw.org/wiki/SubmitPatches

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 http://www.mingw.org/joining_the_team

--

-- 
Regards,
Keith.

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

*.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 foo.sx 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.

Thoughts?

--

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Cesar Strauss | 23 Oct 23:06 2014
Picon

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:

https://cygwin.com/viewvc/src/winsup/mingw/
https://cygwin.com/viewvc/src/winsup/w32api/

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.

Regards,

Cesar

------------------------------------------------------------------------------
David Gressett | 29 Sep 19:04 2014
Picon

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.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
David Gressett | 1 Sep 22:17 2014
Picon

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

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.

--

-- 
Regards,
Keith.

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/

Gmane