Building gcc 4.8.3, 4.9.0 for MinGW

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

Building gcc 4.8.3, 4.9.0 for MinGW

David Gressett
I have been working on building  gcc 4.8.3 and 4.9.0. My starting place is the MinGW gcc source
code package for the 4.8.1-4 release: gcc-4.8.1-2-mingw32-src.tar.lzma

I constructed my working source code packages for both of these by downloading the upstream
gcc 4.8.3 and 4.9.0  source code packages. I made 4.8.3 and 4.9.0 MinGW source packages from
copies of the 4.8.1-4 packages by replacing the original gcc-4.8.1.tar.bz2 with the newer equivalents.

For 4.8.3, I checked all the files that were patched by MinGW patches in the 4.8.1-4 package. They were
unchanged in 4.8.3, so the 4.8.1 patches would easily apply. I did, however, add an additional patch
that fixes the Ada problem that I reported earlier.

FOR 4.9.0, I did no patches; my Ada patch will certainly be needed, as the Ada bug is still present in
4.9.0, but I do not intend to do any such patches until 4.9.0 is buildable without patches.

I then edited the package.ini file to match the version and patch structure for 4.8.3 and 4.9.0 and
started building.

The results in a nutshell: the 4.8.3 build succeeded, the 4.9.0 build failed.

In more detail:
For 4.8.3:

I scanned through the build log looking for warning diagnostics. I expect that most of these
could be ignored, but just on general principle, I looked for odd things, and I wanted to
establish a baseline for comparison with the 4.9.0 build.

There are numerous warnings for many different source files.
I only patched one file, so these were probably things that weren't a problem for 4.8.1-4,
and probably still won't be a problem for 4.8.3; there weren't a large number of changes
from 4.8.1 to 4.8.3.

There were a few implicit declaration of function warnings, variable set but not used warnings,
redeclared without dllimport attribute warnings, function declaration isn't a prototype
warnings, and implicit declaration of function warnings.

"ISO C++98 does not support the 'I64' ms_printf length modifier" appeared many times.
" may be used uninitialized in this function" was also frequent.

" left shift count >= width of type" struck me as a bit odd; likewise  "comparison of
unsigned expression < 0 is always false". These and several others were produced by compilation
of code in a directory named soft-fp. These might be platform-specific corner cases in code
designed for cross-platform used.

There were a number of warnings from adaint.c, which was  one of the files patched by a
MinGW local patch.

After the build completed it, I did a "make install" and tested it. I found one glitch very
quickly. I mostly use Ada for my Windows programming work, and use AdaGIDE as my
development environment. I found that command-line invocations of the Ada tools all
worked perfectly, but AdaGIDE had a problem: it could not tell when a GNATMake build
finished and would wait forever for it to finish. This is not a huge problem in itself, but
indicates a possible problem in the pipe mechanism that AdaGIDE uses to display the output
of GNATMake, which in turn might be a run-time library problem in the newly-built
GNATMake.  I will have to do more testing on this one.

For 4.9.0: Everything ran smoothly until the build reached the Ada run-time library.
 (Note that this build was made with gcc 4.8.1 before I installed 4.8.3) The offender
was gcc-4.9.0/gcc/ada/adaint.c. Numerous calls to Windows API functions produced
a torrent of warnings; most of these were identical to the ones in the 4.8.3 build which
produced no problems.  A fatal error terminated the build before the compiler reached
the end of adaint.c

After the 4.8.3 install I tried the 4.9.0 build again. It failed at the same place, but with
better error messages. Here is an example:

"error: cannot convert 'TCHAR* {aka wchar_t*}' to 'LPCSTR {aka const char*}'
 for argument '1' to 'UINT GetDriveTypeA(LPCSTR)"

This looks like a failure of the new mechanism for transparent handling of Unicode
that was introduced in the most recent version of the MinGW w32api. The problem must
be in the 4.9.0 adaint.c, as this worked in 4.8.3, and most of the code is the same.

Just to double-check, I backed up my MinGW directory, and downloaded and unpacked
the previous w32api and runtime files, overwriting the most recent stuff and built
4.9.0 again. This time, the build zipped right through adaint.c with no problems at all.
I didn't expect the build to succeed, as there were problably some other things that
I should have installed to be consistent with the older runtime and w32api, and in any
case, the 4.9.0  changes could have brought in any number of problems.
Sure enough, the build died later on after a spectacular shower of warning messages.
Many of these were griping about " unknown conversion type character 'l' in format";
sometimes the offending character was 'r' or 'R'. I'm not going to worry too much
about these at this point, as my focus will be on finding the adaint.c problem with the
latest runtime and win32 api code. It is , however, possible that some of these warnings
come from new demands that  4.9.0 makes on the C runtime library.  I haven't compared
the newer mingwex stuff with the older code, so I don't know if these 'l', 'R', and 'r'
conversion type problems are fixed in the newer code.

My next project for the 4.9.0 build is to shrink adaint.c into something small enough
to use as an investigative test for the win32 API problem.



------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck&#174;
Code Sight&#153; - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
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 gcc 4.8.3, 4.9.0 for MinGW

Keith Marshall
Hi David,

On 14/07/14 02:07, David Gressett wrote:
> I have been working on building  gcc 4.8.3 and 4.9.0. My starting
> place is the MinGW gcc source code package for the 4.8.1-4 release:
> gcc-4.8.1-2-mingw32-src.tar.lzma

It's refreshing to see someone who is willing to make a proactive effort
to progress this.  Thank you.

> I constructed my working source code packages for both of these by
> downloading the upstream gcc 4.8.3 and 4.9.0  source code packages. I
> made 4.8.3 and 4.9.0 MinGW source packages from copies of the 4.8.1-4
> packages by replacing the original gcc-4.8.1.tar.bz2 with the newer
> equivalents.
>
> For 4.8.3, I checked all the files that were patched by MinGW patches
> ...

Patches?  What patches?  Oh ... thanks for pointing out the blatant
untruth of this statement:
> "This distribution is created from pristine source without patches".

which appears right at the top of the README on the download site, (and
is reproduced within the source tarball to which you refer).  I took
that at face value, and didn't look for patches, which may explain why I
was unable to realize a working Ada build, for the gcc-4.8.2 release
which I prepared recently, (in spite of having achieved an apparently
Ada enabled linux-to-mingw32 cross-compiler, in preparation for the
subsequent crossed-native build process).

> I then edited the package.ini file ...

Hmm.  That method of distribution needs to disappear, very quickly.
Earnie foisted it upon us, with no consultation whatsoever; IMO, it is
every bit as disgusting as the mgwport rubbish he's trying to replace.
I'd like us to move towards a standard, based on my own mingw-pkg tool:
https://sourceforge.net/u/keithmarshall/mingw-pkg/ci/master/tree/

but not without an appropriate prior consultation process.

> The results in a nutshell: the 4.8.3 build succeeded, the 4.9.0 build
> failed.
>
> In more detail:
> ...

This may not be the most appropriate forum for detailed discussion; I'll
contact you privately, with a view to moving it, with your full
participation, to MinGW-Dvlpr.

--
Regards,
Keith.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck&#174;
Code Sight&#153; - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
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 gcc 4.8.3, 4.9.0 for MinGW

Keith Marshall
On 14/07/14 17:38, Keith Marshall wrote:

> Patches?  What patches?  Oh ... thanks for pointing out the blatant
> untruth of this statement:
>
>> "This distribution is created from pristine source without patches".
>
> which appears right at the top of the README on the download site, (and
> is reproduced within the source tarball to which you refer).  I took
> that at face value, and didn't look for patches, which may explain why I
> was unable to realize a working Ada build, for the gcc-4.8.2 release
> which I prepared recently, (in spite of having achieved an apparently
> Ada enabled linux-to-mingw32 cross-compiler, in preparation for the
> subsequent crossed-native build process).
Nope.  After applying the patches from gcc-4.8.1-4-mingw32-src.tar.lzma
to my gcc-4.8.2 source tree -- but excluding the undesirable config.sub
patch -- and also kludging around the float.h issue, my crossed-native
build still aborts after about 45 mins: (see attachment).  Since I have
no personal interest in Ada programming, and my knowledge of the Ada
language is exactly nil, I wouldn't know where to begin to debug this,
(although the use of adalib includes from the $build compiler tree,
rather than from the $host compiler tree, seems possibly suspicious).

BTW, the relocate.patch in gcc-4.8.1-4-mingw32-src.tar.lzma is corrupt;
it is encoded with CRLF line endings, where it should be LF only.

--
Regards,
Keith.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
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

gcc-4.8.2-mingw32.pkgspec (9K) Download Attachment
failure.msg (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building gcc 4.8.3, 4.9.0 for MinGW

David Gressett
In reply to this post by Keith Marshall
... snip ...

>This may not be the most appropriate forum for detailed discussion; I'll
>contact you privately, with a view to moving it, with your full
>participation, to MinGW-Dvlpr.

The private message finally arrived, delayed by an 18-hour Outlook server
outage.  My reply was rejected with this error message

Connected to mx.sourceforge.net:216.34.181.68 but recipient was rejected.
STARTTLS proto=TLSv1; cipher=AES256-SHA. Remote host said: 550 unknown user




------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
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