https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #15 from Brecht Sanders ---
So what is needed to be able to use gdc to build a simple "Hello world" program
for Windows (x86_64-w64-mingw32)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #13 from Brecht Sanders ---
I understand that would give me a gdc with runtime and no libphobos.
What is needed to make that usable as a compiler?
Do I need to build libphobos spearately or from a different source?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #11 from Brecht Sanders ---
Apparently MinGW-w64 dosn't like extern char** environ;
To avoid this issue for now I commented out the following in gcc/cp/module.cc:
extern char **environ;
while (const char *var = environ[vars.leng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #10 from Brecht Sanders ---
Looks like _pgmptr was superseded by _get_pgmptr().
So I tried this quick and dirty fix to get past the issue:
patch -ulbf libbacktrace/fileline.c << EOF
@@ -262,3 +262,7 @@
to the wine binar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #9 from Brecht Sanders
---
Same thing happens with --enable-languages=c,c++,fortran,d
What is causing the error: "undefined reference to `__imp___p__pgmptr'" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #8 from Brecht Sanders
---
Yes, that was with --languages=d only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #6 from Brecht Sanders
---
Sorry it took me a while to get the hang of building a canadian cross from
Linux.
When building gdc for Windows 64-bit I get the following:
make[2]: Entering directory
'/home/brecht/build-gcc/build_stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #5 from Brecht Sanders
---
Yes, it builds find with --with-libphobos-druntime-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #3 from Brecht Sanders
---
I was just trying to build GCC 12,13,14 with D+libphobos using GCC11.
No success.
GCC12:
libtool: compile: /R/winlibs_gcc1564/gcc-12.4.0/build_mingw/./gcc/gdc
-B/R/winlibs_gcc1564/gcc-12.4.0/build_min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
Bug ID: 118495
Summary: Unable to build gdc (D compiler) for MinGW-w64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
Brecht Sanders changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118283
--- Comment #4 from Brecht Sanders
---
Thanks for clarifying.
So it seems this is by design and there is nothing to fix in GCC.
Unfortunately that means a lot of packages will need to fix their source if
they still want them to build using th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118283
Bug ID: 118283
Summary: Issues when building with GCC15+MinGW-w64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
--- Comment #7 from Brecht Sanders
---
This somehow did allow the build to proceed:
make -Cbuild_mingw/$RUNPLATFORM/libstdc++-v3 LDFLAGS="-L$PWD/build_mingw/gcc
-lcommon"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
--- Comment #6 from Brecht Sanders
---
I tried building without '-D__USE_MINGW_ANSI_STDIO=0' and I still get the same
undefined references.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
--- Comment #5 from Brecht Sanders
---
The purpose of CFLAGS=-D__USE_MINGW_ANSI_STDIO=0 was to speed up console
output, because MinGW's own printf is quite slow.
I only want to speed up console output of GCC tools. Is there a better place to
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
--- Comment #2 from Brecht Sanders
---
../configure --prefix=/R/winlibs14.2.0msvcrt64/inst_gcc-14.2.0/share/gcc
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--enable-offload-targets=nvptx-none --with-pkgversion=MinGW-W64
x86_64-msvcrt-p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
Bug ID: 118244
Summary: Errors building libstdc++-v3 for MinGW-w64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118238
Bug ID: 118238
Summary: gcc/lto-wrapper.cc broken on Windows (MinGW-w64) due
to missing mkstemps() and link()
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116091
Bug ID: 116091
Summary: MinGW-w64 build not building plugin libraries
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
--- Comment #6 from Brecht Sanders
---
You're right. Sorry I missed that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
--- Comment #4 from Brecht Sanders
---
No, that patch wasn't added for my build, see my build recipe here:
https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/gcc.winlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
Brecht Sanders changed:
What|Removed |Added
CC||brechtsanders at users dot
sourcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #10 from Brecht Sanders ---
What is the status of GCC support for aarch64-w64-mingw32 ?
I just tried GCC 14 snapshot 20240414 and it looks like it's still not
supported.
Build fails with:
*** Configuration aarch64-w64-mingw32 not s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913
Brecht Sanders changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #5 from Brecht Sanders
---
Thanks Zac, how can I see what you actually changed?
Is there a particular GCC version I can diff
https://github.com/ZacWalk/gcc-woarm64 against?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #3 from Brecht Sanders
---
Any pointers on which files to edit in order to support aarch64-mingw ?
I think it won't require reinventing the wheel as it will probably be a mix of
existing *-mingw and aarch64-* stuff...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #2 from Brecht Sanders
---
I would love to give it a go if only I knew where to add the support.
I actually got a Windows on ARM device hoping I could figure it out, bit it
looks I will need tome help.
The "Unknown tune used in --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
Bug ID: 108678
Summary: Windows on ARM64 platform target aarch64-w64-mingw32
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #12 from Brecht Sanders ---
I couldn't apply that patch. Is that for 12.2.0 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #10 from Brecht Sanders ---
I can confirm GCC 12.2.0 builds fine with that patch and without CFLAG
-D__USE_MINGW_ACCESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858
--- Comment #8 from Brecht Sanders
---
I seem to be having some success after applying patches based on:
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0010-Fix-using-large-PCH.patch
https://github.com/msys2/MINGW-packages/bl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858
--- Comment #7 from Brecht Sanders
---
Any update on this?
This issue makes GCC12 really slow on Windows because PCH support doesn't work.
If mman-win32 support could be made to work it might solve this issue. The
problem is that this requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858
--- Comment #5 from Brecht Sanders
---
I believe this is issue is cause by the fact that mmap is missing on Windows.
In gcc/ggc-common.cc this causes use of default_gt_pch_get_address() as
HOST_HOOKS_GT_PCH_GET_ADDRESS which just returns NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858
--- Comment #4 from Brecht Sanders
---
Any update on this issue?
I see performance complaints from several people in GCC12+MinGW-w64 being much
slower in the build without precompiled headers (see:
https://github.com/brechtsanders/winlibs_ming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728
Brecht Sanders changed:
What|Removed |Added
CC||brechtsanders at users dot
sourcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858
--- Comment #3 from Brecht Sanders
---
Some information I received related to this issue:
On 01/08/2022 14:52, Luis Dallos wrote:
>
> PCH has had issues for as long as I can remember, see for example:
>
> *
> https://github.com/msys2/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858
--- Comment #2 from Brecht Sanders
---
Just checked, issue is still present in snapshot 12-20220723.
Anybody able to confirm the issue or know what the status is?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858
--- Comment #1 from Brecht Sanders
---
Any news on this?
I am not the only one experiencing this.
See also: https://github.com/brechtsanders/winlibs_mingw/issues/108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #7 from Brecht Sanders
---
Thank you for sharing your insights.
I can confirm building with CFLAGS="-D__USE_MINGW_ACCESS" works.
So I guess the question that remains is: Where is -D__USE_MINGW_ACCES missing
in the configuration of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858
Bug ID: 105858
Summary: MinGW-w64 64-bit build with --libstdcxx-pch: fatal
error: cannot write PCH file: required memory segment
unavailable
Product: gcc
Version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #5 from Brecht Sanders
---
Created attachment 53088
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53088&action=edit
Process Monitor when running `gcc -print-prog-name=cc1`
Process Monitor when running `gcc -print-prog-name=c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #4 from Brecht Sanders
---
I just ran `gcc -print-prog-name=cc1` and saw the output was only `cc1` while
on working versions it reports a full path to `cc1.exe` (e.g.
`d:/prog/winlibs64_stage/custombuilt/share/gcc/bin/../libexec/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #3 from Brecht Sanders
---
Created attachment 53046
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53046&action=edit
ProcessMonitor filtered on occurrence of "cc1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #2 from Brecht Sanders
---
I did an additional test to see where gcc.exe is looking for cc1.exe using
Process Monitor.
This was using a i686 UCRT build of GCC against MinGW-w64 installed under:
D:\Prog\winlibs32ucrt_stage\mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
--- Comment #1 from Brecht Sanders
---
Apparently this issue is not related to the .exe extension, but rather to where
it is looking for cc1.exe.
If somepath/bin is where gcc.exe lives than it helpst to add
somepath/libexec/gcc/x86_64-w64-ming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506
Bug ID: 105506
Summary: Error building GCC 12.1.0 against MinGW-w64: fatal
error: cannot execute 'cc1': CreateProcess: No such
file or directory
Product: gcc
Ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #7 from Brecht Sanders
---
I'm still trying to understand how it all works, but to avoid \n versus \r\n
issues on Windows I would already recommend these changes:
```
patch -ulbf gcc/go/gofrontend/gogo.cc << EOF
@@ -5252,3 +5252,3 @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #5 from Brecht Sanders
---
The generated internal/cpu.gox looks like the below dump. Can you see what the
issue is with the magic string?
```
: 6486 0100 5809 0200 d...X...
0010: 0500 2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #3 from Brecht Sanders
---
What exactly would be the file(s) being opened in this case?
When can we expect the libgo cleanup needed for MinGW(-w64) support?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
--- Comment #1 from Brecht Sanders
---
P.S.: This attempt was with snapshot version 12-20220417
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
Bug ID: 105302
Summary: gccgo for Windows using MinGW-w64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104659
Bug ID: 104659
Summary: msvcUsedUCRT in
libphobos/libdruntime/config/mingw/msvc.c
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104654
Bug ID: 104654
Summary: Errors in gthread.d when building against MinGW-w64
with --enable-threads=posix
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293
--- Comment #9 from Brecht Sanders
---
Any update on this?
Issue still exists today (in GCC 11.2.0 and in latest snapshot
11.2.1-20210814).
Both when building gcc on Windows for nvptx as well as the offload engine for
nvptx there is an error l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401
Brecht Sanders changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293
--- Comment #8 from Brecht Sanders
---
Additional test:
Running this manually (in MSYS2 shell) also fails:
R:/winlibs32_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/gcc/as
-v -m sm_35 -o 'R:\winlibs32_stage\_TMP_\ccYJWYIt.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293
--- Comment #7 from Brecht Sanders
---
I ran the following commands based on what was in config.log
cat > conftest.c << EOF
/* confdefs.h */
#define PACKAGE_NAME "GNU Atomic Library"
#define PACKAGE_TARNAME "libatomic"
#define PACKAGE_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293
--- Comment #6 from Brecht Sanders
---
Yes, that folder exists and that's where my TMP and TEMP environment variables
point to.
I also tried to point them to a folder on the C: drive, as R: is a RAM drive
and I wanted to exclude that that was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293
--- Comment #3 from Brecht Sanders
---
My bad, yes I was using nvptx-tools (master from
https://github.com/MentorEmbedded/nvptx-tools).
my configure command for nvptx offload engine looks like this
./configure --prefix=/R/winlibs64_stage/inst_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293
--- Comment #1 from Brecht Sanders
---
Also tried with unpatched binutils 2.36.1, same outcome.
Building GCC targetting nvptx (--target=nvptx-none) also stops with the same
error. libatomic/config.log reports:
configure:3756: checking whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293
Bug ID: 100293
Summary: MinGW-w64 of nvptx offload engine fails
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100160
Bug ID: 100160
Summary: MinGW-w64 g++ with libgomp and nvptx looks for
libgomp-plugin-nvptx.so.1 instead of
libgomp-plugin-nvptx-1.dll
Product: gcc
Version: 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100141
--- Comment #2 from Brecht Sanders
---
My plan was to build entirely without LLVM if possible, but if needed to just
build the offload accelerator I do have it available (though I need to check if
I have this target available).
What options are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100141
Bug ID: 100141
Summary: Unable to build amdgcn-amdhsa offload accelerator for
MinGW-w64 for both Windows 32-bit and 64-bit
Product: gcc
Version: 10.3.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913
--- Comment #3 from Brecht Sanders
---
Just to clarify: libwinpthread is built as part of the GCC build against
MinGW-w64.
MinGW-w64 also already has a libwinpthread (including libwinpthread-1.dll which
can be found in the PATH).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913
--- Comment #2 from Brecht Sanders
---
By the time I get to that error the build process already generated these
files:
- mingw-w64/mingw/lib/libwinpthread.a
- mingw-w64/mingw/lib/libwinpthread.dll.a
- mingw-w64/mingw/lib/libwinpthread.la
Howeve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913
Bug ID: 99913
Summary: GCC11 fails to build for MinGW-w64 for Windows 32-bit
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
--- Comment #10 from Brecht Sanders ---
I thought MinGW-w64 is it's own C library.
It is found by GCC build process because the folder mingw exists in the
location specified with --with-build-sysroot
CppRuntime_Gcc is mentioned in the predefs, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
--- Comment #8 from Brecht Sanders
---
predefs GNU D_Version2 LittleEndian GNU_SEH_Exceptions GNU_EMUTLS
GNU_StackGrowsDown GNU_InlineAsm D_LP64 D_PIC assert D_ModuleInfo D_Exceptions
D_TypeInfo all X86_64 D_HardFloat Windows MinGW Win64 CppRu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
--- Comment #6 from Brecht Sanders
---
The patch for gcc/config/i386/t-cygming added a line:
winnt-d.o: config/winnt-d.c
I changed it to:
winnt-d.o: config/i386/winnt-d.c
Then I got one step further.
Output is now:
libtool: compile: /R/winlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
Brecht Sanders changed:
What|Removed |Added
CC||brechtsanders at users dot
sourcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401
--- Comment #5 from Brecht Sanders
---
*** Bug 97618 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618
Brecht Sanders changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401
--- Comment #2 from Brecht Sanders
---
Created attachment 50302
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50302&action=edit
gcc -v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401
Bug ID: 99401
Summary: GCC11 MinGW-w64 32-bit build fails with undefined
reference to `LC0'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618
--- Comment #4 from Brecht Sanders
---
Found a smaller project to reproduce the issue with: building BLAKE3 v0.3.7
from
https://github.com/BLAKE3-team/BLAKE3 also has the issue when building with
GCC11 for 32-bit MinGW-w64.
Here I noticed that c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618
--- Comment #3 from Brecht Sanders
---
Issue is till present in GCC 11 snapshot 20210131.
When building GCC 11 with GCC 11 the error is still there when trying to build
fortran.
I also noticed the same error when using GCC 11 to build ccache 4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #27 from Brecht Sanders ---
@Mikael Pettersson, should a similar patch be applied to
gcc/config/i386/mingw-w64.h to fix this same issue in MinGW-w64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
--- Comment #11 from Brecht Sanders ---
Created attachment 50113
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50113&action=edit
objdump -h
List of sections attached (created using `objdump -h`)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
--- Comment #9 from Brecht Sanders
---
The attached .exe will run on Windows after removing the section called `/20`
from the PE file using: `strip conftest.exe --remove-section="/20"`
I don't know what this section does, but I did notice it co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
--- Comment #8 from Brecht Sanders
---
Also, my win64 build uses SEH, not dwarf, so it doesn't look like dwarf is the
issue. I also tried to build with `--enable-compressed-debug-sections=none`,
but that fix the problem either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
--- Comment #7 from Brecht Sanders
---
Adding flag `-gdwarf-4` to the above command still results in a file that won't
execute, see attached file `conftest-gdwarf-4.exe`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
--- Comment #6 from Brecht Sanders
---
Created attachment 50004
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50004&action=edit
test built with -gdwarf-4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
--- Comment #3 from Brecht Sanders
---
Strange, I'm using the same binutils to build GCC 10.2.0 and have no issues
there.
Configuring the GCC build with `LDFLAGS_FOR_TARGET="-s"` works around this
issue for now, but only for win64. For the win3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
--- Comment #1 from Brecht Sanders
---
I have discovered that adding `-s` to the above build command or stripping the
.exe file with `strip` does allow it to run. So probably something is messed up
in the debugging symbols section.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
Bug ID: 98729
Summary: GCC 11 MinGW Windows build doesn't generate working PE
executables
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
--- Comment #3 from Brecht Sanders
---
Fixing gcc/config/nvptx/mkoffload.c got me one step further, but now the
parameters seem to be the issue:
lto1.exe: error: unrecognized command-line option '-mgomp'
lto1.exe: error: '-foffload-abi' option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
--- Comment #2 from Brecht Sanders
---
Did a bit more digging...
Seems COMPILER_PATH uses ';' as separator on Windows, not ':'.
So besides the .exe issue parse_env_var() also needs to separate the list by a
different separator.
Something like t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
--- Comment #1 from Brecht Sanders
---
Closer investigation shows the issue probably not (or not only) cause by the
.exe extension:
This is the error:
lto-wrapper.exe: fatal error: could not find accel/nvptx-none/mkoffload.exe in
d:/prog/winlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
Bug ID: 98145
Summary: On Windows .exe extension is missing when
searching/calling mkoffload
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618
--- Comment #2 from Brecht Sanders
---
To build mpfr wich fails with:
build_mingw\i686-w64-mingw32\libgcc/../../../libgcc/config/libbid/bid128_div.c:1523:
undefined reference to `LC4'
I figured out that the symbol LC4 is defined in libgcc.a, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618
--- Comment #1 from Brecht Sanders
---
I see a similar issue when building mpfr with the resulting compiler, but here
the error is:
build_mingw\i686-w64-mingw32\libgcc/../../../libgcc/config/libbid/bid128_div.c:616:
undefined reference to `LC4'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618
Bug ID: 97618
Summary: undefined reference to LC11 building for target
MinGW-w64 32-bit
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97614
Bug ID: 97614
Summary: MinGW-w64 pointer to long conversion loses precision
error
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484
Brecht Sanders changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484
--- Comment #3 from Brecht Sanders
---
MinGW is pure C, so it doesn't use: using namespace std;
But I do see Ninja doing this before including windows.h.
However GCC 10 and older have no issue with this.
What changed in GCC 11 to cause the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484
Bug ID: 97484
Summary: typedef conflict for "byte" in GCC11 for MinGW-w64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
98 matches
Mail list logo
