Rebuilding GNAT for mingw (32bit)

Rebuilding GNAT for mingw (32bit)

[Jere]

So I recently ran into an issue using the FSF GNAT on 32bit mingw.  
It ended up having a bug in GNAT.Serial_Communications, which was 
fixed in later versions of GNAT found in 64 bit mingw.  Unfortunately 
I can't upgrade to the 64bit version and get a later version of GNAT.  
The bug fix was only a few lines, so I figured I could make the change 
to g-sercom.adb in the adainclude directory and hopefully recompile 
GNAT.  When I looked up instructions for this I found:

https://gcc.gnu.org/onlinedocs/gnat_ugn/Rebuilding-the-GNAT-Run-Time-Library.html

However, the GNAT installation for mingw did not have that makefile 
and libgnat.a wasn't in the locations specified by the gnatls -v 
command.  I did find libgnat.a, but what I don't know is how to 
recompile it.  Just using gnatmake outright generates a ton of .o 
and .ali files instead.  I'm not even sure which switches the runtime 
is normally compiled with for that platform.  Anyone have experience 
compiling it for mingw?  For reference, the GNAT version for mingw 
is currently 6.3.0.

Any help would be appreciated.

Re: Rebuilding GNAT for mingw (32bit)

[Brian Drummond]

On Thu, 28 Jun 2018 04:01:18 -0700, Jere wrote:

> So I recently ran into an issue using the FSF GNAT on 32bit mingw.
> It ended up having a bug in GNAT.Serial_Communications, which was fixed
> in later versions of GNAT found in 64 bit mingw.  Unfortunately I can't
> upgrade to the 64bit version and get a later version of GNAT.
> The bug fix was only a few lines, so I figured I could make the change
> to g-sercom.adb in the adainclude directory and hopefully recompile
> GNAT.  When I looked up instructions for this I found:
> 
> https://gcc.gnu.org/onlinedocs/gnat_ugn/Rebuilding-the-GNAT-Run-Time-
Library.html
> Any help would be appreciated.

In the event you can't find the correct answer, you can probably move 
forward by replacing g-sercom.ad[sb] with your own package derived from 
it, in your project and under your control.

I'm sure someone will jump in with comments if there are license 
implications to this approach.

-- Brian

Re: Rebuilding GNAT for mingw (32bit)

[Jeffrey R. Carter]

On 06/28/2018 01:01 PM, Jere wrote:
> So I recently ran into an issue using the FSF GNAT on 32bit mingw.
> It ended up having a bug in GNAT.Serial_Communications, which was
> fixed in later versions of GNAT found in 64 bit mingw.  Unfortunately
> I can't upgrade to the 64bit version and get a later version of GNAT.
> The bug fix was only a few lines, so I figured I could make the change
> to g-sercom.adb in the adainclude directory and hopefully recompile
> GNAT.  When I looked up instructions for this I found:

It looks to me as if you can change g-sercom.adb and recompile it without 
recompiling GNAT.

-- 
Jeff Carter
"How'd you like to hide the egg and gurgitate
a few saucers of mocha java?"
Never Give a Sucker an Even Break
101

Re: Rebuilding GNAT for mingw (32bit)

[Dan'l Miller]

On Thursday, June 28, 2018 at 6:13:14 AM UTC-5, Brian Drummond wrote:
> On Thu, 28 Jun 2018 04:01:18 -0700, Jere wrote:
> 
> > So I recently ran into an issue using the FSF GNAT on 32bit mingw.
> > It ended up having a bug in GNAT.Serial_Communications, which was fixed
> > in later versions of GNAT found in 64 bit mingw.  Unfortunately I can't
> > upgrade to the 64bit version and get a later version of GNAT.
> > The bug fix was only a few lines, so I figured I could make the change
> > to g-sercom.adb in the adainclude directory and hopefully recompile
> > GNAT.  When I looked up instructions for this I found:
> > 
> > https://gcc.gnu.org/onlinedocs/gnat_ugn/Rebuilding-the-GNAT-Run-Time-
> Library.html
> > Any help would be appreciated.
> 
> In the event you can't find the correct answer, you can probably move 
> forward by replacing g-sercom.ad[sb] with your own package derived from 
> it, in your project and under your control.
> 
> I'm sure someone will jump in with comments if there are license 
> implications to this approach.

If g-sercom.ad[sb] were copied from FSF GNAT (64-bit mingw) to FSF GNAT (32-bit mingw), then same license.  No harm, no foul.

If g-sercom.ad[sb] were copied from GNAT GPL Community Edition to FSF GNAT (by anyone other than an official FSF maintainer as normative representative of FSF itself), then the GPLv3's Runtime Exception would disappear henceforth in all of everything downstream from that now-full-fledged-GPLv3ed copy of FSF GNAT.

[I am not a lawyer who has passed the bar in any jurisdiction.  These observations are merely for my novelty purposes only, not to be relied upon by you.]

Re: Rebuilding GNAT for mingw (32bit)

[Jere]

On Thursday, June 28, 2018 at 7:13:14 AM UTC-4, Brian Drummond wrote:
> On Thu, 28 Jun 2018 04:01:18 -0700, Jere wrote:
> 
> > So I recently ran into an issue using the FSF GNAT on 32bit mingw.
> > It ended up having a bug in GNAT.Serial_Communications, which was fixed
> > in later versions of GNAT found in 64 bit mingw.  Unfortunately I can't
> > upgrade to the 64bit version and get a later version of GNAT.
> > The bug fix was only a few lines, so I figured I could make the change
> > to g-sercom.adb in the adainclude directory and hopefully recompile
> > GNAT.  When I looked up instructions for this I found:
> > 
> > https://gcc.gnu.org/onlinedocs/gnat_ugn/Rebuilding-the-GNAT-Run-Time-
> Library.html
> > Any help would be appreciated.
> 
> In the event you can't find the correct answer, you can probably move 
> forward by replacing g-sercom.ad[sb] with your own package derived from 
> it, in your project and under your control.
> 
> I'm sure someone will jump in with comments if there are license 
> implications to this approach.
> 
> -- Brian

I did that initially to verify that the bug fix would work.  
I was hoping for a more global solution though so I didn't have
to supply that file for every project that I had that used the
serial port.  I renamed it to just Serial_Communications, made
the bug fix, and tested it out.

Re: Rebuilding GNAT for mingw (32bit)

[Jere]

On Thursday, June 28, 2018 at 8:12:17 AM UTC-4, Jeffrey R. Carter wrote:
> On 06/28/2018 01:01 PM, Jere wrote:
> > So I recently ran into an issue using the FSF GNAT on 32bit mingw.
> > It ended up having a bug in GNAT.Serial_Communications, which was
> > fixed in later versions of GNAT found in 64 bit mingw.  Unfortunately
> > I can't upgrade to the 64bit version and get a later version of GNAT.
> > The bug fix was only a few lines, so I figured I could make the change
> > to g-sercom.adb in the adainclude directory and hopefully recompile
> > GNAT.  When I looked up instructions for this I found:
> 
> It looks to me as if you can change g-sercom.adb and recompile it without 
> recompiling GNAT.
> 
> -- 
> Jeff Carter
> "How'd you like to hide the egg and gurgitate
> a few saucers of mocha java?"
> Never Give a Sucker an Even Break
> 101

That was one of the first things I tried after verifying the fix.
It seems to want to pull the object code from somewhere else.  My
guess is the libgnat.a file.  I even tried compiling with -a to
force it to recompile the runtime libraries, but it only generated
a bunch of .o files and no libgnat.a file (in my project's local
object file directory).  That said, keeping the .o file in my
local directory seemed to work to override the RTS version.  I was
just hoping to make the change more permanent.

Re: Rebuilding GNAT for mingw (32bit)

[Jere]

On Thursday, June 28, 2018 at 2:19:41 PM UTC-4, Dan'l Miller wrote:
> On Thursday, June 28, 2018 at 6:13:14 AM UTC-5, Brian Drummond wrote:
> > On Thu, 28 Jun 2018 04:01:18 -0700, Jere wrote:
> > 
> > > So I recently ran into an issue using the FSF GNAT on 32bit mingw.
> > > It ended up having a bug in GNAT.Serial_Communications, which was fixed
> > > in later versions of GNAT found in 64 bit mingw.  Unfortunately I can't
> > > upgrade to the 64bit version and get a later version of GNAT.
> > > The bug fix was only a few lines, so I figured I could make the change
> > > to g-sercom.adb in the adainclude directory and hopefully recompile
> > > GNAT.  When I looked up instructions for this I found:
> > > 
> > > https://gcc.gnu.org/onlinedocs/gnat_ugn/Rebuilding-the-GNAT-Run-Time-
> > Library.html
> > > Any help would be appreciated.
> > 
> > In the event you can't find the correct answer, you can probably move 
> > forward by replacing g-sercom.ad[sb] with your own package derived from 
> > it, in your project and under your control.
> > 
> > I'm sure someone will jump in with comments if there are license 
> > implications to this approach.
> 
> If g-sercom.ad[sb] were copied from FSF GNAT (64-bit mingw) to FSF GNAT (32-bit mingw), then same license.  No harm, no foul.
> 
> If g-sercom.ad[sb] were copied from GNAT GPL Community Edition to FSF GNAT (by anyone other than an official FSF maintainer as normative representative of FSF itself), then the GPLv3's Runtime Exception would disappear henceforth in all of everything downstream from that now-full-fledged-GPLv3ed copy of FSF GNAT.
> 
> [I am not a lawyer who has passed the bar in any jurisdiction.  These observations are merely for my novelty purposes only, not to be relied upon by you.]

All work was done using FSF versions utilizing the special exception.

Re: Rebuilding GNAT for mingw (32bit)

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

> I'm not even sure which switches the runtime is normally compiled with
> for that platform.

You can tell by looking at the start of the .ali files
(e.g. system.ali). Though there are some additional switches for a few
files.

Re: Rebuilding GNAT for mingw (32bit)

[Brian Drummond]

On Thu, 28 Jun 2018 14:39:28 -0700, Jere wrote:

> On Thursday, June 28, 2018 at 7:13:14 AM UTC-4, Brian Drummond wrote:
>> On Thu, 28 Jun 2018 04:01:18 -0700, Jere wrote:

>> In the event you can't find the correct answer, you can probably move
>> forward by replacing g-sercom.ad[sb] with your own package derived from
>> it, in your project and under your control.
>> 
> 
> I did that initially to verify that the bug fix would work.
> I was hoping for a more global solution though so I didn't have to
> supply that file for every project that I had that used the serial port.
>  I renamed it to just Serial_Communications, made the bug fix, and
> tested it out.

I think it's probably better anyway - last time I looked, the stock 
version is not very flexible with a lot of hard-wired options that don't 
suit all applications. Keeping it under your control gives you 
flexibility you may need later anyway.

-- Brian