Building gcc 6.3 for MinGW

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Building gcc 6.3 for MinGW

David Gressett-5
Here is what I have done so far to get a working gcc 6.3

I have patched the isl library so that it will build with a dll for MinGW.
The patch is very simple. Undefined references don't work in Windows
and the patch gets rid of them.

----------------
diff -pNar -U 5 isl-0.16.1-current/Makefile.am isl-0.16.1-working/Makefile.am
--- isl-0.16.1-current/Makefile.am 2016-01-14 09:28:28 -0600
+++ isl-0.16.1-working/Makefile.am 2017-02-28 17:16:34 -0600
@@ -183,11 +183,11 @@ libisl_la_SOURCES = \
  isl_version.c \
  isl_vertices_private.h \
  isl_vertices.c \
  isl_yaml.h
 libisl_la_LIBADD = @MP_LIBS@
-libisl_la_LDFLAGS = -version-info @versioninfo@ \
+libisl_la_LDFLAGS = -version-info @versioninfo@ -no-undefined \
  @MP_LDFLAGS@
 
 isl_test_LDFLAGS = @MP_LDFLAGS@
 isl_test_LDADD = libisl.la @MP_LIBS@
 
diff -pNar -U 5 isl-0.16.1-current/Makefile.in isl-0.16.1-working/Makefile.in
--- isl-0.16.1-current/Makefile.in 2016-01-14 11:26:10 -0600
+++ isl-0.16.1-working/Makefile.in 2017-02-28 17:17:05 -0600
@@ -928,11 +928,11 @@ libisl_la_SOURCES = \
  isl_vertices_private.h \
  isl_vertices.c \
  isl_yaml.h
 
 libisl_la_LIBADD = @MP_LIBS@
-libisl_la_LDFLAGS = -version-info @versioninfo@ \
+libisl_la_LDFLAGS = -version-info @versioninfo@ -no-undefined \
  @MP_LDFLAGS@
 
 isl_test_LDFLAGS = @MP_LDFLAGS@
 isl_test_LDADD = libisl.la @MP_LIBS@
 isl_test_int_LDFLAGS = @MP_LDFLAGS@

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

I have done most of my builds without adding the gmp, mpc,
mpfr, and isl libraries to the gcc source tree. The gcc configure
is OK with linking to the libraries installed in MinGW and they all
work. I'm building gcc 6.3 frequently and doing this nips a bit
more than an hour off of the build time on my computer.

The versions of these that are installed by the MinGW installer
are not all the latest versions that are approved by the
upstream gcc team, but they work, so I not going to
work on newer versions until the gcc 6.3 project is complete.

Keith's released gcc 5.3 has six patches to the upstream gcc 5.3
source code. The equivalent gcc 6.3 source code has not changed
very much, and my build has six very nearly identical patches.
My efforts have produced three additional patches so far. It is
certainly possible that more are needed, but with this set of nine
patches gcc 6.3 will build successfully, and after installation
into the MinGW directory, replacing gcc 5.3, it will build itself
again.

A similar set of nine patches will also build gcc 5.3.0 and gcc 5.4.0.
(There is a Fortran run-time library bug fix in 6.3.0 which
could be back-ported to 5.3.0 and 5.4.0, but none of my patches
will do that.)

One of the patches is a result of searching my 5.3.0 build log
for problems. The logs contain an immense swarm of warnings
that can be ignored, which makes searching them for things that
should not be ignored a rather tedious business. I found two
warnings about undefined references in the build of the Fortran
run-time libraries.

These patches are certainly not entirely my own work - I have
analyzed what other builders have done, keeping firmly in
mind that it is necessary to carefully adhere to the requirements
of the Microsoft licenses that govern what can be done with
proprietary Microsoft information.

In any case, the gcc source files that need patching generally do
not come anywhere close being something that would require
that  a developer  go on a poaching expedition in Microsoft
header files.

I found one possible exception, which I rejected for two reasons.
It compiled with no problems, which meant that did not need
any poached header information, but it was also a fairly large blob
of code with no statement of origin. Since I do not know in detail
if there are ways other than header poaching to get in trouble
with Microsoft licensing, i did not use it. My other reason for
rejection was based on its functionality. The stated purpose of this
patch was to improve handling of symbolic links. For quite some
time, Windows has supported a very non-unixlike analogue of
symbolic links that only works for directories and not at all for
files, so it is worthless for emulation of Unix/Linus symbolic links.

Microsoft began to change that situation in Windows 8, with
the introduction of a new api function that could generate
symbolic links for both files and directories. It had a very
non-unixlike behaviour, however, because some usage
situations required that software using it be running with
administrator privileges. That situation still exists in Windows
10, but the administrator privilege restriction can be turned off
if the computer is set into developer mode. This struck me
as very interesting, but making effective use of it inside gcc
itself is definitely not going to be an immediate project, as
it will require a very detailed understanding of how gcc might use
such capabilities in its own structure, and I do not have that
knowledge, but that was another reason to reject the patch;
it was not up to date on what could be done with symbolic links.

I will not include here the changes that I made to the pkgspec
file; The simple changes are very obvious, and I do not know
how to make any that are not obvious - I do not  
yet know enough about mingw-pkg to make such changes;
 specifically, I know nothing abiut the mingw-pkg install action.

Here are my nine patches. As I did above with the isl patch,
I am delimiting them with a line of dashes.

01-mingw-w64-brain-damage.patch
----------------
diff -pNar -U 5 a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h
--- a/gcc/config/i386/mingw32.h 2016-04-08 08:47:37 -0500
+++ b/gcc/config/i386/mingw32.h 2017-02-16 16:41:42 -0600
@@ -157,22 +157,41 @@ along with GCC; see the file COPYING3.
    %{fvtable-verify=none:%s; \
     fvtable-verify=preinit:vtv_end.o%s; \
     fvtable-verify=std:vtv_end.o%s} \
   crtend.o%s"
 
-/* Override startfile prefix defaults.  */
+#if MINGW_W64_BRAIN_DAMAGE
+/* FIXME: override startfile prefix defaults; unconditionally disabled.
+
+   This may suit the mingw-w64 developers, but it seems to unnecessarily
+   restrict installation path choice; besides, the original defaults seem
+   to work just fine for me (KDM).  */
+
 #ifndef STANDARD_STARTFILE_PREFIX_1
 #define STANDARD_STARTFILE_PREFIX_1 "/mingw/lib/"
 #endif
 #ifndef STANDARD_STARTFILE_PREFIX_2
 #define STANDARD_STARTFILE_PREFIX_2 ""
 #endif
 
-/* For native mingw-version we need to take care that NATIVE_SYSTEM_HEADER_DIR
-   macro contains POSIX-style path.  See bug 52947.  */
+/* FIXME: work around bug 52947; unconditionally disabled, for now.
+
+   This gross hack works around an issue when building under MSYS:
+   for native mingw-version we need to ensure that NATIVE_SYSTEM_HEADER_DIR
+   is defined to represent a POSIX-style path.  Unfortunately, MSYS passes
+   the definition from the makefile, after translation to a fully device
+   qualified native windows absolute path; TARGET_SYSTEM_ROOT is passed
+   in similarly translated format, and the concatenation of the pair
+   becomes invalid as a path name.
+
+   The hack may suit mingw-w64 developers, but it's too restrictive for
+   general use, and may even produce bogus path references, such as
+   described by bug 56279.  */
+
 #undef NATIVE_SYSTEM_HEADER_DIR
 #define NATIVE_SYSTEM_HEADER_DIR "/mingw/include"
+#endif /* MINGW_W64_BRAIN_DAMAGE */
 
 /* Output STRING, a string representing a filename, to FILE.
    We canonicalize it to be in Unix format (backslashes are replaced
    forward slashes.  */
 #undef OUTPUT_QUOTED_STRING
-----------------------

02-mingw32-float.h.patch
-----------------------
diff -pNar -U 5 a/gcc/ginclude/float.h b/gcc/ginclude/float.h
--- a/gcc/ginclude/float.h 2016-01-29 04:03:26 -0600
+++ b/gcc/ginclude/float.h 2017-02-16 16:53:46 -0600
@@ -261,6 +261,16 @@ see the files COPYING3 and COPYING.RUNTI
 #undef DEC_EVAL_METHOD
 #define DEC_EVAL_METHOD __DEC_EVAL_METHOD__
 
 #endif /* __STDC_WANT_DEC_FP__ */
 
+#if defined (__MINGW32__) && ! defined (_MINGW_FLOAT_H_)
+/* MinGW.org's runtime libraries provide a supplementary float.h, which
+ * must also be included to complement this one.  Ideally that MinGW.org
+ * header should be included first, and it will include this one, but in
+ * a default configuration it doesn't normally happen this way; when we
+ * didn't see it first, include the MinGW.org header now!
+ */
+# include_next <float.h>
+#endif
+
 #endif /* _FLOAT_H___ */
-------------------------

03-ada-largefile.patch
-------------------------
diff -pNar -U 5 a/gcc/ada/adaint.c b/gcc/ada/adaint.c
--- a/gcc/ada/adaint.c 2016-01-17 12:07:39 -0600
+++ b/gcc/ada/adaint.c 2017-02-16 17:07:52 -0600
@@ -1328,20 +1328,20 @@ win32_filetime (HANDLE h)
   return (time_t) 0;
 }
 
 /* As above but starting from a FILETIME.  */
 static void
-f2t (const FILETIME *ft, __time64_t *t)
+f2t (const FILETIME *ft, GNAT_TIME_T *t)
 {
   union
   {
     FILETIME ft_time;
     unsigned long long ull_time;
   } t_write;
 
   t_write.ft_time = *ft;
-  *t = (__time64_t) (t_write.ull_time / 10000000ULL - w32_epoch_offset);
+  *t = (GNAT_TIME_T) (t_write.ull_time / 10000000ULL - w32_epoch_offset);
 }
 #endif
 
 /* Return a GNAT time stamp given a file name.  */
 
@@ -1350,11 +1350,11 @@ __gnat_file_time_name_attr (char* name,
 {
    if (attr->timestamp == (OS_Time)-2) {
 #if defined (_WIN32)
       BOOL res;
       WIN32_FILE_ATTRIBUTE_DATA fad;
-      __time64_t ret = -1;
+      GNAT_TIME_T ret = -1;
       TCHAR wname[GNAT_MAX_PATH_LEN];
       S2WSC (wname, name, GNAT_MAX_PATH_LEN);
 
       if ((res = GetFileAttributesEx (wname, GetFileExInfoStandard, &fad)))
  f2t (&fad.ftLastWriteTime, &ret);
diff -pNar -U 5 a/gcc/ada/adaint.h b/gcc/ada/adaint.h
--- a/gcc/ada/adaint.h 2015-05-30 16:23:24 -0500
+++ b/gcc/ada/adaint.h 2017-02-16 17:01:51 -0600
@@ -57,17 +57,27 @@ extern "C" {
 #define GNAT_STAT stat64
 #define GNAT_FSTAT fstat64
 #define GNAT_LSTAT lstat64
 #define GNAT_STRUCT_STAT struct stat64
 
-#elif defined(_WIN32)
+#elif defined(_WIN64)
 #define GNAT_FOPEN fopen64
 #define GNAT_OPEN open
 #define GNAT_STAT stat64
 #define GNAT_FSTAT fstat64
 #define GNAT_LSTAT lstat
 #define GNAT_STRUCT_STAT struct stat64
+#define GNAT_TIME_T __time64_t
+
+#elif defined(_WIN32)
+#define GNAT_FOPEN fopen64
+#define GNAT_OPEN open
+#define GNAT_STAT _stati64
+#define GNAT_FSTAT _fstati64
+#define GNAT_LSTAT _stati64
+#define GNAT_STRUCT_STAT struct _stati64
+#define GNAT_TIME_T time_t
 
 #else
 #define GNAT_FOPEN fopen
 #define GNAT_OPEN open
 #define GNAT_STAT stat
 diff -pNar -U 5 a/gcc/ada/cstreams.c b/gcc/ada/cstreams.c
--- a/gcc/ada/cstreams.c 2015-06-08 02:27:56 -0500
+++ b/gcc/ada/cstreams.c 2017-02-16 17:08:56 -0600
@@ -260,11 +260,11 @@ __gnat_full_name (char *nam, char *buffe
 #endif
 
   return buffer;
 }
 
-#ifdef _WIN32
+#ifdef _WIN64
   /* On Windows we want to use the fseek/fteel supporting large files. This
      issue is due to the fact that a long on Win64 is still a 32 bits value */
 __int64
 __gnat_ftell64 (FILE *stream)
 {
-----------------------

04-eh-frame-begin.patch
-----------------------
diff -pNar -U 5 a/libgcc/config/i386/cygming-crtbegin.c b/libgcc/config/i386/cygming-crtbegin.c
--- a/libgcc/config/i386/cygming-crtbegin.c 2016-01-04 08:30:50 -0600
+++ b/libgcc/config/i386/cygming-crtbegin.c 2017-02-16 17:13:11 -0600
@@ -92,11 +92,11 @@ _Jv_RegisterClasses (__attribute__((unus
 #endif
 
 /* Stick a label at the beginning of the frame unwind info so we can
    register/deregister it with the exception handling library code.  */
 #if DWARF2_UNWIND_INFO
-static EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[]
+EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[]
   __attribute__((used, section(__LIBGCC_EH_FRAME_SECTION_NAME__), aligned(4)))
   = { };
 
 static struct object obj;
----------------------------------

05-fortran-strings.patch
----------------------------------
diff -pNar -U 5 a/libgfortran/intrinsics/selected_char_kind.c b/libgfortran/intrinsics/selected_char_kind.c
--- a/libgfortran/intrinsics/selected_char_kind.c 2016-01-04 08:30:50 -0600
+++ b/libgfortran/intrinsics/selected_char_kind.c 2017-02-16 17:17:47 -0600
@@ -24,11 +24,11 @@ see the files COPYING3 and COPYING.RUNTI
 
 
 #include "libgfortran.h"
 
 #include <string.h>
-
+#include <strings.h>
 
 extern GFC_INTEGER_4 selected_char_kind (gfc_charlen_type, char *);
 export_proto(selected_char_kind);
 
 GFC_INTEGER_4
diff -pNar -U 5 a/libgfortran/runtime/environ.c b/libgfortran/runtime/environ.c
--- a/libgfortran/runtime/environ.c 2016-01-04 08:30:50 -0600
+++ b/libgfortran/runtime/environ.c 2017-02-16 17:18:57 -0600
@@ -23,10 +23,11 @@ see the files COPYING3 and COPYING.RUNTI
 <http://www.gnu.org/licenses/>.  */
 
 #include "libgfortran.h"
 
 #include <string.h>
+#include <strings.h>
 #include <stdlib.h>
 #include <ctype.h>
 
 #ifdef HAVE_UNISTD_H
 #include <unistd.h>
diff -pNar -U 5 a/libgfortran/runtime/string.c b/libgfortran/runtime/string.c
--- a/libgfortran/runtime/string.c 2016-01-04 08:30:50 -0600
+++ b/libgfortran/runtime/string.c 2017-02-16 17:19:47 -0600
@@ -22,10 +22,11 @@ a copy of the GCC Runtime Library Except
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 <http://www.gnu.org/licenses/>.  */
 
 #include "libgfortran.h"
 #include <string.h>
+#include <strings.h>
 #include <stdlib.h>
 
 
 /* Given a fortran string, return its length exclusive of the trailing
    spaces.  */
------------------------------------

06-ssp-wincrypt.patch
-----------------------------------
diff -pNar -U 5 a/libssp/ssp.c b/libssp/ssp.c
--- a/libssp/ssp.c 2016-02-09 13:16:30 -0600
+++ b/libssp/ssp.c 2017-02-16 17:22:09 -0600
@@ -63,10 +63,13 @@ see the files COPYING3 and COPYING.RUNTI
 #endif
 #endif
 #ifdef HAVE_SYSLOG_H
 # include <syslog.h>
 #endif
+#if defined (_WIN32) && !defined (__CYGWIN__)
+#include <wincrypt.h>
+#endif
 
 void *__stack_chk_guard = 0;
 
 static void __attribute__ ((constructor))
 __guard_setup (void)
-----------------------------------------

Next are the three additional patches.
The fist one is the only one that would not be easily
ported back to 5.3.0 or 5.4.0; the files involved
changed substantially in 6.3.0. I did, however, produce
a similar patch for 5.3.0 and 5.4.0

07-fortran-ldflags.patch
---------------------------------------
diff -pNar -U 5 a/libgfortran/Makefile.am b/libgfortran/Makefile.am
--- a/libgfortran/Makefile.am 2015-08-26 07:37:42 -0500
+++ b/libgfortran/Makefile.am 2017-02-16 17:24:15 -0600
@@ -43,11 +43,11 @@ libgfortran_la_LDFLAGS = -version-info `
 libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP)
 
 cafexeclib_LTLIBRARIES = libcaf_single.la
 cafexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
 libcaf_single_la_SOURCES = caf/single.c
-libcaf_single_la_LDFLAGS = -static
+libcaf_single_la_LDFLAGS = -static -no-undefined
 libcaf_single_la_DEPENDENCIES = caf/libcaf.h
 libcaf_single_la_LINK = $(LINK) $(libcaf_single_la_LDFLAGS)
 
 if IEEE_SUPPORT
 fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude
diff -pNar -U 5 a/libgfortran/Makefile.in b/libgfortran/Makefile.in
--- a/libgfortran/Makefile.in 2016-12-21 01:53:31 -0600
+++ b/libgfortran/Makefile.in 2017-02-16 17:29:59 -0600
@@ -604,11 +604,11 @@ libgfortran_la_LDFLAGS = -version-info `
 
 libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP)
 cafexeclib_LTLIBRARIES = libcaf_single.la
 cafexeclibdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)
 libcaf_single_la_SOURCES = caf/single.c
-libcaf_single_la_LDFLAGS = -static
+libcaf_single_la_LDFLAGS = -static -no-undefined
 libcaf_single_la_DEPENDENCIES = caf/libcaf.h
 libcaf_single_la_LINK = $(LINK) $(libcaf_single_la_LDFLAGS)
 @IEEE_SUPPORT_TRUE@fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude
 @IEEE_SUPPORT_TRUE@nodist_finclude_HEADERS = ieee_arithmetic.mod ieee_exceptions.mod ieee_features.mod
 AM_CPPFLAGS = -iquote$(srcdir)/io -I$(srcdir)/$(MULTISRCTOP)../gcc \
----------------------------------

08-ada-gnattools.patch
----------------------------------
diff -pNar -U 5 a/gnattools/Makefile.in b/gnattools/Makefile.in
--- a/gnattools/Makefile.in 2016-04-04 11:37:58 -0500
+++ b/gnattools/Makefile.in 2017-02-18 16:03:23 -0600
@@ -195,11 +195,11 @@ gnattools-native: $(GCC_DIR)/stamp-tools
  $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
   $(TOOLS_FLAGS_TO_PASS_NATIVE) \
   ../../gnatmake$(exeext) ../../gnatlink$(exeext)
  # gnattools2
  $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
-  $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools
+  $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools $(EXTRA_GNATTOOLS)
 
 # gnatmake/link can be built with recent gnatmake/link if they are available.
 # This is especially convenient for building cross tools or for rebuilding
 # the tools when the original bootstrap has already be done.
 regnattools: $(GCC_DIR)/stamp-gnatlib-rts
@@ -207,20 +207,20 @@ regnattools: $(GCC_DIR)/stamp-gnatlib-rt
  $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
   $(TOOLS_FLAGS_TO_PASS_RE) INCLUDES="" \
   gnatmake-re gnatlink-re
  # gnattools2
  $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
-  $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools
+  $(TOOLS_FLAGS_TO_PASS_NATIVE) common-tools $(EXTRA_GNATTOOLS)
 
 gnattools-cross: $(GCC_DIR)/stamp-tools
  # gnattools1-re
  $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
   $(TOOLS_FLAGS_TO_PASS_CROSS) INCLUDES="" \
   gnatmake-re gnatlink-re
  # gnattools2
  $(MAKE) -C $(GCC_DIR)/ada/tools -f ../Makefile \
-  $(TOOLS_FLAGS_TO_PASS_CROSS) common-tools
+  $(TOOLS_FLAGS_TO_PASS_CROSS) common-tools $(EXTRA_GNATTOOLS)
  # Rename cross tools to where the GCC makefile wants them when
  # installing.  FIXME: installation should be done elsewhere.
  if [ -f $(GCC_DIR)/gnatbind$(exeext) ] ; then \
   mv $(GCC_DIR)/gnatbind$(exeext) $(GCC_DIR)/gnatbind-cross$(exeext); \
  fi
---------------------------------

09-libiberty-lrealpath.patch
---------------------------------
diff -pNar -U 5 a/libiberty/lrealpath.c b/libiberty/lrealpath.c
--- a/libiberty/lrealpath.c 2005-05-24 15:48:25 -0500
+++ b/libiberty/lrealpath.c 2017-02-18 16:14:01 -0600
@@ -136,19 +136,30 @@ lrealpath (const char *filename)
      It also converts all forward slashes to back slashes.  */
 #if defined (_WIN32)
   {
     char buf[MAX_PATH];
     char* basename;
+ char* slash;
     DWORD len = GetFullPathName (filename, MAX_PATH, buf, &basename);
     if (len == 0 || len > MAX_PATH - 1)
       return strdup (filename);
     else
       {
- /* The file system is case-preserving but case-insensitive,
-   Canonicalize to lowercase, using the codepage associated
-   with the process locale.  */
-        CharLowerBuff (buf, len);
+ /* Turn all back slashes back back into forward slashes
+   and don't make it all lowercase.
+   Rationale:
+   Windows is as happy with / as it is with \. This will
+   have been built using Cygwin, MSYS* or cross-compiled
+   from a system where dirsep is / so it is cleaner just
+   to keep the dirseps as / (and the case un-modified).
+   This way, the value will be consistent with the build
+   system and string operations (be they internal to this
+   software or external to it, e.g. processing map files
+   with sed) work as expected.  */
+ slash = buf;
+ while ((slash = strchr(slash,'\\')) !=  NULL)
+  *slash = '/';
         return strdup (buf);
       }
   }
 #endif
 --------------------------------------------------



------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Building gcc 6.3 for MinGW

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/03/17 02:56, David Gressett wrote:
> Here is what I have done so far to get a working gcc 6.3

Many thanks for your work on this, David; it is much appreciated.

> I have patched the isl library so that it will build with a dll for
> MinGW. The patch is very simple. Undefined references don't work in
> Windows and the patch gets rid of them.

Strictly, it's an ugly kludge to work around a long-standing bug in
libtool: the '-no-undefined' option doesn't "get rid" of any undefined
references ... it just promises that you won't try to refer to any, in
the first place.  Without that promise, libtool is too inept to be
able to create windows DLLs ... a bug which has been present for ages,
and isn't likely to be fixed until developers recognize the reality:
'-no-undefined' *isn't* the solution; it's just an ugly work around
for a deeply entrenched bug.

> I have done most of my builds without adding the gmp, mpc,
> mpfr, and isl libraries to the gcc source tree. The gcc configure
> is OK with linking to the libraries installed in MinGW and they all
> work. I'm building gcc 6.3 frequently and doing this nips a bit
> more than an hour off of the build time on my computer.

That's fine.  I always build them "in-tree", but then, the *entire*
build process takes barely more than an hour for me, anyway.

> The versions of these that are installed by the MinGW installer
> are not all the latest versions that are approved by the
> upstream gcc team, but they work, so I not going to
> work on newer versions until the gcc 6.3 project is complete.

Again, understood, and absolutely fine.

> Keith's released gcc 5.3 has six patches to the upstream gcc 5.3
> source code. The equivalent gcc 6.3 source code has not changed
> very much, and my build has six very nearly identical patches.
> My efforts have produced three additional patches so far. It is
> certainly possible that more are needed, but with this set of nine
> patches gcc 6.3 will build successfully, and after installation
> into the MinGW directory, replacing gcc 5.3, it will build itself
> again.

That's promising.

> A similar set of nine patches will also build gcc 5.3.0 and gcc
> 5.4.0.  (There is a Fortran run-time library bug fix in 6.3.0 which
> could be back-ported to 5.3.0 and 5.4.0, but none of my patches will
> do that.)

Might be worth looking into.  Once I get mingwrt/w32api-5.0 out,
if you can point me in the right direction, I'll take a look.

> One of the patches is a result of searching my 5.3.0 build log for
> problems. The logs contain an immense swarm of warnings that can be
> ignored, which makes searching them for things that should not be
> ignored a rather tedious business.

Agreed.

> I found two warnings about undefined references in the build of the
> Fortran run-time libraries.

I must have missed those, among the noise.

> 05-fortran-strings.patch

Do we still need that?  I submitted a bunch of GCC bug reports, after
I built GCC-5.3.0; all have been ignored, except for one relating to
this, which I understood Fran├žois Coudert had fixed.

> I will not include here the changes that I made to the pkgspec file;
> The simple changes are very obvious, and I do not know how to make
> any that are not obvious - I do not yet know enough about mingw-pkg
> to make such changes; specifically, I know nothing abiut the
> mingw-pkg install action.

The 'mingw-pkg install' action, (unless the pkgspec file defines a
custom 'action_install()' function, which the GCC pkgspec doesn't),
does nothing more than:

  make $make_options ${install_options-"install-strip"}

which, given the pkgspec 'option install install' setting, becomes:

  make $make_options install

(and, on reflection, the '$make_options' shouldn't be there, because
they specify the compile-time settings; probably should be expressed
as '$compile_options', within mingw-pkg, leaving '$make_options' for
anything which should be passed to make, when performing any action).

As an aside, mingw-pkg isn't intended to supplant the conventional
'configure && make && make install' process; rather, it provides a
mechanism for automating the specification of options in each of the
sequential steps.  Unless pkgspec defines specific options, or a
custom action, for any step, invoking that step via mingw-pkg offers
no advantage over running the step directly, (and running a step
directly makes it easier to specify additional parameters which are
not defined in pkgspec).  Thus:

 - 'mingw-pkg patch' is convenient, to ensure a sequence of patches
   is applied, in the correct order.

 - 'mingw-pkg configure' is convenient, because pkgspec specifies a
   (long) list of options, which *should* be passed to 'configure'.

 - 'mingw-pkg compile' just invokes 'make $make_options'; since our
   pkgspec doesn't specify any '$make_options', this is equivalent
   to bare 'make', so it's more convenient to run 'make' directly,
   (with any additional parameters you wish; when we've identified
   any such parameters that are always required, we can specify them
   in pkgspec, to make 'mingw-pkg compile' more useful).

 - 'mingw-pkg install' invokes 'make install', as described above.
   Once again, it's usually more convenient (and flexible) to just
   invoke 'make install' directly.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYwB3DAAoJEMCtNsY0flo/PtkP/1/+iGRLHZ1/7ZdQcpF3QBbH
S8td+/KvC6Ki7VTmgs63ODRYiNy2acJWq9yR9MixSaogAKnDcaAyQcSVHVvdyQCl
2QPhdFqtJcMDwRFPDz1MCeD3FRpbwGPZquqyDWlGDdVgmkmLx16UMG7WqTaYpwT4
NTEPDuNWV/dBNtDAiwTm6CxJdhH3tUbMURa9I1GTKELlUpVA0NyFMN9NTyAOpNuJ
mynb1kngVIbmyWrYZeV9BaxEknbOFZ1Hwj63x3MkYMQZgJ0AZmUBI5O5HBnMIbUO
tfJBJhngDpuT8v2/ElSkGWVVQAlTmlB55LNj7wJlOrx6UTYMz5RghfyZn8nDraY8
UDk08DfNbmEaqQQmAEdkRg3TpCakfI2bxIJC6hCCJFpe4UsmQFelyWikIq87xi8B
9wRqlRKdsM9lY3fUR3ig0E00ajnWW92sBVzp3fGTx0cd+6Fh4eGwF5ApZ6gBqMoe
D9kHtwShWTb183cjn5E2x4KWO5D45yC0jHWVg1cTinAz09xkFiYT+n6j0puECOM0
b1D8OFi67i0S+8zZ+GlvA5tfzH7SKJiNclTunu1h1QashWWBngoFpDy3fgnukJzp
/l6mHByX+mQseIIWLGBpVAa2jJALkgN4mOYHC38tkIPO2UJQ6UTLZC3fZd7fxS8l
GxlSOTo2fY67SeQcrngZ
=aOsA
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
MinGW-dvlpr mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr
Loading...