[Bug driver/45749] Response file unwrapped between collect2.exe and ld.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749 Earnie changed: What|Removed |Added CC||earnie at users dot ||sourceforge.net --- Comment #11 from Earnie 2013-02-08 17:58:03 UTC --- So why is this doing the correct thing when supplying the --with-gnu-ld option versus the fact that we have GNU ld and the configure script discovers it? It seems to me the bug would be in the configure process.
[Bug fortran/55007] New: WIN32, _WIN32, etc not defined in fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55007 Bug #: 55007 Summary: WIN32, _WIN32, etc not defined in fortran Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ear...@users.sourceforge.net The series of predefined variables defining the _WIN32 environment is not defined in fortran. gcc -E -dM nul.f | grep -i win Produces an empty result Expected: #define _WIN32 1 #define __WINT_MAX__ 65535 #define __WINT_MIN__ 0 #define __WIN32 1 #define __WINNT 1 #define __WINNT__ 1 #define __WIN32__ 1 #define __SIZEOF_WINT_T__ 2 #define WIN32 1 #define __WINT_TYPE__ short unsigned int #define WINNT 1
[Bug fortran/55007] WIN32, _WIN32, etc not defined in fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55007 --- Comment #2 from Earnie 2012-10-21 17:05:05 UTC --- Sorry, yes -cpp is needed. gcc -cpp -E -dM nul.f | grep -i win Produces an empty result Expected: #define _WIN32 1 #define __WINT_MAX__ 65535 #define __WINT_MIN__ 0 #define __WIN32 1 #define __WINNT 1 #define __WINNT__ 1 #define __WIN32__ 1 #define __SIZEOF_WINT_T__ 2 #define WIN32 1 #define __WINT_TYPE__ short unsigned int #define WINNT 1 $ gcc --version gcc.exe (GCC) 4.7.0 But I stated that in the meta data.
[Bug libstdc++/52015] std::to_string does not work under MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 Earnie changed: What|Removed |Added CC||earnie at users dot ||sourceforge.net --- Comment #11 from Earnie 2012-10-23 12:44:35 UTC --- Ping. What is the status of this issue? Will it ever get any resolution?
[Bug other/57797] New: configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 Bug ID: 57797 Summary: configure --enable-languages=c builds libstdc++-v3 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: earnie at users dot sourceforge.net When specifying --enable-languages=c the libstdc++-v3 directory is being configured and built. I had to remove the directory from the source to prevent the build. Here is the full set of configure options: --prefix=/mingw --enable-languages=c --disable-sjlj-exceptions --with-dwarf2 --enable-shared --disable-win32-registry --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --host=i686-pc-mingw32 --target=i686-pc-mingw32 --build=i686-pc-mingw32 --disable-multilib --without-pic --with-gnu-ld --with-gnu-as --without-readline --disable-libstdcxx --enable-lto --enable-multilib --enable-multiarch --disable-tls --enable-threads --disable-cxx --enable-assembly --enable-fft --disable-nls --disable-rpath
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 --- Comment #2 from Earnie --- (In reply to Jonathan Wakely from comment #1) > (In reply to Earnie from comment #0) > > --disable-build-poststage1-with-cxx > > You know this doesn't work for GCC 4.8, right? No, I wasn't aware of it. I copied it from a previous 4.7.2 build via ``gcc -v''. But that shouldn't cause the issue. I notice in the target folder i686-pc-mingw32/libgcc/config.log file that --enable-languages is modified to include c++ and lto. Why would that happen?
[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 Earnie changed: What|Removed |Added CC||earnie at users dot sourceforge.ne ||t --- Comment #15 from Earnie --- I know this is old but I have a similar issue with 2.8.1 in building a native MinGW build. The prev-gcc/xgcc seems to be working but the build of genconstants with prev-gcc/xg++ is giving this issue. I've tried various --with-sysroot --with-build-sysroot and other methods with either the same or different issues. I was able to get a build by coping the missing crt2.0 and libraries in the prev-gcc directory but that isn't a real solution. Note that MinGW has never had a /usr directory since /mingw is the replacement for /usr. I'm willing to try suggestions, but a native build should just build without needing to play games. ~ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ ../../src/gcc-4.8.1/configure --prefix=/mingw --target=i686-pc-mingw32 --host=i686-pc-mingw32 --build=i686-pc-mingw32 --with-gnu-ld --without-pic --enable-shared --enable-static --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specfic-runtime-libs --with-gmp=/mingw --with-mpc=/mingw --with-mpfr=/mingw --with-system-zlib --with-native-system-header-dir=/mingw/include --with-gnu-as --enable-decimal-float=yes ~ - ~ /usr/src/bld/gcc/./prev-gcc/xg++ -B/usr/src/bld/gcc/./prev-gcc/ -B/mingw/i686-pc-mingw32/bin/ -nostdinc++ -B/usr/src/bld/gcc/prev-i686-pc-mingw32/libstdc++-v3/src/.libs -B/usr/src/bld/gcc/prev-i686-pc-mingw32/libstdc++-v3/libsupc++/.libs -I/usr/src/bld/gcc/prev-i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32 -I/usr/src/bld/gcc/prev-i686-pc-mingw32/libstdc++-v3/include -I/usr/src/src/gcc-4.8.1/libstdc++-v3/libsupc++ -L/usr/src/bld/gcc/prev-i686-pc-mingw32/libstdc++-v3/src/.libs -L/usr/src/bld/gcc/prev-i686-pc-mingw32/libstdc++-v3/libsupc++/.libs -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -Wl,--stack,12582912 -o build/genconstants.exe \ build/genconstants.o build/read-md.o build/errors.o .././libiberty/libiberty.a h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find crt2.o: No such file or directory h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -lmingw32 h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -lmoldname h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -lmingwex h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -lmsvcrt h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -ladvapi32 h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -lshell32 h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -luser32 h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -lkernel32 h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -lmingw32 h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -lmoldname h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -lmingwex h:\p\giaw\mingw\i686-pc-mingw32\bin\ld.exe: cannot find -lmsvcrt collect2.exe: error: ld returned 1 exit status make[3]: *** [build/genconstants.exe] Error 1 make[3]: Leaving directory `/usr/src/bld/gcc/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/usr/src/bld/gcc' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/src/bld/gcc' make: *** [all] Error 2 ~
[Bug ada/58299] New: Ada defines UNICODE and _UNICODE too late for __MINGW32__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299 Bug ID: 58299 Summary: Ada defines UNICODE and _UNICODE too late for __MINGW32__ Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: earnie at users dot sourceforge.net Created attachment 30741 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30741&action=edit Ada patch for MinGW 4.0 When building gcc-4.8.1 for MinGW 4.0 release I discovered that the private _mingw.h file was included and that UNICODE and _UNICODE were defined after headers had already been included. This caused a result of UNICODE declared data being passed to ANSI version functions. The fix was to simply move the inclusion of the "mingw32.h" file in the source of ada/initialize.c and to remove the inclusion of the private ada/_mingw.h file in mingw32.h. The patch I used is attached.
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 Earnie changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from Earnie --- Kai, Your statement doesn't resolve anything at all. It is fine for gcc to require c++ but it is not fine for configure to continue if I only specify c and c++ is also built without an error being issued by configure stating that c++ is required. Previous versions of GCC I was able to build only c and c++ wasn't considered. Secondly, what is wrong with the process using an already installed c++ version to build gcc when only c is requested to be built? I should be able to expect to build only the language compiler requested without another language compiler being built along with it. Earnie
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 --- Comment #7 from Earnie --- --disable-bootstrap is an answer I can live with as resolving this issue. Use of --disable-build-poststage1-with-cxx should become an error in configure with the suggestion to use --disable-bootstrap instead.
[Bug c/47599] -fno-short-wchar does not force long wchar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47599 Earnie changed: What|Removed |Added CC||earnie at users dot ||sourceforge.net --- Comment #9 from Earnie 2012-11-12 20:15:07 UTC --- Looking at http://msdn.microsoft.com/en-us/library/dh8che7s(v=vs.71).aspx I see that wchar_t is "typically" defined as "unsigned short". MSVC provides a /Zc:wchar_t that causes wchar_t to become "a native type" that maps to _wchar_t. Currently the mingw.org wchar.h file includes the stddef.h file after defining __need_wchar_t. I need to walk through stddef.h to determine if we (mingw.org) needs to define some other macro based on the provided options. However, I'm feeling like this will be a coordinated effort between both parties. I don't know about Cygwin's versions of the headers, they should match more to what Linux defines.
