[Bug bootstrap/52947] [4.7/4.8 Regression] bootstrap fails due to wrong include search path composition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52947 --- Comment #4 from ralphengels at gmail dot com 2012-05-13 15:15:10 UTC --- Adding --disable-build-poststage1-with-cxx \ --disable-build-with-cxx \ allows the full bootstrap on windows with mingw64. Something is broken with C++ though as anything that links to libstdc++ will crash with the executable has stopped working error (exceptions ?). I hope my findings can shed some light on this.
[Bug bootstrap/52947] [4.7/4.8 Regression] bootstrap fails due to wrong include search path composition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52947 ralpheng...@gmail.com changed: What|Removed |Added CC||ralphengels at gmail dot ||com --- Comment #3 from ralphengels at gmail dot com 2012-04-21 09:39:19 UTC --- Just chiming in. Im also running into this problem in stage2 where it fails to find stdarg.h. As an experiment i tried reverting kai's work but it still fails to find system headers. A non bootstrap build works but im having problems with programs using libstdc++. All programs compiled that depends on libstdc++ will crash with initialization error 0xc05. My machine is Win7 64. All previous gcc versions build fine btw. And work also. I have tried with versions compiled by other parts and the problem persists.
[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114 --- Comment #20 from ralphengels at gmail dot com --- Clarification. If not using pthreads-w32 #ifdef PTW32_VERSION // See libstdc++/67114 # define _GLIBCXX_THREAD_ID_LESS(X, Y) ((X).x < (Y).x) <- this #endif would end up undefined if say we build with winpthreads. As you noticed yourself os_defines.h gets pulled in after gthr.h so it fails, my suggestion if using a macro would be to put it in gthr_posix.h instead. My reason for this suggestion is that gthr_posix.h gets linked to gthr.h when building with posix threads and is visible to all parts of the code. My patch was made for the mingw.org compiler, since they still use pthreads-w32. Hope this clears it up, i was a little tired at the time of writing my last reply.
[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114 ralphengels at gmail dot com changed: What|Removed |Added Attachment #38009|0 |1 is obsolete|| --- Comment #14 from ralphengels at gmail dot com --- Created attachment 38010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38010&action=edit Whopsie Uploaded an older version by mistake, here is the correct one.
[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114 --- Comment #22 from ralphengels at gmail dot com --- Aye the pthreads specific fixes needs to be taken care of upstream. The comment was just to let people know that the gcc changes are not enough. Ill try and get a hold on the current maintainer for pthreads-w32, the repository is sadly read only so i cannot submit patches via git.
[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114 ralphengels at gmail dot com changed: What|Removed |Added CC||ralphengels at gmail dot com --- Comment #12 from ralphengels at gmail dot com --- Created attachment 38009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38009&action=edit pthreads-w32 compatibility patch Patch to allow building gcc-5.3.0 with pthreads-w32, no bugs so far but im still running the testsuite so something might turn up, feel free to test.
[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114 --- Comment #19 from ralphengels at gmail dot com --- Had problems with the define not being pulled in from os_defines.h (i think a better place would have been gthr_posix.h since that gets pulled in at build time) hence the change, also if using another posix thread implementation it would break using that instead since your define would then be undefined leading to a build error. Besides that better implementations are welcome :) this was just an example of a possible fix.
[Bug libstdc++/67114] [MinGW64] build failure with POSIX threads enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114 --- Comment #13 from ralphengels at gmail dot com --- 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)
[Bug c++/71298] New: changes to libstdc++ breaks windows builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71298 Bug ID: 71298 Summary: changes to libstdc++ breaks windows builds Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ralphengels at gmail dot com Target Milestone: --- gcc-6.1.0 libstdc++ cannot find stdlib.h on mingw-w64. the change seems to have been cstdlib where the include was changed to include_next.
[Bug libstdc++/71298] changes to libstdc++ breaks windows builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71298 --- Comment #3 from ralphengels at gmail dot com --- Sorry for the delay, yes its a duplicate of the same bug you linked to. The msys2 devs have found a way to get around it which does not include patching, but i thought it best to report it anyway in case it breaks other archs.
[Bug preprocessor/48677] New: cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 Summary: cpp.exe broken ? Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: ralpheng...@gmail.com hello im not sure if it has happened to others but im running head first into something really annoying with the new gcc-4.6.0 package. i maintain two packages for i686-w64-mingw32 and x86_64-w64-mingw32. latest version i build was 4.5.2 and it works flawlessly but i was kinda looking forward to the new version with plugin support for mingw. unfortunatly it seems something broke with the changes causing cpp.exe to crash when executed (i686-w64-mingw32) a quick run through gdb points to lbasename.c in this section /* Skip over a possible disk name. */ if (ISALPHA(name[0]) && name[1] == ':') // crashes here name += 2; the x86_64-w64-mingw32 builds cpp.exe doesnt crash but outputs nothing. i noticed a lot of changes in the libiberty code so maybe a bug ? heres the commands i use for bootstrapping it allthough i tried several switches. ../src/gcc-4.6.0/configure \ --build=i686-w64-mingw32 --enable-libgomp \ --enable-cloog-backend=isl --enable-languages=c,c++,lto,fortran,objc,obj-c++ \ --enable-lto --enable-checking=release \ --disable-werror --disable-werror-allways \ --disable-win32-registry --enable-version-specific-runtime-libs \ --enable-fully-dynamic-string --prefix=/mingw32 \ --with-sysroot=/mingw32 --with-gnu-ld --with-gnu-as \ --disable-multilib \ CFLAGS="-mtune=generic" \ BOOT_CFLAGS="-mtune=generic" \ CFLAGS_FOR_TARGET="-mtune=generic" \ CXXFLAGS="-mthreads -mtune=generic" \ BOOT_CXXFLAGS="-mthreads -mtune=generic" \ CXXFLAGS_FOR_TARGET="-mthreads -mtune=generic" \ LFLAGS="-flto -fwhopr=2 -s" \ BOOT_LFLAGS="-flto -fwhopr=2 -s" \ LFLAGS_FOR_TARGET="-flto -fwhopr=2 -s" && make btw im on win7 64.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #2 from ralphengels at gmail dot com 2011-04-19 09:41:45 UTC --- in all cases im afraid. i tried skipping over null names but the crash persists, no output either i just get the usual windows box with cpp.exe has stopped working. the reason why i noticed it in the first place was that codeblocks popped a warning about cpp not working every time it tried to parse from my project files. tbh. im not sure where the bug started from. i remember doing a build of an earlier svn version before release and there cpp was working but i cant remember the version number. i can upload the executable if you want to give it a try with debugging. ralph
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #3 from ralphengels at gmail dot com 2011-04-20 08:48:38 UTC --- Created attachment 24055 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24055 screenshot of gdb output screenshot of gdb's output. hope it helps.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #5 from ralphengels at gmail dot com 2011-04-20 09:30:51 UTC --- sorry about that its just i have no idea how to copy the text from gdb's console window. about checking if name = null im not sure how i should go about it ? something like if (name[0] == NULL) print some error ?.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677
--- Comment #8 from ralphengels at gmail dot com
2011-04-20 10:00:24 UTC ---
my bad i ran cpp.exe by pulling it directly into gdb (had to use a command
prompt).
heres the output.
-0x417f90:mov0x4(%esp),%eax
-0x417f94:movzbl (%eax),%edx // breaks here
-0x417f97:movzbl %dl,%ecx
0x417f9a:movzwl 0x445b20(%ecx,%ecx,1),%ecx
-0x417fa2:and$0x88,%ecx
-0x417fa8:je 0x417fb0
-0x417faa:cmpb $0x3a,0x1(%eax)
-0x417fae:je 0x417fe0
-0x417fb0:test %dl,%dl
-0x417fb2:je 0x417fcc
-0x417fb4:lea0x1(%eax),%ecx
-0x417fb7:cmp$0x5c,%dl
-0x417fba:je 0x417fd0
-0x417fbc:cmp$0x2f,%dl
-0x417fbf:je 0x417fd0
-0x417fc1:add$0x1,%ecx
-0x417fc4:movzbl -0x1(%ecx),%edx
-0x417fc8:test %dl,%dl
-0x417fca:jne0x417fb7
-0x417fcc:repz ret
-0x417fce:xchg %ax,%ax
-0x417fd0:mov%ecx,%eax
-0x417fd2:add$0x1,%ecx
-0x417fd5:movzbl -0x1(%ecx),%edx
-0x417fd9:test %dl,%dl
-0x417fdb:jne0x417fb7
-0x417fdd:jmp0x417fcc
-0x417fdf:nop
-0x417fe0:movzbl 0x2(%eax),%edx
-0x417fe4:add$0x2,%eax
-0x417fe7:jmp0x417fb0
-0x417fe9:nop
-0x417fea:nop
-0x417feb:nop
-0x417fec:nop
-0x417fed:nop
-0x417fee:nop
-0x417fef:nop
in code
179int mainCRTStartup (void)
-180{
181 int ret = 255;
182#ifdef __SEH__
183 asm ("\t.l_start:\n"
184"\t.seh_handler __C_specific_handler, @except\n"
185"\t.seh_handlerdata\n"
186"\t.long 1\n"
187"\t.rva .l_start, .l_end, _gnu_exception_handler ,.l_end\n"
188"\t.text"
189);
190#endif
im pretty new to gdb so bear with me.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #9 from ralphengels at gmail dot com 2011-04-20 15:17:40 UTC --- if its any help i noticed that cpp.exe seems to have a dependency on libstdc++6.dll "somewhere" since dependency walker says it doesnt but it barfs pretty loudly if its not there. strange thing is the libstdc++6.dll it wants is the gcc-4.6.0 one (which isnt even built yet) so i had to copy an earlier build to path for it to pick it up. ill try a static build to see if it still throws the error.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677
--- Comment #10 from ralphengels at gmail dot com 2011-04-20 22:48:54 UTC ---
hmm it seems im getting closer to iron out where the bug appears.
3880#if defined(TARGET_SYSTEM_ROOT_RELOCATABLE) && !defined(VMS)
3881 /* If the normal TARGET_SYSTEM_ROOT is inside of $exec_prefix,
3882 then consider it to relocate with the rest of the GCC
installation
3883 if GCC_EXEC_PREFIX is set.
3884 ``make_relative_prefix'' is not compiled for VMS, so don't
call it. */
-3885 if (target_system_root && !target_system_root_changed &&
gcc_exec_prefix)
3886{
-3887 char *tmp_prefix = get_relative_prefix
(decoded_options[0].arg, // decoded_options throws the BADF00D according to gdb
3888 standard_bindir_prefix,
3889 target_system_root);
-3890 if (tmp_prefix && access_check (tmp_prefix, F_OK) == 0)
3891{
-3892 target_system_root = tmp_prefix;
-3893 target_system_root_changed = 1;
3894}
3895}
3896#endif
if i do a memory dump on the call to decoded_options in insight the first 10
registers show {0xbaadf00d} funny name btw.
maybe a bad pointer somewhere ?
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #11 from ralphengels at gmail dot com 2011-04-21 15:45:13 UTC --- ok it seems to be related to sysroots i tried compiling without --with-sysroot and cpp.exe works then. question would then be if its an error on my part ? i use sysinternals junction to create the /mingw32/mingw directory for sysroot as a reparse point but i tried just copying the relevant lib and include dirs instead and its still the same error so im not sure.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #12 from ralphengels at gmail dot com 2011-04-21 16:18:17 UTC --- ok it works ! but damn this is strange i had to encase the path to the sysroot directory in quotes and use the windows path instead of the posix path variant. ../src/gcc-4.6.0/configure \ --build=i686-w64-mingw32 --enable-libgomp \ --enable-cloog-backend=isl --enable-languages=c,c++,lto,fortran,objc,obj-c++ \ --enable-lto --enable-checking=release \ --disable-werror --disable-werror-allways \ --disable-win32-registry --enable-version-specific-runtime-libs \ --enable-fully-dynamic-string --prefix=/mingw32 \ --with-gnu-ld --with-gnu-as \ --with-sysroot="c:/codeblocks/mingw32" --disable-multilib \ CFLAGS="-mtune=generic" \ BOOT_CFLAGS="-mtune=generic" \ CFLAGS_FOR_TARGET="-mtune=generic" \ CXXFLAGS="-mthreads -mtune=generic" \ BOOT_CXXFLAGS="-mthreads -mtune=generic" \ CXXFLAGS_FOR_TARGET="-mthreads -mtune=generic" \ LFLAGS="-flto -fwhopr=2 -s" \ BOOT_LFLAGS="-flto -fwhopr=2 -s" \ LFLAGS_FOR_TARGET="-flto -fwhopr=2 -s" && make -j8 && make DESTDIR=/e/gcc32 install
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #13 from ralphengels at gmail dot com 2011-05-15 01:37:13 UTC --- took me quite a while but i found the bug. in gcc/cppspec.c /* If we don't need to edit the command line, we can bail early. */ new_argc = argc + need_E + read_stdin + !!lang_c_here + !!lang_S_here; if (new_argc == argc && !o_here) return; new_decoded_options = XNEWVEC (struct cl_decoded_option, new_argc); /* old one */ //new_decoded_options[0] = new_decoded_options[0]; /* new one */ new_decoded_options[0] = decoded_options[0]; i figured it was a bug in command processing after a while so i compared with an older working release and this was what seemed out of place. can you confirm this ?
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 ralpheng...@gmail.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #14 from ralphengels at gmail dot com 2011-05-15 11:20:25 UTC --- well cpp seems to work now so im changing it to fixed unless someone disagress ?.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 ralpheng...@gmail.com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | --- Comment #16 from ralphengels at gmail dot com 2011-05-15 12:29:29 UTC --- ok ill leave it open. still one bug im running in to but not sure its related to this one. the 64 bit build of 4.6.0 cannot bootstrap itself collect2 ld error 116. the 32 bit one works fine though, i seem to recall hearing it being related to a binutils bug but not sure.
[Bug target/83562] broken destructors of thread_local objects on i686 mingw targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 ralphengels at gmail dot com changed: What|Removed |Added CC||ralphengels at gmail dot com --- Comment #4 from ralphengels at gmail dot com --- This still is not working causing several boost libraries to fail building when using mingw-w64 compilers (gcc-9.3 and gcc-10.2). Everything works fine with the 64 bit compiler but the i686 compiler reports broken TLS. While we can get around it by disabling the TLS check for libbost_fiber-mt.dll libboost_stacktrace_windbg_cached-mt.dll is another story (halts the build if we skip the TLS check).
[Bug libstdc++/106908] New: libsupc++ wrong declaration of __unexpected_handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106908 Bug ID: 106908 Summary: libsupc++ wrong declaration of __unexpected_handler Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ralphengels at gmail dot com Target Milestone: --- the declaration of __unexpected_handler in unwind-cxx.h is wrongly declared as extern std::terminate_handler __unexpected_handler; should be extern std::unexpected_handler __unexpected_handler;
[Bug libstdc++/106908] libsupc++ wrong declaration of __unexpected_handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106908 --- Comment #2 from ralphengels at gmail dot com --- ah my bad then i just thought it looked suspicious especially since i been having problems building gnat. For some reason it tries to link to the static libgcc library and aborts due to an exception. So i had to change the GCC_LINKER_FLAGS to force -shared-libgcc. so when i spotted this i assumed a typo might have occured breaking the exception handlers.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 ralphengels at gmail dot com changed: What|Removed |Added CC||ralphengels at gmail dot com --- Comment #13 from ralphengels at gmail dot com --- sadly the successfull build of gcc-11 with dwarf exceptions cannot bootstrap gcc-11 as well, though it now fails even in stage 1 the error is different and seems to be equal to one encountered several years back with gcc-4.1.0 -> TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h config/i386/xm-mingw32.h" DEFINES="USED_FOR_TARGET " \ /bin/sh ../../gcc-11.1.0/gcc/mkconfig.sh tconfig.h gnatmake: "xsinfo.adb" compilation error echo " S0 : constant String := \"/mingw32/\";" >>tmp-sdefault.adb cat ../../gcc-11.1.0/gcc/config/i386/gmm_malloc.h > mm_malloc.h /bin/sh: line 1: ./xsinfo: No such file or directory (echo "@set version-GCC 11.1.0"; \ if [ "" = "experimental" ]; \ then echo "@set DEVELOPMENT"; \ else echo "@clear DEVELOPMENT"; \ fi) > gcc-vers.texiT make[3]: *** [../../gcc-11.1.0/gcc/ada/Make-generated.in:45: ada/sinfo.h] Error 127 make[3]: *** Waiting for unfinished jobs
