Definition of struct timespec in MinGW runtime 3.21

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Definition of struct timespec in MinGW runtime 3.21

Eli Zaretskii
This is just to draw people's attention to one issue I've bumped into
with the latest MinGW runtime v3.21.

The runtime now defines 'struct timespec' in an internal header
parts/time.h which is included by unistd.h, presumably to be able to
declare a prototype of 'nanosleep'.

There are 2 problems with this:

 . time.h does not include parts/time.h, although I think it was meant
   to do so.  As result, configure scripts that check whether system
   headers define the struct, and look for it in time.h and
   sys/time.h, will not find it.

 . The "usual" definition of 'struct timespec' uses time_t as the type
   of the tv_sec member, but MinGW runtime uses 'long long' instead.
   Since time_t is still 32-bit wide, this means potential trouble, at
   least in the following cases:

   . if the replacement definition, generated as result of the failure
     of the configure script to find the definition provided by MinGW,
     uses time_t, and the application then includes unistd.h, the
     compilation will fail; for one such problem that already happened
     see
       http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00042.html

   . including pthread.h in a program that also includes unistd.h will
     most probably also fail, since pthread.h defines this structure
     using time_t

I think MinGW should at least include parts/time.h in time.h.  Not
sure what to do with the Pthreads incompatibility, though.  It might
be possible to add to parts/time.h the HAVE_STRUCT_TIMESPEC guard that
pthread.h uses to define its own struct, but that won't help with
using precompiled binaries of Pthreads, if they were built with
previous versions of MinGW.  Any suggestions?

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Definition of struct timespec in MinGW runtime 3.21

マーズ ho han keng
Hello Eli,
I dual boot Fedora 20 Heisenbug x86_64 and Win 8.1.
It is still 32 bit time_t in both OS. May be the problem is
hardware related, ie. the RTC is ticking away in 32-bit
register.

I did a simple C++ a.out to test the numeric limits of time_t
for Heisenbug and time_t overflows by the year 2106. So we
may not be around then, not our problem?

Eli Zaretskii wrote:

> This is just to draw people's attention to one issue I've
bumped into
> with the latest MinGW runtime v3.21.
>
> The runtime now defines 'struct timespec' in an internal
header
> parts/time.h which is included by unistd.h, presumably to
be able to
> declare a prototype of 'nanosleep'.
>
> There are 2 problems with this:
>
>  . time.h does not include parts/time.h, although I think
it was meant
>    to do so.  As result, configure scripts that check
whether system
>    headers define the struct, and look for it in time.h and
>    sys/time.h, will not find it.
>
>  . The "usual" definition of 'struct timespec' uses time_t
as the type
>    of the tv_sec member, but MinGW runtime uses 'long long'
instead.
>    Since time_t is still 32-bit wide, this means potential
trouble, at
>    least in the following cases:
>
>    . if the replacement definition, generated as result of
the failure
>      of the configure script to find the definition
provided by MinGW,
>      uses time_t, and the application then includes
unistd.h, the
>      compilation will fail; for one such problem that
already happened
>      see
>        http://lists.gnu.org/archive/html/bug-
gnulib/2015-01/msg00042.html
>
>    . including pthread.h in a program that also includes
unistd.h will
>      most probably also fail, since pthread.h defines this
structure
>      using time_t
>
> I think MinGW should at least include parts/time.h in
time.h.  Not
> sure what to do with the Pthreads incompatibility, though.  
It might
> be possible to add to parts/time.h the HAVE_STRUCT_TIMESPEC
guard that
> pthread.h uses to define its own struct, but that won't
help with
> using precompiled binaries of Pthreads, if they were built
with
> previous versions of MinGW.  Any suggestions?
>
>
------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in
Ashburn, VA.
> GigeNET is offering a free month of service with a new
server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of
bandwidth.
> Higher redundancy.Lower latency.Increased
capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> MinGW-users mailing list
> MinGW-
[hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for
the list etiquette
> may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe
at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also:
> mailto:mingw-users-
[hidden email]?subject=unsubscribe



------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Definition of struct timespec in MinGW runtime 3.21

John Brown


On Sun, 18 Jan 2015 07:08:37 +0800, ho han keng wrote:

> Eli Zaretskii wrote:
>
>> [description of problem with struct timespec snipped]

>
> Hello Eli,
...
>
> I did a simple C++ a.out to test the numeric limits of time_t
> for Heisenbug and time_t overflows by the year 2106. So we
> may not be around then, not our problem?
>

Hello ho han keng,

The problem is not the date range allowed by long long or time_t.
The problem is:
>> if the replacement definition ... uses time_t, and the application
>> then includes unistd.h, the compilation will fail; for one such problem
>> that already happened see
>> http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00042.html
>>

There is also a probable incompatibility with pthreads.

Regards,
John Brown.


     
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Definition of struct timespec in MinGW runtime 3.21

Eli Zaretskii
> From: John Brown <[hidden email]>
> Date: Sun, 18 Jan 2015 04:46:45 -0500
>
> The problem is not the date range allowed by long long or time_t.
> The problem is:
> >> if the replacement definition ... uses time_t, and the application
> >> then includes unistd.h, the compilation will fail; for one such problem
> >> that already happened see
> >> http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00042.html
> >>
>
> There is also a probable incompatibility with pthreads.

Indeed, those are the real problems here.

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Definition of struct timespec in MinGW runtime 3.21

Keith Marshall-3
In reply to this post by Eli Zaretskii
On 17/01/15 14:31, Eli Zaretskii wrote:
> This is just to draw people's attention to one issue I've bumped into
> with the latest MinGW runtime v3.21.
>
> The runtime now defines 'struct timespec' in an internal header
> parts/time.h which is included by unistd.h, presumably to be able to
> declare a prototype of 'nanosleep'.

Exactly so, yes, (and this is the only use currently made of struct
timespec, within mingwrt).

> There are 2 problems with this:
>
>  . time.h does not include parts/time.h, although I think it was meant
>    to do so.  As result, configure scripts that check whether system
>    headers define the struct, and look for it in time.h and
>    sys/time.h, will not find it.

I'll confess that I didn't think of possible third party ramifications,
when I added struct timespec.  Yes, time.h should include parts/time.h,
but I've yet to work through the details, and right now, I don't have
time to address the issue.

>  . The "usual" definition of 'struct timespec' uses time_t as the type
>    of the tv_sec member, but MinGW runtime uses 'long long' instead.

But, what the heck is time_t?  As you well know, POSIX still thinks of
it as 32-bit, but notes that it will eventually need to accommodate a
wider numeric range than 32-bit can support; however, the POSIX working
group has not yet given sufficient attention to how that might be
accomplished to warrant standardization; Microsoft, OTOH, have shown us,
dramatically, how to make a real pig's ear of it, with their utterly
unworkable, and thoroughly ambiguous 32/64-bit implementation.

>    Since time_t is still 32-bit wide,

But is it?  Microsoft's _USE_32BIT_TIME_T insanity means that it could
be either 32-bit or 64-bit.

>    this means potential trouble, at least in the following cases:
>
>    . if the replacement definition, generated as result of the failure
>      of the configure script to find the definition provided by MinGW,
>      uses time_t, and the application then includes unistd.h, the
>      compilation will fail; for one such problem that already happened
>      see
>        http://lists.gnu.org/archive/html/bug-gnulib/2015-01/msg00042.html
>
>    . including pthread.h in a program that also includes unistd.h will
>      most probably also fail, since pthread.h defines this structure
>      using time_t
>
> I think MinGW should at least include parts/time.h in time.h.
Yes, eventually it should, and will.

> Not sure what to do with the Pthreads incompatibility, though.  It
> might be possible to add to parts/time.h the HAVE_STRUCT_TIMESPEC
> guard that pthread.h uses to define its own struct, but that won't
> help with using precompiled binaries of Pthreads, if they were built
> with previous versions of MinGW.  Any suggestions?

With the benefit of hindsight -- isn't it a wonderful thing? -- perhaps
I was premature in exposing the implementation of nanosleep(); I wanted
to fix a broken usleep(), and nanosleep() was a natural extension of
that resolution.  Obviously, *anything* which relies on time_t on
Windows will be susceptible to 32 vs. 64-bit ambiguity in the typedef,
and thus must be considered broken, so I contend that pthread.h is
broken anyway.  Since I don't have time to devote to this at present,
perhaps the best interim solution would be to hide the nanosleep()
implementation in unistd.h, thus making inclusion of parts/time.h
unnecessary, (and parts/time.h redundant for the time being), until such
time as a suitable resolution can be identified.

--
Regards,
Keith.

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

hide-nanosleep.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Definition of struct timespec in MinGW runtime 3.21

Eli Zaretskii
> Date: Tue, 20 Jan 2015 08:52:46 +0000
> From: Keith Marshall <[hidden email]>
>
> >  . time.h does not include parts/time.h, although I think it was meant
> >    to do so.  As result, configure scripts that check whether system
> >    headers define the struct, and look for it in time.h and
> >    sys/time.h, will not find it.
>
> I'll confess that I didn't think of possible third party ramifications,
> when I added struct timespec.  Yes, time.h should include parts/time.h,
> but I've yet to work through the details, and right now, I don't have
> time to address the issue.

Could you tell what potential problems need to be figured out for
this to happen?

> >  . The "usual" definition of 'struct timespec' uses time_t as the type
> >    of the tv_sec member, but MinGW runtime uses 'long long' instead.
>
> But, what the heck is time_t?  As you well know, POSIX still thinks of
> it as 32-bit, but notes that it will eventually need to accommodate a
> wider numeric range than 32-bit can support; however, the POSIX working
> group has not yet given sufficient attention to how that might be
> accomplished to warrant standardization; Microsoft, OTOH, have shown us,
> dramatically, how to make a real pig's ear of it, with their utterly
> unworkable, and thoroughly ambiguous 32/64-bit implementation.
>
> >    Since time_t is still 32-bit wide,
>
> But is it?  Microsoft's _USE_32BIT_TIME_T insanity means that it could
> be either 32-bit or 64-bit.

Yes, I understand that.  I meant to say that MinGW's time_t is 32-bit
_by_default_.

> > Not sure what to do with the Pthreads incompatibility, though.  It
> > might be possible to add to parts/time.h the HAVE_STRUCT_TIMESPEC
> > guard that pthread.h uses to define its own struct, but that won't
> > help with using precompiled binaries of Pthreads, if they were built
> > with previous versions of MinGW.  Any suggestions?
>
> With the benefit of hindsight -- isn't it a wonderful thing? -- perhaps
> I was premature in exposing the implementation of nanosleep(); I wanted
> to fix a broken usleep(), and nanosleep() was a natural extension of
> that resolution.  Obviously, *anything* which relies on time_t on
> Windows will be susceptible to 32 vs. 64-bit ambiguity in the typedef,
> and thus must be considered broken, so I contend that pthread.h is
> broken anyway.

I agree that this is not an easy problem.  But I think at least the
situation where one compiles the entire program, including any
3rd-party libraries, with the default mingwrt settings, where time_t
is a 32-bit quantity, should work.  Using time_t in struct timespec
thus would have solved more use cases than using 'long long'.  But I
guess this is water under the bridge, now that 3.21 is out in the
open.

> Since I don't have time to devote to this at present,
> perhaps the best interim solution would be to hide the nanosleep()
> implementation in unistd.h, thus making inclusion of parts/time.h
> unnecessary, (and parts/time.h redundant for the time being), until such
> time as a suitable resolution can be identified.

Hiding nanosleep will only help if the program doesn't use it.  If it
does, the configure script will likely find the function anyway
(because a test program will compile and link), and then using a
definition of 'struct timespec' supplied by, say, gnulib, with time_t
as the first member type, will produce a broken problem.

I think we should instead advertise our 'struct timespec' in time.h
ASAP, so that as many packages as possible detect its existence and
use our definition, instead of providing a (broken) substitute with
time_t.  (I already asked the gnulib maintainers to add a test for
unistd.h as one more possible place where 'struct timespec' might be
defined, and this change is already in upstream gnulib.)  This will
leave us with only Pthreads as a problem, where the solution is to
build the library with the latest MinGW runtime and change the struct
definition.

Thanks.

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Definition of struct timespec in MinGW runtime 3.21

Keith Marshall-3
On 20/01/15 16:47, Eli Zaretskii wrote:
>> Date: Tue, 20 Jan 2015 08:52:46 +0000
>> From: Keith Marshall
>> I'll confess that I didn't think of possible third party ramifications,
>> when I added struct timespec.  Yes, time.h should include parts/time.h,
>> but I've yet to work through the details, and right now, I don't have
>> time to address the issue.
>
> Could you tell what potential problems need to be figured out for
> this to happen?

It needs a review of time.h, vis-a-vis other existing headers; is there
anything else in there which should maybe be factored out, into the
internal header.  ATM, I simply cannot devote any time to this.

>>>    Since time_t is still 32-bit wide,
>>
>> But is it?  Microsoft's _USE_32BIT_TIME_T insanity means that it could
>> be either 32-bit or 64-bit.
>
> Yes, I understand that.  I meant to say that MinGW's time_t is 32-bit
> _by_default_.

But we have always instructed users to seek documentation on MSDN; this
would now have them believe that time_t defaults to 64-bit.

>> Since I don't have time to devote to this at present,
>> perhaps the best interim solution would be to hide the nanosleep()
>> implementation in unistd.h, thus making inclusion of parts/time.h
>> unnecessary, (and parts/time.h redundant for the time being), until such
>> time as a suitable resolution can be identified.
>
> Hiding nanosleep will only help if the program doesn't use it.  If it
> does, the configure script will likely find the function anyway
> (because a test program will compile and link), and then using a
> definition of 'struct timespec' supplied by, say, gnulib, with time_t
> as the first member type, will produce a broken problem.

The Q&D patch I suggested yesterday would also *remove* nanosleep() from
libmingwex() entirely, so no, a configure script would not find it in a
quickly republished mingwrt-3.21.1.

> I think we should instead advertise our 'struct timespec' in time.h
> ASAP, so that as many packages as possible detect its existence and
> use our definition, instead of providing a (broken) substitute with
> time_t.

In an ideal world, I agree.  However, current constraints on my time
mean that I may not be able to address that effectively until July or
August, at the earliest, whereas I might just manage to squeeze out a
Q&D interim release, with nanosleep() removed.

--
Regards,
Keith.

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Definition of struct timespec in MinGW runtime 3.21

Keith Marshall-3
In reply to this post by Eli Zaretskii
On 20/01/15 16:47, Eli Zaretskii wrote:
>>>  . time.h does not include parts/time.h, although I think it was meant
>>>    to do so.

My time for following up on this is still extremely limited, but I have
managed to get to some groundwork.  Is the attached patch sufficient to
address the "struct timespec" issue to your satisfaction?  (Note that it
also corrects a consistent misspelling of the "__cdecl" attribute in
unistd.h, and an initialization bug which I've noticed in glob.c, and it
removes the long obsolete varargs.h file).

>>>    Since time_t is still 32-bit wide,
>>
>> But is it?  Microsoft's _USE_32BIT_TIME_T insanity means that it could
>> be either 32-bit or 64-bit.
>
> Yes, I understand that.  I meant to say that MinGW's time_t is 32-bit
> _by_default_.

It isn't really MinGW's time_t; it's Microsoft's.  I've done some
experiments, (I'll make the code available when I'm less strapped for
time), which convince me that Microsoft's time_t, as it is implemented
in all versions of MSVCRT.DLL shipped with all versions of Windows up to
and including Win7, is resolutely equivalent to __time32_t; it is only
in those brain damaged MSVCRxx.DLL variants, from MSVCR80.DLL onwards,
that the "_USE_32BIT_TIME_T" insanity rears its ugly head.  Nonetheless,
I have revisited my "struct timespec" definition such that it is able to
accommodate a 64-bit "tv_sec" member, but with the default as a 32-bit
time_t, to match the usage in MSVCRT.DLL

--
Regards,
Keith.

------------------------------------------------------------------------------

_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

mingwrt-3.21-patch.20150518.xz (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Definition of struct timespec in MinGW runtime 3.21

Eli Zaretskii
> Date: Fri, 05 Jun 2015 09:32:00 +0100
> From: Keith Marshall <[hidden email]>
>
> On 20/01/15 16:47, Eli Zaretskii wrote:
> >>>  . time.h does not include parts/time.h, although I think it was meant
> >>>    to do so.
>
> My time for following up on this is still extremely limited, but I have
> managed to get to some groundwork.  Is the attached patch sufficient to
> address the "struct timespec" issue to your satisfaction?

Thanks a lot, I will try this as soon as I can.  It will probably be a
few days before I have an opportunity.

> >>>    Since time_t is still 32-bit wide,
> >>
> >> But is it?  Microsoft's _USE_32BIT_TIME_T insanity means that it could
> >> be either 32-bit or 64-bit.
> >
> > Yes, I understand that.  I meant to say that MinGW's time_t is 32-bit
> > _by_default_.
>
> It isn't really MinGW's time_t; it's Microsoft's.  I've done some
> experiments, (I'll make the code available when I'm less strapped for
> time), which convince me that Microsoft's time_t, as it is implemented
> in all versions of MSVCRT.DLL shipped with all versions of Windows up to
> and including Win7, is resolutely equivalent to __time32_t; it is only
> in those brain damaged MSVCRxx.DLL variants, from MSVCR80.DLL onwards,
> that the "_USE_32BIT_TIME_T" insanity rears its ugly head.  Nonetheless,
> I have revisited my "struct timespec" definition such that it is able to
> accommodate a 64-bit "tv_sec" member, but with the default as a 32-bit
> time_t, to match the usage in MSVCRT.DLL

Thanks, I think this is TRT to do to make sure programs built with
MinGW runtime will run correctly on all versions of Windows, including
the older ones.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Building MinGW GCC (was: Definition of struct timespec in MinGW runtime 3.21)

Eli Zaretskii
In reply to this post by Keith Marshall-3
On a (slightly) related topic: since no one seems to volunteer to
build newer versions of GCC for MinGW, I could try doing that myself
(the binaries will then be made available from the ezwinports site).
But I need some help figuring out the prerequisite support packages I
need to build first, and the optional GCC features to enable/disable.
Last time I built GCC on any OS was many years ago, and a lot has
changed since then.

Keith, I've looked at your script that you used for GCC 4.8.2, but
there were too many issues there that I couldn't figure out by myself,
which means I'd need a lot of wading through GCC docs and sources (and
a lot of Googling), before I make up my mind on these issues.

Therefore, an annotated list of GCC prerequisites and build options,
together with issues to consider when deciding whether or not to
enable/include them in the MinGW build, will be most appreciated.

Please note that I intend to build GCC natively, using MSYS.

(In case it's important, I already have the latest Binutils built for
MinGW, and can build newer versions of them if needed; building
Binutils for MinGW is easy.  Btw, if there's enough demand, I can make
MinGW 32-bit build of Binutils 2.25 available on ezwinports.)

TIA to anyone who could share their experiences and advice on this.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Building MinGW GCC

asmwarrior
On 2015-6-5 17:21, Eli Zaretskii wrote:

> On a (slightly) related topic: since no one seems to volunteer to
> build newer versions of GCC for MinGW, I could try doing that myself
> (the binaries will then be made available from the ezwinports site).
> But I need some help figuring out the prerequisite support packages I
> need to build first, and the optional GCC features to enable/disable.
> Last time I built GCC on any OS was many years ago, and a lot has
> changed since then.
>
> Keith, I've looked at your script that you used for GCC 4.8.2, but
> there were too many issues there that I couldn't figure out by myself,
> which means I'd need a lot of wading through GCC docs and sources (and
> a lot of Googling), before I make up my mind on these issues.
>
> Therefore, an annotated list of GCC prerequisites and build options,
> together with issues to consider when deciding whether or not to
> enable/include them in the MinGW build, will be most appreciated.
>
> Please note that I intend to build GCC natively, using MSYS.
>
> (In case it's important, I already have the latest Binutils built for
> MinGW, and can build newer versions of them if needed; building
> Binutils for MinGW is easy.  Btw, if there's enough demand, I can make
> MinGW 32-bit build of Binutils 2.25 available on ezwinports.)
>
> TIA to anyone who could share their experiences and advice on this.
>

Hi, Eli

I think there are some links you can take as references:

1,
TDM gcc has 32bit mingw gcc toolchain(last year, he release gcc 4.9.2 for windows),
you can see the patches and scripts he use.
https://sourceforge.net/projects/tdm-gcc/files/Sources/TDM%20Sources/
I see he build gcc under msys.
Though he may use slightly different configure options and prerequisite support packages.

2,
I recently found that we should fix the large pch file crash issue, see:
Comment 17 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926#c17
Especially the comment 17, I think 512M pch is enough, current 128M is too small.

3,
I use some gdb patches to handle windows related issue, such as this bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=15559
With out this patch, inferior call under gdb get failed if you try to
call the class member function.

asmwarrior


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Building MinGW GCC

John E. / TDM
On 6/5/2015 9:04 AM, asmwarrior wrote:
> On 2015-6-5 17:21, Eli Zaretskii wrote:
>> Therefore, an annotated list of GCC prerequisites and build options,
>> together with issues to consider when deciding whether or not to
>> enable/include them in the MinGW build, will be most appreciated.
*snip*
> 1,
> TDM gcc has 32bit mingw gcc toolchain(last year, he release gcc 4.9.2 for windows),
> you can see the patches and scripts he use.
> https://sourceforge.net/projects/tdm-gcc/files/Sources/TDM%20Sources/
> I see he build gcc under msys.
> Though he may use slightly different configure options and prerequisite support packages.

Yep, feel free to dig into these build scripts if you like. (The
documentation is pretty minimal, though.)

Off the top of my head (with a little bit of looking through the README
to jog my memory):
* Set --prefix to a path on your C: drive, or else end users whose D: E:
F: etc. drives are removable will get spurious error dialog boxes every
time they run GCC.
* When starting the GCC build the --prefix tree should already contain
built binutils, mingwrt and w32api, as well as GMP, MPFR, MPC, CLOOG (if
pre-GCC-5.x), and ISL.
* Use "make install prefix=[staging path]" to get a clean GCC-only tree
for packaging.
* buildsys.patch includes a hunk that sets i686 as the default
instruction set, which is necessary if building Ada language support.
(In the new GCC 5.x there are even more Ada changes that break MinGW
compatibility.)
* Some paths that are searched for headers/libraries are fully hardcoded
as opposed to being "relocatable" - relocate.patch fixes this but breaks
the build system unless (as in the TDM system) environment variables are
set up to supplement the missing paths during the build.
* If you're not a glutton for punishment, there may be better ways to
spend your time than building GCC on Windows. :)

-John E. / TDM

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Building MinGW GCC

Eli Zaretskii
> Date: Fri, 05 Jun 2015 09:46:22 -0600
> From: "John E. / TDM" <[hidden email]>
>
> On 6/5/2015 9:04 AM, asmwarrior wrote:
> > On 2015-6-5 17:21, Eli Zaretskii wrote:
> >> Therefore, an annotated list of GCC prerequisites and build options,
> >> together with issues to consider when deciding whether or not to
> >> enable/include them in the MinGW build, will be most appreciated.
> *snip*
> > 1,
> > TDM gcc has 32bit mingw gcc toolchain(last year, he release gcc 4.9.2 for windows),
> > you can see the patches and scripts he use.
> > https://sourceforge.net/projects/tdm-gcc/files/Sources/TDM%20Sources/
> > I see he build gcc under msys.
> > Though he may use slightly different configure options and prerequisite support packages.
>
> Yep, feel free to dig into these build scripts if you like. (The
> documentation is pretty minimal, though.)

Thanks, but I'm specifically looking for human-readable documentation,
not scripts.

> Off the top of my head (with a little bit of looking through the README
> to jog my memory):
> * Set --prefix to a path on your C: drive, or else end users whose D: E:
> F: etc. drives are removable will get spurious error dialog boxes every
> time they run GCC.
> * When starting the GCC build the --prefix tree should already contain
> built binutils, mingwrt and w32api, as well as GMP, MPFR, MPC, CLOOG (if
> pre-GCC-5.x), and ISL.
> * Use "make install prefix=[staging path]" to get a clean GCC-only tree
> for packaging.
> * buildsys.patch includes a hunk that sets i686 as the default
> instruction set, which is necessary if building Ada language support.
> (In the new GCC 5.x there are even more Ada changes that break MinGW
> compatibility.)
> * Some paths that are searched for headers/libraries are fully hardcoded
> as opposed to being "relocatable" - relocate.patch fixes this but breaks
> the build system unless (as in the TDM system) environment variables are
> set up to supplement the missing paths during the build.

Thanks, this is useful, although most of it is pretty basic, as
building MinGW ports of any GNU software goes.  What I'm looking for
is some discussion of optional features and packages that GCC can be
built with or without.  Any chance of sharing those?

> * If you're not a glutton for punishment, there may be better ways to
> spend your time than building GCC on Windows. :)

If you, or someone else, will produce MinGW-standard builds of the
latest versions of GCC, and upload them to some place, I promise not
to try to ;-)

(No, I don't want to switch to TDM.)

Thanks.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Building MinGW GCC

John E. / TDM
On 6/5/2015 1:13 PM, Eli Zaretskii wrote:
> Thanks, this is useful, although most of it is pretty basic, as
> building MinGW ports of any GNU software goes.  What I'm looking for
> is some discussion of optional features and packages that GCC can be
> built with or without.  Any chance of sharing those?

Your best bet is probably to work from previous builds' configury
command lines in conjunction with the GCC online documentation.

Here is the configury command line (output from "gcc -v") for TDM-GCC
4.9.2, 32-bit edition. Every item is in there for a reason -- often a
complicated reason.

Configured with: ../../../src/gcc-4.9.2/configure --build=mingw32
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp
--enable-lto --enable-graphite --enable-libstdcxx-debug
--enable-threads=posix --enable-version-specific-runtime-libs
--enable-fully-dynamic-string --enable-libstdcxx-threads
--enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls
--disable-win32-registry --disable-symvers
--enable-cxx-flags='-fno-function-sections -fno-data-sections
-DWINPTHREAD_STATIC' --prefix=/mingw32tdm
--with-local-prefix=/mingw32tdm --with-pkgversion=tdm-1
--enable-sjlj-exceptions --with-bugurl=http://tdm-gcc.tdragon.net/bugs

You can run "gcc -v" yourself on MinGW official releases for comparison.

The pieces of the TDM configuration that are probably in opposition to
the accepted "MinGW standard" are:
* --enable-threads=posix (forces every user-generated binary to rely on
a pthreads compatibility library)
* --enable-fully-dynamic-string (breaks std::string compatibility with
binaries from other builds that don't use it)
* --disable-nls (disables error message translations and such)
* --enable-sjlj-exceptions (MinGW currently uses --disable-sjlj-exceptions)

> If you, or someone else, will produce MinGW-standard builds of the
> latest versions of GCC, and upload them to some place, I promise not
> to try to ;-)

My home-grown scripts don't jive with the mingw-get infrastructure all
that well. I would be willing to run a build with the non-canon stuff
tweaked out, if you or someone else was willing to do the back-end work
to integrate it and accept a TDM source archive (containing said
home-grown scripts and a minimal README - ex. [1]) as sufficient
documentation on how to reproduce the build.

That aside, best of luck!

-John E. / TDM

[1] -
http://sourceforge.net/projects/tdm-gcc/files/Sources/TDM%20Sources/gcc-4.9.2-tdmsrc-1.zip/download

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Building MinGW GCC

Eli Zaretskii
> Date: Fri, 05 Jun 2015 14:09:15 -0600
> From: "John E. / TDM" <[hidden email]>
>
> On 6/5/2015 1:13 PM, Eli Zaretskii wrote:
> > Thanks, this is useful, although most of it is pretty basic, as
> > building MinGW ports of any GNU software goes.  What I'm looking for
> > is some discussion of optional features and packages that GCC can be
> > built with or without.  Any chance of sharing those?
>
> Your best bet is probably to work from previous builds' configury
> command lines in conjunction with the GCC online documentation.

Does that documentation explain how to decide whether or not to build
with this or that optional feature/package?  Last time I looked, it
didn't, but maybe I overlooked something.

> Here is the configury command line (output from "gcc -v") for TDM-GCC
> 4.9.2, 32-bit edition. Every item is in there for a reason -- often a
> complicated reason.

Those reasons are precisely what I'm looking for.  Making the decision
which ones to use is by far the most time consuming job when building
any non-trivial package.  For example, in this case:

> Configured with: ../../../src/gcc-4.9.2/configure --build=mingw32
> --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp
> --enable-lto --enable-graphite --enable-libstdcxx-debug

Why --enable-graphite?

What capabilities does --enable-libstdcxx-debug gives you?

> --disable-win32-registry --disable-symvers

Why --disable-win32-registry?

> --enable-cxx-flags='-fno-function-sections -fno-data-sections

What are these about?

(You don't need to answer these questions, if you don't have time for
that.  I just wanted to demonstrate what are the issues for which I
asked for help and experience sharing.)

> You can run "gcc -v" yourself on MinGW official releases for comparison.

Of course, I can.  I just don't want to accept for granted the
decisions made by the person who did that port, without a clear
understanding what each option means.

> > If you, or someone else, will produce MinGW-standard builds of the
> > latest versions of GCC, and upload them to some place, I promise not
> > to try to ;-)
>
> My home-grown scripts don't jive with the mingw-get infrastructure all
> that well.

I don't care about mingw-get.  If I make the binaries, they will be
simple zip archives, like everything you see on the ezwinports site.

> That aside, best of luck!

Thanks, I know I'll need it.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Building MinGW GCC

John E. / TDM
On 6/5/2015 2:22 PM, Eli Zaretskii wrote:
> (You don't need to answer these questions, if you don't have time for
> that.  I just wanted to demonstrate what are the issues for which I
> asked for help and experience sharing.)
>
>> You can run "gcc -v" yourself on MinGW official releases for comparison.
> Of course, I can.  I just don't want to accept for granted the
> decisions made by the person who did that port, without a clear
> understanding what each option means.

Yeah - sadly I don't have the time to delve into the obscure reasons why
things were done a given way. Maybe someone else can; maybe you'll just
have to take it on faith to a certain extent.

-John E. / TDM

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Definition of struct timespec in MinGW runtime 3.21

Eli Zaretskii
In reply to this post by Eli Zaretskii
> Date: Fri, 05 Jun 2015 12:09:26 +0300
> From: Eli Zaretskii <[hidden email]>
> Cc: [hidden email]
>
> > Date: Fri, 05 Jun 2015 09:32:00 +0100
> > From: Keith Marshall <[hidden email]>
> >
> > On 20/01/15 16:47, Eli Zaretskii wrote:
> > >>>  . time.h does not include parts/time.h, although I think it was meant
> > >>>    to do so.
> >
> > My time for following up on this is still extremely limited, but I have
> > managed to get to some groundwork.  Is the attached patch sufficient to
> > address the "struct timespec" issue to your satisfaction?
>
> Thanks a lot, I will try this as soon as I can.  It will probably be a
> few days before I have an opportunity.

Tried it, and it looks good, thanks.  GDB builds without a hitch, and
so does Emacs.

I think this is good to go.  I hope to see it soon in a MinGW runtime
release near me.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Definition of struct timespec in MinGW runtime 3.21

Keith Marshall-3
On 07/06/15 16:39, Eli Zaretskii wrote:
>>> Is the attached patch sufficient to
>>> address the "struct timespec" issue to your satisfaction?
>>
>> Thanks a lot, I will try this as soon as I can.  It will probably be a
>> few days before I have an opportunity.
>
> Tried it, and it looks good, thanks.  GDB builds without a hitch, and
> so does Emacs.

Thanks for testing.

> I think this is good to go.  I hope to see it soon in a MinGW runtime
> release near me.

The packages are up on FRS now, at:
https://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/mingwrt-3.21.1/

I still need to find time to do the mingw-get integration; I'll hold off
on a formal release announcement until that's done.

--
Regards,
Keith.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Building MinGW GCC

David Gressett-6
In reply to this post by asmwarrior
Eli Zaretskii wrote:

>On a (slightly) related topic: since no one seems to volunteer to
>build newer versions of GCC for MinGW, I could try doing that myself
>(the binaries will then be made available from the ezwinports site).
>But I need some help figuring out the prerequisite support packages I
>need to build first, and the optional GCC features to enable/disable.
>Last time I built GCC on any OS was many years ago, and a lot has
>changed since then.

>Keith, I've looked at your script that you used for GCC 4.8.2, but
>there were too many issues there that I couldn't figure out by myself,
>which means I'd need a lot of wading through GCC docs and sources (and
>a lot of Googling), before I make up my mind on these issues.

>Therefore, an annotated list of GCC prerequisites and build options,
>together with issues to consider when deciding whether or not to
>enable/include them in the MinGW build, will be most appreciated.

>Please note that I intend to build GCC natively, using MSYS.

>(In case it's important, I already have the latest Binutils built for
>MinGW, and can build newer versions of them if needed; building
>Binutils for MinGW is easy. Btw, if there's enough demand, I can make
>MinGW 32-bit build of Binutils 2.25 available on ezwinports.)

>TIA to anyone who could share their experiences and advice on this.

I have successfully built a MinGW gcc 4.9.2 with only a few minor
tweaks to the build structure.  I reported the details on this list, but
that was back when 4.9.2 was just released. My build had a patch
for Ada to fix a bug in the Ada run-time library that only happens
when a 64-bit time_t is used.  This will not really be needed for a
build that uses the MinGW 3.21 runtime, but I am keeping in in my
builds in order to be ready for when a usable version of the MinGW
V4 appears. Here it is, gcc-4.9.2-mingw32.patch:

############################# This is a separator line, not part of the patch
--- gcc-4.9.1/gcc/ada/sysdep.c 2014-01-20 09:23:37 -0600
+++ gcc-4.9.1-patched/gcc/ada/sysdep.c 2014-09-10 09:41:36 -0500
@@ -68,6 +68,11 @@
 #include <time.h>
 #include <errno.h>
 
+#ifdef __MINGW32__
+#include <stdint.h>
+/* This may be useful for platforms other than Windows */
+#endif
+
 #if defined (sun) && defined (__SVR4) && !defined (__vxworks)
 /* The declaration is present in <time.h> but conditionalized
    on a couple of macros we don't define.  */
@@ -626,6 +631,11 @@
 
 #if defined (__MINGW32__)
 
+/* The size of the first argument of __gnat_localtime_tzoff must
+  match the size of the Ada type used by the calling routine. */
+
+typedef intptr_t ada_time_t;
+
 #ifdef CERT
 
 /* For the Cert run times on native Windows we use dummy functions
@@ -650,17 +660,21 @@
 /* Reentrant localtime for Windows. */
 
 extern void
-__gnat_localtime_tzoff (const time_t *, const int *, long *);
+__gnat_localtime_tzoff (const ada_time_t *, const int *, long *);
 
 static const unsigned long long w32_epoch_offset = 11644473600ULL;
 void
-__gnat_localtime_tzoff (const time_t *timer, const int *is_historic, long *off)
+__gnat_localtime_tzoff (const ada_time_t *ada_timer, const int *is_historic, long *off)
 {
+  time_t timer;
+  
   TIME_ZONE_INFORMATION tzi;
 
   BOOL  rtx_active;
   DWORD tzi_status;
 
+  timer = (time_t) *ada_timer;
+  
 #ifdef RTX
   rtx_active = 1;
 #else
@@ -707,7 +721,7 @@
     BOOL status;
 
     /* First convert unix time_t structure to windows FILETIME format.  */
-    utc_time.ull_time = ((unsigned long long) *timer + w32_epoch_offset)
+    utc_time.ull_time = ((unsigned long long) timer + w32_epoch_offset)
                         * 10000000ULL;
 
     /* If GetTimeZoneInformation does not return a value between 0 and 2 then

############################# This is a separator line, not part of the patch

Here is my package.ini. Not that I intended this to be contributed to the MinGW
project, so it does make some references to MinGW SourceForge things
that do not actually exist, but that won't keep you from using it. Note that
I have removed the - -with-mpc, --with-mpfr, and --with-gmp elements
from CONFOPT, which means that you have to have the mpc, mpfr, and
gmp libraries installed in your MinGW configuration. I did this because
the upstream gcc project has defined this as the recommended way to build
gcc, and I wanted to keep variations from such recommendations to a minimum:

##
# @file package.ini
# Copyright 2014 MinGW.org project
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice (including the next
# paragraph) shall be included in all copies or substantial portions of the
# Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# This file is part of MinGW Package Maker (mpmkr)
#
# This file is the configuration part of mpmkr and should be modified for your
# package.
#
# This file was modified for the gcc-4.9.2 released file and represents the
# configuration of the distributed binary release found at the project URL of
# http://sf.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.9.2-1/.

# This variable contains the name of the package, e.g. mingwrt.
PKG = gcc

# This variable contains the package version as is shown by the name of the
# package file.
PKGVER = 4.9.2

# This variable contains additional package name data, usually empty. E.G. the
# upstream pthreads-w32 package name is pthreads-w32-2-9-1-release, the PKGEXTRA
# variable is set as PKGEXTRA = -release.
PKGEXTRA =

# This variable gives the archive format for the upstream file name.
PKGEXT = tar.bz2

# This variable gives the URL to find the package name in order to download it
# if necessary.  The $(PKGFILE) is a target in the Makefile and its rules will
# use this variable to attempt to download the file.
PKGURL = http://ftp.gnu.org/gnu/gcc/$(PKG)-$(PKGVER)

# This is the version of the package we wish to provide in package naming.  This
# variable will usually match the $(PKGVER) variable but sometimes the upstream
# package name doesn't contain a consistent naming pattern and we can override
# it here.  E.G. The pthreads-w32 package PKGVER variable is 1-0-0 which is not
# consistent with the MinGW naming pattern so we set MPKGVER = 1.0.0 instead.
MPKGVER = $(PKGVER)

# Set this variable with the package release sequence number. E.G. If I have
# package foo-1.0.0 already delivered as foo-1.0.0-1-mingw32 and I want to
# correct a package issue I would set this to 2 so that the packages are created
# as foo-1.0.0-2-mingw32.
MPKGRLS = 1

# Set this variable for the file extension matching the compression you wish
# to give it.
MPKGEXT = tar.lzma

# Set this variable for the mingw-get package identifier.
MPKGRT = mingw32

# Set this variable with a list of files to add as patches.  The order of the
# list may be important.
#MPATCHES = gcc-4.9.2-mingw32.patch
MPATCHES =

# Set this variable for the options to the patch program.  It defaults to -p0.
MPATCHOPT =

# Set this variable to the final destination for installation.
PREFIX = /mingw

# Set this variable to the host environment "triplet" string.
HOST = mingw32

# Set this variable to the build environment "triplet" string.
BUILD = mingw32

# Set this variable with the options to the configure script.
CONFOPT = --prefix=$(PREFIX) --host=$(HOST) --build=$(BUILD) --with-arch=i586 --with-tune=generic --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs    --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s

# Set this variable with the files containing license you want copied to
# share/doc/$(PKG)/$(MPKGVER).  The list of files may contain sub-directories
# relative to the $(PACKAGE) directory.  E.G. Libiberty copied into packages
# like binutils and gcc has its own set of license files but libiberty
# is distributed with the base $(PACKAGE).  So include libiberty/COPYING.LIB to
# have it as part of the license file set.
#
core_LIC_FILES = COPYING COPYING.LIB COPYING.RUNTIME COPYING3 COPYING3.LIB gcc/COPYING gcc/COPYING.LIB gcc/COPYING3 gcc/COPYING3.LIB include/COPYING include/COPYING3 libiberty/COPYING.LIB libquadmath/COPYING.LIB libffi/LICENSE zlib/contrib/dotzlib/LICENSE_1_0.txt libsanitizer/LICENSE.TXT

# Set this variable with the files you want copied to
# share/doc/$(PKG)/$(MPKGVER).  The list of files may contain sub-directories
# relative to the $(PACKAGE) directory.  E.G. Libiberty copied into packages
# like binutils and gcc has its own set of documentation files but libiberty
# is distributed with the base $(PACKAGE).  So include libiberty/ChangeLog to
# have it as part of the documentation file set.
#
core_DOC_FILES = ABOUT-NLS ChangeLog* INSTALL/README LAST_UPDATED MAINTAINERS MD5SUMS NEWS README boehm-gc/ChangeLog* boehm-gc/doc/README.* boehm-gc/doc/barrett_diagram config/ChangeLog* contrib/ChangeLog* contrib/reghunt/ChangeLog* contrib/regression/ChangeLog* contrib/regression/README fixincludes/ChangeLog* fixincludes/README* gcc/ABOUT-GCC-NLS gcc/BASE-VER gcc/ChangeLog* gcc/DATESTAMP gcc/DEV-PHASE gcc/FSFChangeLog* gcc/LANGUAGES gcc/ONEWS gcc/README.Portability gcc/c/ChangeLog* gcc/c-family/ChangeLog* gcc/config/README gcc/cp/ChangeLog* gcc/cp/NEWS gcc/lto/ChangeLog* gcc/testsuite/ChangeLog* gcc/testsuite/README* include/ChangeLog* intl/ChangeLog* intl/README intl/VERSION libatomic/ChangeLog* libbacktrace/ChangeLog* libbacktrace/README libcpp/ChangeLog* libdecnumber/ChangeLog* libffi/ChangeLog* libffi/README libgcc/ChangeLog* libgomp/ChangeLog* libiberty/ChangeLog* libiberty/README libquadmath/ChangeLog* libssp/ChangeLog* libsanitizer/ChangeLog* libsanitizer/README.gcc libsanitizer/MERGE lto-plugin/ChangeLog* zlib/ChangeLog* zlib/FAQ zlib/INDEX zlib/README
ada_DOC_FILES = gcc/ada/ChangeLog* gnattools/ChangeLog* libada/ChangeLog*
fortran_DOC_FILES = gcc/fortran/ChangeLog* libgfortran/ChangeLog*
objc_DOC_FILES = gcc/objc/ChangeLog* gcc/objcp/ChangeLog* libobjc/ChangeLog* libobjc/README libobjc/THREADS
cpp_DOC_FILES = libstdc++-v3/ChangeLog* libstdc++-v3/README

core_HTML_FILES = boehm-gc/*.html INSTALL/*.html

core_INFO_FILES = cpp.info gcc.info cppinternals.info gcc.info gccinstall.info gccint.info libgomp.info libquadmath.info
ada_INFO_FILES = gnat-style.info gnat_rm.info gnat_ugn.info
fortran_INFO_FILES = gfortran.info

core_MAN_FILES = man1/cpp.1 man1/gcc.1 man1/gcov.1 man7/fsf-funding.7 man7/gfdl.7 man7/gpl.7
fortran_MAN_FILES = man1/gfortran.1
cpp_MAN_FILES = man1/g++.1

# If you want to copy the .exe files installed to $(PREFIX)/bin to also contain
# a $(HOST) prefix then set this variable to y or yes. E.G. If you want to copy
# bin/ld.exe to bin/$(HOST)-ld.exe then set this variable to y.
COPY_BIN_TO_HOST = y

# if you want to copy the include/, lib/ and libexec/ directories to a $(HOST)
# directory then set this variable to y or yes.  E.G. We need the mingwrt
# libraries in the $(HOST)/include and $(HOST)/lib to help with cross tooling so
# this variable is set to y.
COPY_LIB_TO_HOST = y


############################# This is a separator line, not part of package.ini


I have had no success building gcc 5.1.0. The MinGW 3.21 runtime
 introduced a new function which triggered a bug in the Fortran runtime
library.

Keith Marshall suggested a fix for this, but I have not had time to apply it;
 Going back to a previous V3 runtime would work around that problem,
but it would probably not work around another problem that occurs when
 the Ada 5.1.0 runtime is built. I did another build with Fortran disabled,
and the build dropped dead when compiling the Ada run-time library.
Most of that library is written in Ada, but there are a few bits in C. Tne
5.1.0 Ada team seems to have decided to move into the 64-bit world
and getting the build to work with 32-bit  MinGW will require undoing
the 64-bit patches. I have not yet had time to work through the details.

It might be worth your time to focus on fixing the MinGW V4 runtime.
I have been planning to transplant the V3.21 code into the V4 build
structure, but I have not had time to work on it.

------------------------------------------------------------------------------

_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

package.ini (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building MinGW GCC

Eli Zaretskii
> From: David Gressett <[hidden email]>
> Date: Mon, 8 Jun 2015 11:42:49 -0500
>
> Here is my package.ini.

Thanks a lot!

> I have removed the - -with-mpc, --with-mpfr, and --with-gmp elements
> from CONFOPT, which means that you have to have the mpc, mpfr, and
> gmp libraries installed in your MinGW configuration. I did this because

You mean, as opposed to having their sources in the GCC tree?

I see you use --enable-threads -- AFAIU this means libstdc++ will be
devoid of <thread> implementation, is that right?  Did you do this on
purpose, or just because previous MinGW compilers were built like
that?

> I have had no success building gcc 5.1.0. The MinGW 3.21 runtime
>  introduced a new function which triggered a bug in the Fortran runtime
> library.

Which function is that?

>  Going back to a previous V3 runtime would work around that problem,
> but it would probably not work around another problem that occurs when
>  the Ada 5.1.0 runtime is built.

Building Ada requires a previous version of Gnat to be installed,
doesn't it?

> It might be worth your time to focus on fixing the MinGW V4 runtime.

Sorry, I think MinGW runtime V4 is a dead end, because the
incompatible way it treated time_t makes it impossible to build
programs that run on old and new versions of Windows.

So I'm sticking with 3.21.1 for the time being, which has all the
niceties of v4, but none of the problems (now that Keith fixed the
last couple of them).

Thanks again for sharing your experience.

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
12