: 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
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
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 i
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 de
ty: 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 G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114
Keith Marshall changed:
What|Removed |Added
CC||keith.marshall at mailinator
dot c
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 t
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 i
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299
Keith Marshall changed:
What|Removed |Added
CC||keith.marshall at mailinator
dot c
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
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 t
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
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
librar
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 ; t
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 librarie
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
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&action=edit
Patch to create gnatlib import libraries for Win32
(In reply to Eric Botcazou from comment #14)
> In any case
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&action=edit
Make install-strip work for libobjc
FWIW, I've applied the attached patch, for the MinGW.org binary distributi
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.
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82626
Keith Marshall changed:
What|Removed |Added
CC||keith.marshall at mailinator
dot c
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,
__F
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, wh
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
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=36013&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936
--- Comment #2 from Keith Marshall ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936
--- Comment #5 from Keith Marshall ---
(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_IXUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936
--- Comment #6 from Keith Marshall ---
(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_IXUS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936
--- Comment #8 from Keith Marshall ---
(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 wer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936
--- Comment #10 from Keith Marshall ---
(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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720
Keith Marshall changed:
What|Removed |Added
CC||keith.marshall at mailinator
dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720
--- Comment #2 from Keith Marshall ---
Created attachment 36018
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36018&action=edit
Differences between "find staged" for each of "install-strip" and "install"
cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66936
--- Comment #18 from Keith Marshall ---
(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
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
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 c
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 assum
37 matches
Mail list logo
