[Bug jit/98586] libgccjit crashes with segmentation fault on failed gcc_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586 --- Comment #6 from Keith Marshall --- (In reply to David Malcolm from comment #5) > Should be fixed by the above commit. I applied your patch, and disabled (by changing "#ifdef _WIN32" to "#if 0") the effect of my own, so that the invalid assumption regarding Win32 DIR_SEPARATOR is not corrected. I now see: $ ./tut01-hello-world.exe internal compiler error: in make_tempdir_path_template, at jit/jit-tempdir.c:73 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. so all looks good, thanks. Just one residual irritation: after displaying this error message, in the console, MS-Windows pops up a dialogue box to tell me that the program has stopped working, and invites me to (pointlessly) forward an error report to Microsoft, before finally terminating the process. Just another annoying Windows feature, which I don't know how to circumvent, short of hacking the registry, and the control panel settings, to disable Windows error reporting altogether. BTW, you may wish to consider the patches, which I have attached to: https://osdn.net/projects/mingw/ticket/41070 They do help those building libgccjit for MS-Windows.
[Bug jit/98586] libgccjit crashes with segmentation fault on failed gcc_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586 --- Comment #2 from Keith Marshall --- (In reply to David Malcolm from comment #1) > I looked at calling diagnostic_initialize. > > Unfortunately, libgccjit supports being linked into multithreaded processes, > and it guards all of the regular compiler state with a single big mutex, > including the diagnostic subsystem (and the "global_dc" pointer implicitly > used by fancy_abort). This failure is happening before the mutex is > acquired. Indeed, yes. I actually patched the mutex acquisition/release code, to use a native MS-Windows critical section, in preference to the alien pthreads mutex: https://osdn.net/ticket/download.php?group_id=3917=41070_id=5791 I thought that, maybe, it was my modification which led to the crash; I was surprised to find that execution never reached my modified code. > I'm not sure yet what the best fix is. I don't know the GCC internals well enough, to advise on this, but I'm willing to assist with testing, in any way that I can. In the meantime, I've patched around the flawed assumption, which leads to the failing assertion, in the first place: https://osdn.net/ticket/download.php?group_id=3917=41070_id=5799 Thanks for your attention.
[Bug jit/98586] New: libgccjit crashes with segmentation fault on failed gcc_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98586 Bug ID: 98586 Summary: libgccjit crashes with segmentation fault on failed gcc_assert Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- In response to a feature request by Eli Zaretskii, with my follow-up as detailed at https://osdn.net/projects/mingw/ticket/41070, I have been evaluating the feasibility of providing a libgccjit.dll implementation for mingw32. Since GCC-9.2.0 is the most recent version, for which I have a successful build of GCC itself, my initial efforts have been focussed on a libgccjit implementation for that version. With a series of patches, as attached to the OSDN ticket, I have successfully compiled the shared library, as libgccjit-0.dll; I am even able to successfully compile, and link, the tut01-hello-world.c example from your own online manual, at https://gcc.gnu.org/onlinedocs/jit/intro/tutorial01.html. Unfortunately however, when attempting to run this program, it crashes with a segmentation fault, and no useful diagnostic message. I have traced the origin of the crash to a failing assertion, at line 54 in gcc/jit/jit-tempdir.c. The failure of the assertion, as explained in the OSDN ticket, is due to it testing an invalid assumption — on MS-Windows, both '/' and '\\' are valid directory name separator characters, but the assertion requires '/', whereas the libiberty.a choose_tmpdir() function returns a path containing, and ending with, only '\\'. While I can easily, and will, correct the invalid assumption, on which the assertion fails, that the failed assertion terminates in a segmentation fault, rather than a graceful termination, with an appropriate diagnostic message, indicates that there is a deeper seated underlying defect. The segmentation fault actually occurs in function pp_format(), from gcc/pretty-print.c, when it attempts to dereference a NULL pointer, passed as the printer member of the global_dc structure. I guess that this structure has not been initialized; perhaps a call to diagnostic_initialize() has been omitted, but I have no idea where to insert it.
[Bug libgomp/93471] GCC-9.2.0 libgomp configuration passes bogus mingw32 library search paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93471
--- Comment #4 from Keith Marshall ---
(In reply to Keith Marshall from comment #3)
> Although this initially manifests for libgomp, the actual source of the
> failure may lie elsewhere within the GCC build system. After placing
> libpthread.a into the ${top_builddir}/mingw32/winsup hierarchy, other
> components -- initially ada -- fail in identical circumstances, with
> identical -L path specs, except that it is -lws2_32 which cannot be found,
> unless it too is copied to the ${top_builddir}/mingw32/winsup hierarchy.
Interestingly, I can no longer reproduce this failure, w.r.t. -lws2_32. I
believe this to be the result of a local patch, which I've applied to Ada's
gsocket.h, to remove gratuitously introduced dependencies on getaddrinfo(),
getnameinfo(), and freeaddrinfo() functions, (which are unsupported in Windows
versions predating WinXP), replacing them with a MinGW emulation of Microsoft's
wspiapi.h fallback API, based on Microsoft's equivalent of a dlopen()/dlsym()
lookup, and so eliminating all direct link-time dependencies on -lws2_32, (even
though it remains specified in the linking command).
OTOH, the failure w.r.t. -lpthread remains consistently reproducible.
[Bug libgomp/93471] GCC-9.2.0 libgomp configuration passes bogus mingw32 library search paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93471
--- Comment #3 from Keith Marshall ---
(In reply to Jakub Jelinek from comment #2)
> No idea what to look for, don't have any Windows around,
Nor do I ... I encountered this, initially when building a --target=mingw32
cross-compiler, on an up-to-date Manjaro-Linux, on which the native GCC is
GCC-9.2.0.
> and grep doesn't find any winsup strings in libgomp. Nor am aware of any
> mingw32/cygwin etc. related changes in libgomp recently.
IIRC, winsup is an artefact of cygwin's build system, which of course should
not really be applicable for builds on a GNU/Linux host. If it helps, the
problem initially manifests when running the configure script for the libgomp
component: configure aborts, stating that "Pthreads is required to build
libgomp", and the failure is the result of a link test, which cannot find
-lpthread. Once I've placed libpthread.a into the
${top_builddir}/mingw32/winsup/mingw directory, configure succeeds, the build
proceeds, and interestingly, grep finds no references to -lpthread in my build
log, (but does find -pthread references, which presumably implies -lpthread).
Although this initially manifests for libgomp, the actual source of the failure
may lie elsewhere within the GCC build system. After placing libpthread.a into
the ${top_builddir}/mingw32/winsup hierarchy, other components -- initially ada
-- fail in identical circumstances, with identical -L path specs, except that
it is -lws2_32 which cannot be found, unless it to is copied to the
${top_builddir}/mingw32/winsup hierarchy.
The real issue here seems to be: where do these bogus -L
.../mingw32/winsup/mingw -L .../mingw32/winsup/w32api/lib references originate,
and how do we fix them to reflect the correctly installed paths for the windows
support libraries?
[Bug libgomp/93471] New: GCC-9.2.0 libgomp configuration passes bogus mingw32 library search paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93471
Bug ID: 93471
Summary: GCC-9.2.0 libgomp configuration passes bogus mingw32
library search paths
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: keith.marshall at mailinator dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Building GCC-9.2.0 for mingw32 target, initially as GNU/Linux hosted
cross-compiler, and subsequently using that cross-compiler to build
cross-native for Win32 deployment, both builds fail at libgomp configuration
step, because libpthread.a cannot be found ... in spite of it being available
at its correctly installed location, relative to the associated pthreads header
files, which are found.
Specifically, failure to find the library is because the GCC-9.2.0 build
system, which does pass valid -I search paths, passes two entirely bogus -L
search paths, and no valid -L path, to the linker; both -L paths which are
passed lie within the non-existent, and never created,
${top_builddir}/mingw32/winsup hierarchy.
I can kludge around this, by manually creating the
${top_builddir}/mingw32/winsup/mingw directory, and creating libpthread.a
within it, as a hard link to the properly installed library, (which in my build
case is /home/keith/mingw32/lib/pthread.a), but that's a hideous kludge, to
work around a failing of the build system itself. Furthermore, it does have to
be a hard link, or a physical copy ... logically I had hoped that creating
${top_builddir}/mingw32/winsup as a physical directory hierarchy, with mingw as
a symbolic link within that, as a reference to /home/keith/mingw32/lib, would
have been sufficient, but apparently it is not.
I've never encountered any such issue, building previous GCC versions back as
far as GCC-4.8.2, and through to GCC-8.2.0, so it appears that this is a newly
introduced build system defect, with GCC-9.x
[Bug libgomp/84393] New: "make install" omits gfortran modules, following cross-native build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84393 Bug ID: 84393 Summary: "make install" omits gfortran modules, following cross-native build Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com CC: jakub at gcc dot gnu.org Target Milestone: --- I've successfully built, and installed, GCC-6.3.0 as a GNU/Linux hosted cross compiler suite for the mingw32 target; the language set includes fortran, and libgomp is enabled. I then proceeded to use this cross compiler suite to create a cross native build, for deployment on the mingw32 host itself. When installing the cross compiler suite, "make install" has added the following eight files to my $CROSS_COMPILER_ROOT/lib/gcc/mingw32/6.3.0/finclude: omp_lib.f90 omp_lib.h omp_lib_kinds.mod omp_lib.mod openacc.f90 openacc_kinds.mod openacc_lib.h openacc.mod However, when staging the cross native build, "make install" neglects to install any of these files.
[Bug driver/84391] New: External specs file misinterpreted, unless read twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84391
Bug ID: 84391
Summary: External specs file misinterpreted, unless read twice
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: keith.marshall at mailinator dot com
Target Milestone: ---
I'm experimenting with a customised GCC specs file, to enable selection of
alternative runtime libraries for MinGW. I started by extracting the default
(built-in) specs:
$ mingw32-gcc -dumpspecs > lib/gcc/mingw32/6.3.0/specs
This causes mingw32-gcc to read its default specs from this file, ignoring the
built-in specs. So far, so good; all behaves as expected, (and as documented).
Adding the '-v' option confirms that the specs are now read from the external
file, and built-in specs are not used.
Next, I defined new specs strings, within my external specs file:
*msvcrt_id:
-D__MSVCRT_VERSION__=0x0
*msvcrt_version:
${msvcr*:$(msvcrt_id)%*0} $<msvcr*
and I prepended:
*cpp:
%(msvcrt_version) ...original cpp spec-string unchanged...
in place, to the original cpp spec-string, within the same specs file.
The intent is to interpret a custom '-msvcr90' option (say), to set the MinGW
specific '__MSVCRT_VERSION__' feature macro as appropriate for using
MSVCR90.DLL, rather than the MSVCRT.DLL default. However, if I specify it,
using natural invocation syntax, I see:
$ mingw32-gcc -E -dM -msvcr90 -xc /dev/null | grep MSVCRT
mingw32-gcc: error: unrecognized command line option '-msvcr90'
Conversely, if I adopt this alternative (unnatural) invocation syntax:
$ mingw32-gcc -specs=specs -E -dM -msvcr90 -xc /dev/null | grep MSVCRT
#define __MSVCRT_VERSION__ 0x0900
#define __MSVCRT__ 1
I see exactly the effect I am trying to achieve.
If I add the '-v' option to the former (failing) command, I see that my
external specs file is read once, (before any other output is produced); if I
add '-v' to the latter (successful) command, I see that my external specs file
is read twice, (again, before any other output is produced).
FWIW, I also see the expected behaviour if I augment the built-in specs, by
placing my customisations in an alternatively named auxiliary specs file, (say
mingw.specs), and invoke:
$ mingw32-gcc -specs=mingw.specs -E -dM -msvcr90 -xc /dev/null | grep MSVCRT
#define __MSVCRT_VERSION__ 0x0900
#define __MSVCRT__ 1
Unless I'm overlooking something, I guess this is a bug in the way GCC
processes an external specs file explicitly named as 'specs', when reading it
implicitly; it seems that it may be worked around by loading it explicitly,
(although this is certainly much less convenient).
[Bug target/82626] -msse and -mfpmath=sse Causes __FLT_EVAL_METHOD__ to be -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626 --- Comment #12 from Keith Marshall --- (In reply to Jakub Jelinek from comment #10) > While defining float_t to float and double_t to long double for -msse > -mfpmath=sse is a reasoanble choice, Actually, it is the correct choice, but... > you need to have some choice also for other reasons why __FLT_EVAL_METHOD__ > is > -1 (e.g. mixed sse+387). ...it would be a poor fit here, which is why FLT_EVAL_METHOD = -1 is completely the wrong configuration, in this case. The correct solution is to introduce an implementation-defined FLT_EVAL_METHOD, (say -2), to accommodate this case, (since it cannot be represented by the standard 0..2 range of values, but neither is it, by any stretch of the imagination, an indeterminate case). > glibc just provides both float_t and double_t being long double for all the > __FLT_EVAL_METHOD__ -1 cases. That's exactly what I propose to do, in MinGW; it is surely the most appropriate compromise for, e.g. sse+387. However, -1 is just plain *wrong* for -msse.
[Bug target/82626] -msse and -mfpmath=sse Causes __FLT_EVAL_METHOD__ to be -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626 --- Comment #11 from Keith Marshall --- (In reply to Jakub Jelinek from comment #8) > Indeed, this really is a mingw bug. Wrong! It is *both* a MinGW bug, *and* a GCC bug. The difference is that I am fully committed to fixing the MinGW bug, whereas you seem to want to sweep the GCC bug under the carpet. > "and for other values of FLT_EVAL_METHOD, they are > otherwise implementation-defined." > Being implementation-defined doesn't mean they aren't defined at all. That's correct; (and it's also why simply suppressing references to float_t and double_t in isn't the right thing to do). However, neither is defining __FLT_EVAL_METHOD__ as "indeterminate" the right thing -- the case in question most definitely isn't indeterminate. The right thing, in this case, is to exercise the licence granted by POSIX.1, (and by inference, by ISO-C), to specify an implementation-defined FLT_EVAL_METHOD, (POSIX.1-2008 stipulates that it should be less than -1), for which I can check in MinGW's , and typedef float_t and double_t accordingly: : # elif __FLT_EVAL_METHOD__ == -2 /* say */ typedef float float_t; typedef long double double_t; :
[Bug target/82626] -msse and -mfpmath=sse Causes __FLT_EVAL_METHOD__ to be -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626 --- Comment #6 from Keith Marshall --- (In reply to Jakub Jelinek from comment #5) > __FLT_EVAL_METHOD__ 0 can't be correct in that case, "all operations and > constants evaluate in the range and precision of the type used." does not > hold, __FLT_EVAL_METHOD__ -1 cannot be correct either: "the precision of floating point operations is indeterminable", so you force me to compromise on the typedefs for float_t and double_t, (and the only sane choice I can make is long double for both), yet you use methods of determinable precision for your implementation, (in terms of generated code, and in the case of which the double_t compromise is likely correct, but the float_t isn't). > but "all operations and constants evaluate in the range and precision of > long double." which is the requirement for 2 doesn't hold either - float > operations evaluate in the range and precision of that type (float), double > evaluates in the range and precision of long double. Exactly so, (and there is no standardised FLT_EVAL_METHOD to represent that case), but it is very much a determinate case, ergo __FLT_EVAL_METHOD__ -1 is just plain wrong! Correct would have been to exercise the licence granted by POSIX.1-2008, and to define an implementation specific value less than -1, whence I could then infer the proper (albeit non-standard combination of) type definitions for float_t and double_t. > float_t/double_t definitions aren't provided by GCC, but by the C library. > So, if they aren't defined properly in that case, it is up to glibc or mingw > or whatever else projects owns them. And therein lies your bug: if you've specified that float_t and double_t are of indeterminate precision, (and therefore -- by definition -- they themselves are undefinable), you have no right to gratuitously require their definitions in the C++ header.
[Bug target/82626] -msse and -mfpmath=sse Causes __FLT_EVAL_METHOD__ to be -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626 Keith Marshall changed: What|Removed |Added CC||keith.marshall at mailinator dot c ||om --- Comment #4 from Keith Marshall --- (In reply to Jakub Jelinek from comment #3) > (In reply to jos...@codesourcery.com from comment #2) > > I think a value of 0 should be correct with -mfpmath=sse. > > For -msse2 -mfpmath=sse sure, and that is what you get. > But for -mno-sse2 -msse -mfpmath=sse only float computations are done in > SSE, double is done in x87. If you're going to claim that argument, then your C++ header is broken, because you've just made the float_t and double_t data types indeterminate for -mfpmath=sse prior to SSE2, yet you unconditionally refer to both in "uses" clauses, (which requires typedefs from somewhere, yet you aren't providing them; if you expect me to provide them in MinGW -- which is where Danny Smith originally provided them, but he neglected the "indeterminate" case -- then I'm probably going to make both equivalent to X87 defaults -- i.e. 80-bit long double for both -- and you might just as well punt float to the X87 too. Thus, you've comprehensively broken support for pre-SSE2 -mfpmath=sse, from GCC-6 onwards). Sorry, but you can't have your cake, and eat it; one way or another, this is a regression from GCC-5, which (correctly IMO, and in full agreement with Joseph) set FLT_EVAL_METHOD to zero, for the OP's use case.
[Bug libobjc/54720] libobjc install-strip target not populated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 --- Comment #4 from Keith Marshall --- Created attachment 41468 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41468=edit Make install-strip work for libobjc FWIW, I've applied the attached patch, for the MinGW.org binary distribution of GCC-6.3.0
[Bug ada/80921] cross compiling fails to build Ada shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 --- Comment #15 from Keith Marshall --- Created attachment 41464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41464=edit Patch to create gnatlib import libraries for Win32 (In reply to Eric Botcazou from comment #14) > In any case, the Windows GNAT folks are happy with the current situation. Fair enough. FWIW, I've applied the attached (trivial) patch, for my MinGW.org build of GCC-6.3.0, so we do get the import libraries. Feel free to adopt it, or not, as you please. BTW, although I am now able to build the DLLs, install-strip does not strip the installed copies; should it?
[Bug ada/80921] cross compiling fails to build Ada shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 --- Comment #13 from Keith Marshall --- (In reply to Eric Botcazou from comment #7) > > With that in place, a clean configure and build does now produce: > > > > gcc/ada/rts/libgnarl-6.dll > > gcc/ada/rts/libgnat-6.dll > > > > but there are no accompanying import libraries, (as there are for other > > DLLs, produced for other languages in the GCC suite). Definitely an > > improvement, but perhaps not quite the entire solution. > > Thanks for the feedback. The Ada compiler doesn't use libtool to build its > library so that's as expected (and import libraries are obsolete these days). That's not strictly true; while they may not be essential, import libraries are, by no means, obsolete. The search order, for the Windows linker[1], is: libfoo.dll.a foo.dll.a libfoo.a foo.dll libfoo.dll So, unless the foo.dll (or libfoo.dll) is in a different path from libfoo.a, and that path is searched earlier that the conventional lib path, then -lfoo will always cause static linking, if libfoo.dll.a is not provided. Also, when the static library is libfoo.a, and the DLL is qualified by a version suffix, -lfoo will never find libfoo-N.dll; this entirely defeats the linker's -Bdynamic vs. -Bstatic selection for -lfoo. A further problem with your DLL only convention is that the linker search path (normally) isn't anywhere that a running application will expect to find its shared objects, so we end up installing multiple copies of the DLL, spread around the file system. MinGW convention is to provide libfoo.dll.a and libfoo.a, in the linker search path, with foo-N.dll (or libfoo-N.dll) in the runtime path. [1]: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html
[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 --- Comment #6 from Keith Marshall --- (In reply to Keith Marshall from comment #5) > ... a clean configure and build does now produce: > > gcc/ada/rts/libgnarl-6.dll > gcc/ada/rts/libgnat-6.dll > > but there are no accompanying import libraries, (as there are for other > DLLs, produced for other languages in the GCC suite). Definitely an > improvement, but perhaps not quite the entire solution. Looking in the build log, (i.e. output from 'make 2>&1 | tee build.log'), I now see the commands which create these DLLs; in both cases, they invoke: mingw32-gcc -shared -shared-libgcc ... which is correct, (although -static-libgcc may be safer); however, both commands also include the -Wl,-soname, linker option, which is wrong. AIUI, that option is applicable only for building ELF shared objects, but we are creating a PECOFF shared object; in this case, the preferred option would be the PECOFF linker's -Wl,--out-implib, option, (and we would typically omit the DLL version suffix), such that we would produce: gcc/ada/rts/libgnarl.dll.a gcc/ada/rts/libgnat.dll.a to accompany: gcc/ada/rts/libgnarl-6.dll gcc/ada/rts/libgnat-6.dll
[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921
--- Comment #5 from Keith Marshall ---
(In reply to Eric Botcazou from comment #3)
> Probably the FIXME in libada/configure.ac then:
>
> # Determine what to build for 'gnatlib'
> if test $build = $target \
>&& test ${enable_shared} = yes ; then
> # Note that build=target is almost certainly the wrong test; FIXME
> default_gnatlib_target="gnatlib-shared"
> else
> default_gnatlib_target="gnatlib-plain"
> fi
> AC_SUBST([default_gnatlib_target])
>
> No idea why this was put in the first place but the first test should go...
Thanks. That seems likely.
I have autoconf-2.69, not 2.64 (which your configuration requires), so I found
the corresponding fragment within libada/configure itself, and adjusted that:
# Determine what to build for 'gnatlib'
if test ${enable_shared} = yes ; then
default_gnatlib_target="gnatlib-shared"
else
default_gnatlib_target="gnatlib-plain"
fi
With that in place, a clean configure and build does now produce:
gcc/ada/rts/libgnarl-6.dll
gcc/ada/rts/libgnat-6.dll
but there are no accompanying import libraries, (as there are for other DLLs,
produced for other languages in the GCC suite). Definitely an improvement, but
perhaps not quite the entire solution.
[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 --- Comment #2 from Keith Marshall --- (In reply to Eric Botcazou from comment #1) > Look into the compilation log, there must be an error reported in this case. There is not. I see records of (successful) ar commands to build the static libraries, but no evidence at all of even any attempt to build shared; the build was configured with --enable-shared, and even explicit --enable-shared=libada makes no difference ... no shared Ada libraries are built, while shared libraries for C, C++, Fortran, ObjC, and other supporting components are.
[Bug ada/80921] New: Cross compiling for mingw32 target fails to build Ada shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921 Bug ID: 80921 Summary: Cross compiling for mingw32 target fails to build Ada shared libraries Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- Working on a GNU/Linux host, my goal is to deliver a crossed-native GCC build for deployment on MS-Windows32 hosts. Currently focussing on GCC-6.3.0, I have: 1) Bootstrapped and installed native Ada-enabled GCC-6.3.0, for the GNU/Linux host. 2) With (1) at start of $PATH, built and installed GNU/Linux hosted GCC-6.3.0 cross-comiler suite for the mingw32 target. 3) With (1) still at the start of $PATH, followed by (2), built and installed (into a local staging directory) GCC-6.3.0 suite for host = target = mingw32. All seems fine, except that libgnarl-6.dll, libgnarl.dll.a, libgnat-6.dll, and libgnat.dll.a are nowhere to be found, either in my build tree, or in my staged installation tree. A colleague, building natively on MS-Windows (a process which takes approximately six times longer that my cross-hosted build), with the same configuration, (except for the necessary build/host/target differences), confirms that these shared libraries and import libraries are created by his build. What might I be missing, to get these components delivered by the crossed-native build? I've observed the same omission from previous GCC-4.9.3 and GCC-5.3.0 crossed-native builds, and I like to see a resolution before I progress to any attempt to build GCC-7.x
[Bug ada/58299] Ada defines UNICODE and _UNICODE too late for __MINGW32__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299 --- Comment #3 from Keith Marshall --- (In reply to Eric Botcazou from comment #1) > Patches should be posted on the gcc-patches mailing-list. Huh? So you can blatantly ignore it there too? Not only is that completely asinine, it contradicts the hint on the "add attachment" link: "proposed *patch*, testcase, etc." Surely, it is much more logical to have patches attached to the problem report to which they relate?
[Bug libobjc/54720] libobjc install-strip target not populated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 --- Comment #3 from Keith Marshall --- And, more than 4 years later, this issue persists in GCC-6.3.0
[Bug ada/58299] Ada defines UNICODE and _UNICODE too late for __MINGW32__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299 Keith Marshall changed: What|Removed |Added CC||keith.marshall at mailinator dot c ||om --- Comment #2 from Keith Marshall --- Still broken in GCC-6.3, (and possibly later). The issue, of course, is that feature test macros, such as UNICODE and _UNICODE, are *supposed* to be defined *before any* header file -- or at least before any system header, or any private header which may incidentally include a system header -- is included; Ada's delegation of these defines, to the private header "mingw32.h", which is included after other private headers which themselves *do* include system headers, is a gross violation of, and non-conformity with, this fundamental (and universal) requirement.
[Bug libstdc++/79178] New: Configuration tests for ISO-C99 support use invalid standards compliance specs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79178 Bug ID: 79178 Summary: Configuration tests for ISO-C99 support use invalid standards compliance specs Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- When building for mingw32, libstdc++-v3 configure uses an inappropriate -std=... spec, when testing for availability of ISO-C99 feature support in , etc. In config.log I see (simplified): ./gcc/xgcc -std=c++98 ... conftest.cpp followed by a failing test for a bunch of functions which should be available when ISO-C99 is supported. mingw32 does support all of the functions tested, but requires an appropriate __STDC_VERSION__ [>= 199901L] or __cplusplus [>= 201103L] spec for the prototypes to be declared. Since the ISO-C++ standard didn't add support for e.g. strtoll() until C++11, it is inappropriate to test for its availability using a C++ compiler supporting only the earlier C++98; the test (naturally) fails, causing _GLIBCXX_USE_C99 to remain undefined in the resultant bits/c++config.h header, so breaking the resultant compiler behaviour under -std=c++11. A correct test would be to either compile (as C code) for -std=c99, or, if you must use C++, then the minimum required standard for a correct test would be -std=c++11; -std=c++98, which sets __cplusplus to only 199711L, is just plain wrong. For corresponding MinGW.org bug report, see https://sourceforge.net/p/mingw/bugs/2335/
[Bug libfortran/70311] libgfortran build dies on "implicit declaration of function strncasecmp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70311 --- Comment #5 from Keith Marshall --- For sake of completeness, I've also implemented a solution for the strnlen() issue, within MinGW.org's mingwrt code base.
[Bug libfortran/70311] libgfortran build dies on "implicit declaration of function strncasecmp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70311 --- Comment #2 from Keith Marshall --- (In reply to Dominique d'Humieres from comment #1) > Could some mingw32 guru assign this PR to her/himself? Well, I should have thought that the requirement to include to expose a prototype for strncasecmp() is more a POSIX.1 conformity issue, than specifically a MinGW issue; you appear to be relying on a non-conformity in glibc, which allows this prototype to be exposed by including . MinGW is simply stricter in this aspect of POSIX.1 conformity, so exposing a weakness in your code. It would be inappropriate for you to expect MinGW to become less POSIX.1 conformant, when the correct solution is for you to include the proper header files, at point of use. OTOH, the strnlen() issue is, perhaps, best addressed in MinGW; since the function isn't universally supported by all Windows versions, which MinGW aims to support, it is appropriate for MinGW to provide a suitable fall back.
[Bug other/70313] New: libssp/ssp.c should include wincrypt.h for mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70313 Bug ID: 70313 Summary: libssp/ssp.c should include wincrypt.h for mingw32 Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- When building for the mingw32 target, compilation fails with a "HCRYPTPROV does not name a type" error. HCRYPTPROV is typedef'd in , which is conspicuously missing from the _WIN32 specific #includes; (IIRC, it must follow #include , which is included, although its placement within the "#ifndef _PATH_TTY" conditional block may not be an entirely prudent choice).
[Bug libfortran/70311] New: libgfortran build dies on "implicit declaration of function strncasecmp"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70311 Bug ID: 70311 Summary: libgfortran build dies on "implicit declaration of function strncasecmp" Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- I've just succeeded in building GCC-5.3.0 as a GNU/Linux hosted cross-compiler for the mingw32 target. However, I did need to add: #include to each of the following libgfortran source files: libgfortran/intrinsics/selected_char_kind.c libgfortran/runtime/environ.c libgfortran/runtime/string.c This is required, because the prototype for the POSIX.1 strncasecmp() function is correctly declared in , which these three libgfortran sources do not include; (they do include , but that's a distinct header, with a different, ISO-C conforming purpose; in a strictly conforming POSIX.1 context, it does not declare strncasecmp(), and recent changes to the MinGW.org runtime headers have introduced this conformity requirement). In addition, I ran into an issue surrounding the implementation of the strnlen() function ... again an implicit declaration issue. For the mingw32 target, this issue is less clearly defined: the function is available on hosts from Windows-Vista onwards, (and the GCC configure script may detect it), but the prototype is not exposed in the headers for a default mingw32 build, (since the default aims to support earlier Windows versions). My work-around was: -#ifndef HAVE_STRNLEN +#if ! defined HAVE_STRNLEN || (defined _WIN32 && ! defined __CYGWIN__) so selecting the local replacement function in libgfortran/runtime/string.c; this may be a prudent configuration choice for _WIN32 in any case, since the build-time detection of strnlen(), may become invalid at run-time.
[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114 Keith Marshall changed: What|Removed |Added CC||keith.marshall at mailinator dot c ||om --- Comment #21 from Keith Marshall --- (In reply to ralpheng...@gmail.com from comment #13) > Also needs a small change in pthread.h to guard against including windows.h > > #if defined(PTW32_CONFIG_MINGW) && defined(__cplusplus) > > change to > > #if defined(PTW32_CONFIG_MINGW) && defined(PTW32_BUILD) && > defined(__cplusplus) Agreed, pthread.h from pthreads-win32 needs to change, (but that's hardly an issue of particular interest here). Personally, I would patch it much more aggressively: it should NEVER include windows.h, but it also incorporates a load of additional cruft which simply doesn't belong there. However, this isn't the place to discuss such issues; let's take them up on a MinGW.org, or a pthreads-win32, focussed mailing list.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #18 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to Francois-Xavier Coudert from comment #17) Given the history and reasons, I've committed the patch to restore build on mingw32. Marking as fixed on trunk. Thanks. Looks like a cleaner way to achieve the same effect as my own QD hack. Reverted mine, and applied this to my 4.9.3 tree; can confirm that it now builds successfully for mingw32, (as crossed-native build from GNU/Linux; still can't build 5.x, but that's an entirely different issue). I haven't written any Fortran code in near 15 years, and no longer run Windows myself anyway, so haven't tested usability; let's push it out there, and see if anyone in the MinGW.org community can identify any consequent problems.
[Bug libobjc/54720] libobjc install-strip target not populated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 --- Comment #2 from Keith Marshall keith.marshall at mailinator dot com --- Created attachment 36018 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36018action=edit Differences between find staged for each of install-strip and install cases.
[Bug libobjc/54720] libobjc install-strip target not populated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 Keith Marshall keith.marshall at mailinator dot com changed: What|Removed |Added CC||keith.marshall at mailinator dot c ||om --- Comment #1 from Keith Marshall keith.marshall at mailinator dot com --- This appears to afflict version 4.8.5 too. After successfully completing a crossed-native build for the mingw32 target, make prefix=`pwd`/staged install-strip omits all libraries, associated headers, and the associated dll for the libobjc component, whereas make prefix=`pwd`/staged install includes them. The difference in installed inventory, between execution of each of these commands is attached.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #10 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to Andrew Pinski from comment #9) Well it is a libgfortran bug yes. Which, being pedantic, makes it a GCC bug, because libgfortran is a component of GCC. What we could do add to io/unix.c: #if MINGW !defined(S_IRWXG) #define S_IRWXG 0 #endif #if MINGW !defined(S_IRWXO) #define S_IRWXO 0 #endif And that will allow it to work correctly. Conceptually, yes; you'd actually need to test on __MINGW32__, or maybe even more generically on _WIN32, rather than on (nonexistent) MINGW. However, that seems every bit as much of a kludge as my own work-around. Realistically, calling umask() in this context on native windows would seem to be completely redundant anyway; I can't see how it will actually achieve anything, since all it will do will be to reproduce the already existing state, at the time of the call.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #5 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #4) Update title. The code in question is #ifdef HAVE_UMASK /* Temporarily set the umask such that the file has 0600 permissions. */ mode_mask = umask (S_IXUSR | S_IRWXG | S_IRWXO); #endif MinGW appears to define HAVE_UMASK, but MinGW seems to lack a correctly written umask(3). MinGW inherits its umask() implementation from Microsoft, in the shape of whatever MSVCRT.DLL provides; (and yes, at one time Microsoft decided to rename their umask() implementation to _umask(), but MinGW has always mapped those renames back to their originals, for backwards compatibility). So, the bug is that you gratuitously assume that any umask() implementation should conform to POSIX, even when the platform is not POSIX. IF you aim to support non-POSIX platforms, (as you do with the mingw32 target), you must be prepared to handle non-POSIX implementations, such as this umask() -- _umask(), which is documented at https://msdn.microsoft.com/en-us/library/5axxx3be.aspx
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #6 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #4) Update title. The code in question is #ifdef HAVE_UMASK /* Temporarily set the umask such that the file has 0600 permissions. */ mode_mask = umask (S_IXUSR | S_IRWXG | S_IRWXO); #endif MinGW appears to define HAVE_UMASK, but MinGW seems to lack a correctly written umask(3). Just for the record: MinGW has had access to Microsoft's umask() implementation for a very long time; HAVE_UMASK has always been defined, when compiling the mingw32 builds of GCC. However, this particular block of code is encapsulated within an outer #ifdef HAVE_MKSTEMP block, and it is only recently that MinGW has provided an implementation of mkstemp(), (Microsoft do not offer one), which has caused HAVE_MKSTEMP to become defined, so exposing this (presumably long-standing) bug.
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #8 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #7) So add #define S_IRWXG 0 #define S_IRWXO 0 to the header file wherever mingw defines the available mask bits for umask(3). The bug is clearly in mingw were it gratuitously maps umask() to _umask() without properly adding the mappings for the mode_t argument bits of umask(3). Absolutely not! Those bits are utterly irrelevant for the windows (MinGW) platform; to add them would be do nothing more than create confusion. The mask bits for umask(), on the windows platform are S_IREAD | S_IWRITE; those are the only mask bits YOUR code should be passing to non-POSIX umask(5axxx3be.aspx). This is NOT a MinGW bug; it's a GCC bug, and that's where it should be fixed. Until you do fix it, I have my work-around, (which I'm perfectly willing to publish in MinGW forked source for GCC, prominently commented as a ghastly hack to circumvent a gross upstream GCC bug).
[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 --- Comment #2 from Keith Marshall keith.marshall at mailinator dot com --- (In reply to kargl from comment #1) The name of the language is Fortran. The language has been called Fortran since 1988 or so. It was always FORTRAN, in the days when I actually used the language, but how you choose to capitalize it, or not, is completely irrelevant. The correct fix would be to add test to configure to define HAVE_S_IRWXG and HAVE_S_IRWXO. Of course it would, but I'm not going to dirty my hands with your autoconf code; this is your bug, and that is definitively your responsibility. A better fix would be for MingW32 to conform to POSIX. No, it most definitely would not; that is never going to happen. MinGW is definitively aimed at Microsoft Windows compatibility. Windows is not POSIX, and nor is MinGW; nor will it ever be, nor will it even aspire to be. S_IRWXG and S_IRWXO have no place in the windows environment; it would be wrong for MinGW to define them, (even if an appropriate pseudo-definition were ever proposed), just as it is wrong for you to assume that availability of mkstemp() implies that they should be defined.
[Bug libfortran/66936] New: io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936 Bug ID: 66936 Summary: io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that mkstemp() is available Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: keith.marshall at mailinator dot com Target Milestone: --- Created attachment 36013 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36013action=edit Kludge to work around issue for mingw32 When building GCC, with FORTRAN language support, for mingw32 with the mingwrt-3.21+ runtime library from MinGW.org installed, the build fails in libgfortran/io/unix.c, because the tempfile_open() function gratuitously assumes that, if HAVE_MKSTEMP is defined, then it must invoke: mode_mask = umask (S_IXUSR | S_IRWXG | S_IRWXO); regardless of whether or not those access mode flags are defined. Of course, the assumption is invalid: while S_IXUSR may have some semblance of meaning on a windows host, and is defined, S_IRWXG and S_IRWXO are meaningless, and are not. Now, I can kludge around this, with the attached patch, but I suspect that it doesn't represent a true solution.
