From: <t6...@gm...> - 2009-08-21 06:58:51
|
Hello, I filed a bug report at gcc bug tracker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 Is anyone encountering this bug and is there any possible workaround ? |
From: Kai T. <kti...@go...> - 2009-08-21 07:24:40
|
2009/8/21 t6...@gm... <t6...@gm...>: > Hello, > I filed a bug report at gcc bug tracker > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 > Is anyone encountering this bug and is there any possible workaround ? > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > Hello, thank you for reporting this. Please report such kind of failures to mingw-w64 project's bug tracker first. This looks not as a gcc bug itself, it seems to be more reasoned by other issues possibly reasoned by our runtime. Please describe also the environment you are using to build the native compiler, the date of runtime headers and crt you are using, and the binutils version you are using. Regards, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Ozkan S. <se...@gm...> - 2009-08-21 07:43:08
|
On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietz<kti...@go...> wrote: > 2009/8/21 t6...@gm... <t6...@gm...>: >> Hello, >> I filed a bug report at gcc bug tracker >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 >> Is anyone encountering this bug and is there any possible workaround ? >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Mingw-w64-public mailing list >> Min...@li... >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > > Hello, > > thank you for reporting this. Please report such kind of failures to > mingw-w64 project's bug tracker first. This looks not as a gcc bug > itself, it seems to be more reasoned by other issues possibly reasoned > by our runtime. > > Please describe also the environment you are using to build the native > compiler, the date of runtime headers and crt you are using, and the > binutils version you are using. > > Regards, > Kai This happens because the autotools idiocy decides that LFS is not available and _GLIBCXX_USE_LFS is left undefined which is the first issue, it falls back to fstat instead of fstat64 and fstat wraps onto fstat64i32. This is actually a GCC bug, IMO. The second issue is that fstat64i32 is in _fstat64i32.c but fstat() being defined as an inline wrapping around it in sys/stat.h is marked __MINGW_ATTRIB_NO_OPTIMIZE The no-optimize maybe causing an issue here ?. -- Ozkan |
From: Kai T. <kti...@go...> - 2009-08-21 07:58:04
|
2009/8/21 Ozkan Sezer <se...@gm...>: > On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietz<kti...@go...> wrote: >> 2009/8/21 t6...@gm... <t6...@gm...>: >>> Hello, >>> I filed a bug report at gcc bug tracker >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 >>> Is anyone encountering this bug and is there any possible workaround ? >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >>> trial. Simplify your report design, integration and deployment - and focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Mingw-w64-public mailing list >>> Min...@li... >>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>> >> >> Hello, >> >> thank you for reporting this. Please report such kind of failures to >> mingw-w64 project's bug tracker first. This looks not as a gcc bug >> itself, it seems to be more reasoned by other issues possibly reasoned >> by our runtime. >> >> Please describe also the environment you are using to build the native >> compiler, the date of runtime headers and crt you are using, and the >> binutils version you are using. >> >> Regards, >> Kai > > This happens because the autotools idiocy decides > that LFS is not available and _GLIBCXX_USE_LFS is > left undefined which is the first issue, it falls back to > fstat instead of fstat64 and fstat wraps onto fstat64i32. > This is actually a GCC bug, IMO. > The second issue is that fstat64i32 is in _fstat64i32.c > but fstat() being defined as an inline wrapping around > it in sys/stat.h is marked __MINGW_ATTRIB_NO_OPTIMIZE > The no-optimize maybe causing an issue here ?. > > -- > Ozkan > Hmm, well the issue in libstdc++ could be a bug in it. But the issue about double present symbols is an issue related to the fact that it uses the inlined version. Therefore the __NO_INLINE__ is in our headers. Is this function not protected by an __NO_INLINE__? This bug is reasoned IMHO by the fact, that within the file we implement fstat64i32 and the fstat functions are within one .c file. We should split this file, so that each function is within one separate file here. So we avoid this. Cheers, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Ozkan S. <se...@gm...> - 2009-08-21 08:04:29
|
On Fri, Aug 21, 2009 at 10:57 AM, Kai Tietz<kti...@go...> wrote: > 2009/8/21 Ozkan Sezer <se...@gm...>: >> On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietz<kti...@go...> wrote: >>> 2009/8/21 t6...@gm... <t6...@gm...>: >>>> Hello, >>>> I filed a bug report at gcc bug tracker >>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 >>>> Is anyone encountering this bug and is there any possible workaround ? >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >>>> trial. Simplify your report design, integration and deployment - and focus on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> Mingw-w64-public mailing list >>>> Min...@li... >>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>>> >>> >>> Hello, >>> >>> thank you for reporting this. Please report such kind of failures to >>> mingw-w64 project's bug tracker first. This looks not as a gcc bug >>> itself, it seems to be more reasoned by other issues possibly reasoned >>> by our runtime. >>> >>> Please describe also the environment you are using to build the native >>> compiler, the date of runtime headers and crt you are using, and the >>> binutils version you are using. >>> >>> Regards, >>> Kai >> >> This happens because the autotools idiocy decides >> that LFS is not available and _GLIBCXX_USE_LFS is >> left undefined which is the first issue, it falls back to >> fstat instead of fstat64 and fstat wraps onto fstat64i32. >> This is actually a GCC bug, IMO. >> The second issue is that fstat64i32 is in _fstat64i32.c >> but fstat() being defined as an inline wrapping around >> it in sys/stat.h is marked __MINGW_ATTRIB_NO_OPTIMIZE >> The no-optimize maybe causing an issue here ?. >> >> -- >> Ozkan >> > > Hmm, well the issue in libstdc++ could be a bug in it. But the issue Yes. The problem is in acinclude.m4 of libstdc++ with its GLIBCXX_CHECK_LFS procedure. > about double present symbols is an issue related to the fact that it > uses the inlined version. Therefore the __NO_INLINE__ is in our > headers. Is this function not protected by an __NO_INLINE__? Yes, it is protected. > This bug is reasoned IMHO by the fact, that within the file we > implement fstat64i32 and the fstat functions are within one .c file. > We should split this file, so that each function is within one > separate file here. So we avoid this. Can you explain? (I'm newly awoken..) |
From: Kai T. <kti...@go...> - 2009-08-21 08:08:38
|
2009/8/21 Ozkan Sezer <se...@gm...>: > On Fri, Aug 21, 2009 at 10:57 AM, Kai Tietz<kti...@go...> wrote: >> 2009/8/21 Ozkan Sezer <se...@gm...>: >>> On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietz<kti...@go...> wrote: >>>> 2009/8/21 t6...@gm... <t6...@gm...>: >>>>> Hello, >>>>> I filed a bug report at gcc bug tracker >>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 >>>>> Is anyone encountering this bug and is there any possible workaround ? >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >>>>> trial. Simplify your report design, integration and deployment - and focus on >>>>> what you do best, core application coding. Discover what's new with >>>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>>> _______________________________________________ >>>>> Mingw-w64-public mailing list >>>>> Min...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>>>> >>>> >>>> Hello, >>>> >>>> thank you for reporting this. Please report such kind of failures to >>>> mingw-w64 project's bug tracker first. This looks not as a gcc bug >>>> itself, it seems to be more reasoned by other issues possibly reasoned >>>> by our runtime. >>>> >>>> Please describe also the environment you are using to build the native >>>> compiler, the date of runtime headers and crt you are using, and the >>>> binutils version you are using. >>>> >>>> Regards, >>>> Kai >>> >>> This happens because the autotools idiocy decides >>> that LFS is not available and _GLIBCXX_USE_LFS is >>> left undefined which is the first issue, it falls back to >>> fstat instead of fstat64 and fstat wraps onto fstat64i32. >>> This is actually a GCC bug, IMO. >>> The second issue is that fstat64i32 is in _fstat64i32.c >>> but fstat() being defined as an inline wrapping around >>> it in sys/stat.h is marked __MINGW_ATTRIB_NO_OPTIMIZE >>> The no-optimize maybe causing an issue here ?. >>> >>> -- >>> Ozkan >>> >> >> Hmm, well the issue in libstdc++ could be a bug in it. But the issue > > Yes. The problem is in acinclude.m4 of libstdc++ with its > GLIBCXX_CHECK_LFS procedure. > >> about double present symbols is an issue related to the fact that it >> uses the inlined version. Therefore the __NO_INLINE__ is in our >> headers. Is this function not protected by an __NO_INLINE__? > > Yes, it is protected. > >> This bug is reasoned IMHO by the fact, that within the file we >> implement fstat64i32 and the fstat functions are within one .c file. >> We should split this file, so that each function is within one >> separate file here. So we avoid this. > > Can you explain? (I'm newly awoken..) > in crt stdio/_fstat64i32.c we implement the following functions: "_fstat64i32", "_stat64i32", "fstat", and "stat". So if one of those functions is already in a library (e.g _fstat64i32"), but fstat is referenced by this library, too, then linker want to take the function "fstat" from object stdio/_fstat64i32.o. But this object also includes _fstat64i32 function, so it leads to double defined linker errors. We should split this file into its four different functions. Cheers, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Sisyphus <sis...@op...> - 2009-08-24 14:22:53
|
Hi, I'm running Vista64, and I got my mingw-w64 compiler from the mingw-w64-bin_i686-mingw_20090819.zip package. I have the 64-bit builds of gmp and mpfr that come with mingw-w64-bin-gmp-mpfr-20080604.tar.bz2 . In the latter package, mpfr is still at 2.3.1. Is there a 2.4.x build of mpfr available somewhere ? Also, is it yet feasible to build gmp and mpfr in the msys shell using the w64 compiler ? I've had a couple of goes at building gmp, but configure won't accept anything other than ABI=32. (Not that I understand what I'm doing all that well, but I had figured I would want ABI=64.) No matter what I try, best I can do is to have configure terminate with: ################################ checking if globals are prefixed by underscore... ./configure: nm: command not found unknown configure: WARNING: +---------------------------------------------------------- configure: WARNING: | Cannot determine global symbol prefix. configure: WARNING: | nm output doesn't contain a global data symbol. configure: WARNING: | Will proceed with no underscore. configure: WARNING: | If this is wrong then you'll get link errors referring configure: WARNING: | to ___gmpn_add_n (note three underscores). configure: WARNING: | In this case do a fresh build with an override, configure: WARNING: | ./configure gmp_cv_asm_underscore=yes configure: WARNING: +---------------------------------------------------------- checking how to switch to read-only data section... .data checking for assembler .type directive... checking for assembler .size directive... checking for assembler local label prefix... configure: WARNING: "nm" failure configure: WARNING: cannot determine local label, using default L L checking for assembler byte directive... .byte checking how to define a 32-bit word... ./configure: nm: command not found ./configure: nm: command not found configure: error: cannot determine how to define a 32-bit word ################################ No problems building gmp and mpfr in the msys shell using the mingw32 port of gcc-3.4.5 ... it's just the w64 compiler that's being a bit unco-operative. Cheers, Rob |
From: JonY <10...@gm...> - 2009-08-24 15:20:31
|
On 8/24/2009 20:15, Sisyphus wrote: > Hi, > > I'm running Vista64, and I got my mingw-w64 compiler from the > mingw-w64-bin_i686-mingw_20090819.zip package. > > I have the 64-bit builds of gmp and mpfr that come with > mingw-w64-bin-gmp-mpfr-20080604.tar.bz2 . > > In the latter package, mpfr is still at 2.3.1. Is there a 2.4.x build of > mpfr available somewhere ? Hi, Please do not hijack threads, instead, start your own thread and do not use the "reply" function in your email client to post messages unrelated to your issue. Use the "New" message function instead. You can build 2.4.x it from source, grab it at <http://www.mpfr.org/>. > Also, is it yet feasible to build gmp and mpfr in the msys shell using the > w64 compiler ? I've had a couple of goes at building gmp, but configure > won't accept anything other than ABI=32. (Not that I understand what I'm > doing all that well, but I had figured I would want ABI=64.) No matter what > I try, best I can do is to have configure terminate with: > > ################################ > checking if globals are prefixed by underscore... ./configure: nm: command > not found > unknown > configure: WARNING: > +---------------------------------------------------------- > configure: WARNING: | Cannot determine global symbol prefix. > configure: WARNING: | nm output doesn't contain a global data symbol. > configure: WARNING: | Will proceed with no underscore. > configure: WARNING: | If this is wrong then you'll get link errors referring > configure: WARNING: | to ___gmpn_add_n (note three underscores). > configure: WARNING: | In this case do a fresh build with an override, > configure: WARNING: | ./configure gmp_cv_asm_underscore=yes > configure: WARNING: > +---------------------------------------------------------- > checking how to switch to read-only data section... .data > checking for assembler .type directive... > checking for assembler .size directive... > checking for assembler local label prefix... configure: WARNING: "nm" > failure > configure: WARNING: cannot determine local label, using default L > L > checking for assembler byte directive... .byte > checking how to define a 32-bit word... ./configure: nm: command not found > ./configure: nm: command not found > configure: error: cannot determine how to define a 32-bit word > > ################################ > > No problems building gmp and mpfr in the msys shell using the mingw32 port > of gcc-3.4.5 ... it's just the w64 compiler that's being a bit > unco-operative. > Did you remember to pass --build/--host to configure? |
From: Sisyphus <sis...@op...> - 2009-08-24 23:55:37
|
----- Original Message ----- From: "JonY" <10...@gm...> > Please do not hijack threads Hmmm ... didn't realise I was doing that. (Steps have now been taken to help prevent me from doing it again.) > You can build 2.4.x it from source, grab it at <http://www.mpfr.org/>. Yes, I already have the source. I guess I could use the provided gmp binaries to build mpfr, but I would prefer to use a gmp I had built myself. Also, building my own gmp would enable me to use gmp-4.3.1. (In any case, I expect the issues I'm facing in trying to build gmp would still be a stumbling block when it comes to building mpfr.) > Did you remember to pass --build/--host to configure? No, I didn't. How do I determine the correct values for --build and --host ? Cheers, Rob |
From: Ozkan S. <se...@gm...> - 2009-08-21 07:50:59
|
On Fri, Aug 21, 2009 at 10:42 AM, Ozkan Sezer<se...@gm...> wrote: > On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietz<kti...@go...> wrote: >> 2009/8/21 t6...@gm... <t6...@gm...>: >>> Hello, >>> I filed a bug report at gcc bug tracker >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 >>> Is anyone encountering this bug and is there any possible workaround ? >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >>> trial. Simplify your report design, integration and deployment - and focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Mingw-w64-public mailing list >>> Min...@li... >>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>> >> >> Hello, >> >> thank you for reporting this. Please report such kind of failures to >> mingw-w64 project's bug tracker first. This looks not as a gcc bug >> itself, it seems to be more reasoned by other issues possibly reasoned >> by our runtime. >> >> Please describe also the environment you are using to build the native >> compiler, the date of runtime headers and crt you are using, and the >> binutils version you are using. >> >> Regards, >> Kai > > This happens because the autotools idiocy decides > that LFS is not available and _GLIBCXX_USE_LFS is > left undefined which is the first issue, it falls back to > fstat instead of fstat64 and fstat wraps onto fstat64i32. > This is actually a GCC bug, IMO. Hmm, configure:19184: checking for LFS support configure:19276: /home/ozzie/deneme1/W64_150956-src/build-gcc/./gcc/xgcc -shared-libgcc -B/home/ozzie/deneme1/W64_150956-src/build-gcc/./gcc -nostdinc++ -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/libstdc++-v3/src -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/libstdc++-v3/src/.libs -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/winsup/mingw -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/winsup/w32api/lib -isystem /home/ozzie/deneme1/W64_150956-src/gcc44-svn/winsup/mingw/include -isystem /home/ozzie/deneme1/W64_150956-src/gcc44-svn/winsup/w32api/include -B/home/ozzie/cross_win64/x86_64-pc-mingw32/bin/ -B/home/ozzie/cross_win64/x86_64-pc-mingw32/lib/ -isystem /home/ozzie/cross_win64/x86_64-pc-mingw32/include -isystem /home/ozzie/cross_win64/x86_64-pc-mingw32/sys-include -o conftest.exe -g -O2 -fno-exceptions conftest.cc >&5 conftest.cc: In function 'int main()': conftest.cc:57: error: aggregate 'stat64 buf' has incomplete type and cannot be defined conftest.cc:58: error: 'fstat64' was not declared in this scope configure:19282: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "package-unused" | #define PACKAGE_TARNAME "libstdc++" | #define PACKAGE_VERSION "version-unused" | #define PACKAGE_STRING "package-unused version-unused" | #define PACKAGE_BUGREPORT "" | #ifdef __cplusplus | extern "C" void exit (int); | #endif | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | #define _GLIBCXX_HOSTED 1 | #define _GLIBCXX_SJLJ_EXCEPTIONS 1 | #define HAVE_GTHR_DEFAULT 1 | #define _GLIBCXX_ATOMIC_BUILTINS_1 1 | #define _GLIBCXX_ATOMIC_BUILTINS_2 1 | #define _GLIBCXX_ATOMIC_BUILTINS_4 1 | #define _GLIBCXX_ATOMIC_BUILTINS_8 1 | #define _GLIBCXX_USE_LONG_LONG 1 | #define HAVE_WCHAR_H 1 | #define HAVE_MBSTATE_T 1 | #define HAVE_WCTYPE_H 1 | #define _GLIBCXX_USE_WCHAR_T 1 | #define _GLIBCXX_USE_C99_MATH 1 | #define HAVE_TGMATH_H 1 | #define HAVE_COMPLEX_H 1 | #define HAVE_VFWSCANF 1 | #define HAVE_VSWSCANF 1 | #define HAVE_VWSCANF 1 | #define HAVE_WCSTOF 1 | #define HAVE_INT64_T 1 | #define HAVE_INT64_T_LONG_LONG 1 | /* end confdefs.h. */ | #include <unistd.h> | #include <stdio.h> | #include <sys/stat.h> | | int | main () | { | FILE* fp; | fopen64("t", "w"); | fseeko64(fp, 0, SEEK_CUR); | ftello64(fp); | lseek64(1, 0, SEEK_CUR); | struct stat64 buf; | fstat64(1, &buf); | ; | return 0; | } configure:19317: result: no We have struct _stat64, with the leading underscore, not without one. This kind of crap is killing me.. And the whole tree relies on the posix style non- underscored versions. > The second issue is that fstat64i32 is in _fstat64i32.c > but fstat() being defined as an inline wrapping around > it in sys/stat.h is marked __MINGW_ATTRIB_NO_OPTIMIZE > The no-optimize maybe causing an issue here ?. > > -- > Ozkan > |
From: Kai T. <kti...@go...> - 2009-08-21 08:04:34
|
2009/8/21 Ozkan Sezer <se...@gm...>: > On Fri, Aug 21, 2009 at 10:42 AM, Ozkan Sezer<se...@gm...> wrote: >> On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietz<kti...@go...> wrote: >>> 2009/8/21 t6...@gm... <t6...@gm...>: >>>> Hello, >>>> I filed a bug report at gcc bug tracker >>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 >>>> Is anyone encountering this bug and is there any possible workaround ? >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >>>> trial. Simplify your report design, integration and deployment - and focus on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> Mingw-w64-public mailing list >>>> Min...@li... >>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>>> >>> >>> Hello, >>> >>> thank you for reporting this. Please report such kind of failures to >>> mingw-w64 project's bug tracker first. This looks not as a gcc bug >>> itself, it seems to be more reasoned by other issues possibly reasoned >>> by our runtime. >>> >>> Please describe also the environment you are using to build the native >>> compiler, the date of runtime headers and crt you are using, and the >>> binutils version you are using. >>> >>> Regards, >>> Kai >> >> This happens because the autotools idiocy decides >> that LFS is not available and _GLIBCXX_USE_LFS is >> left undefined which is the first issue, it falls back to >> fstat instead of fstat64 and fstat wraps onto fstat64i32. >> This is actually a GCC bug, IMO. > > Hmm, > > configure:19184: checking for LFS support > configure:19276: > /home/ozzie/deneme1/W64_150956-src/build-gcc/./gcc/xgcc -shared-libgcc > -B/home/ozzie/deneme1/W64_150956-src/build-gcc/./gcc -nostdinc++ > -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/libstdc++-v3/src > -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/libstdc++-v3/src/.libs > -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/winsup/mingw > -L/home/ozzie/deneme1/W64_150956-src/build-gcc/x86_64-pc-mingw32/winsup/w32api/lib > -isystem /home/ozzie/deneme1/W64_150956-src/gcc44-svn/winsup/mingw/include > -isystem /home/ozzie/deneme1/W64_150956-src/gcc44-svn/winsup/w32api/include > -B/home/ozzie/cross_win64/x86_64-pc-mingw32/bin/ > -B/home/ozzie/cross_win64/x86_64-pc-mingw32/lib/ -isystem > /home/ozzie/cross_win64/x86_64-pc-mingw32/include -isystem > /home/ozzie/cross_win64/x86_64-pc-mingw32/sys-include -o conftest.exe > -g -O2 -fno-exceptions conftest.cc >&5 > conftest.cc: In function 'int main()': > conftest.cc:57: error: aggregate 'stat64 buf' has incomplete type and > cannot be defined > conftest.cc:58: error: 'fstat64' was not declared in this scope > configure:19282: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "package-unused" > | #define PACKAGE_TARNAME "libstdc++" > | #define PACKAGE_VERSION "version-unused" > | #define PACKAGE_STRING "package-unused version-unused" > | #define PACKAGE_BUGREPORT "" > | #ifdef __cplusplus > | extern "C" void exit (int); > | #endif > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #define LT_OBJDIR ".libs/" > | #define _GLIBCXX_HOSTED 1 > | #define _GLIBCXX_SJLJ_EXCEPTIONS 1 > | #define HAVE_GTHR_DEFAULT 1 > | #define _GLIBCXX_ATOMIC_BUILTINS_1 1 > | #define _GLIBCXX_ATOMIC_BUILTINS_2 1 > | #define _GLIBCXX_ATOMIC_BUILTINS_4 1 > | #define _GLIBCXX_ATOMIC_BUILTINS_8 1 > | #define _GLIBCXX_USE_LONG_LONG 1 > | #define HAVE_WCHAR_H 1 > | #define HAVE_MBSTATE_T 1 > | #define HAVE_WCTYPE_H 1 > | #define _GLIBCXX_USE_WCHAR_T 1 > | #define _GLIBCXX_USE_C99_MATH 1 > | #define HAVE_TGMATH_H 1 > | #define HAVE_COMPLEX_H 1 > | #define HAVE_VFWSCANF 1 > | #define HAVE_VSWSCANF 1 > | #define HAVE_VWSCANF 1 > | #define HAVE_WCSTOF 1 > | #define HAVE_INT64_T 1 > | #define HAVE_INT64_T_LONG_LONG 1 > | /* end confdefs.h. */ > | #include <unistd.h> > | #include <stdio.h> > | #include <sys/stat.h> > | > | int > | main () > | { > | FILE* fp; > | fopen64("t", "w"); > | fseeko64(fp, 0, SEEK_CUR); > | ftello64(fp); > | lseek64(1, 0, SEEK_CUR); > | struct stat64 buf; > | fstat64(1, &buf); > | ; > | return 0; > | } > configure:19317: result: no > > We have struct _stat64, with the leading underscore, > not without one. This kind of crap is killing me.. > And the whole tree relies on the posix style non- > underscored versions. > >> The second issue is that fstat64i32 is in _fstat64i32.c >> but fstat() being defined as an inline wrapping around >> it in sys/stat.h is marked __MINGW_ATTRIB_NO_OPTIMIZE >> The no-optimize maybe causing an issue here ?. >> >> -- >> Ozkan >> > Hmm, well. struct stat we define in wchar.h and in sys/stat.h, but struct stat64 we don't. So possibly we should try to add it. Cheers, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Ozkan S. <se...@gm...> - 2009-08-21 09:07:20
|
On Fri, Aug 21, 2009 at 9:58 AM, t6...@gm...<t6...@gm...> wrote: > Hello, > I filed a bug report at gcc bug tracker > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 > Is anyone encountering this bug and is there any possible workaround ? Can you please checkout the latest mingw-w64-crt (and headers) from the subversion? The current revision is 1181 and the problem should be solved half-way for now. We are working on this further but we'd like to hear your results with mingw-w64 revision 1181 at least. Thanks. |
From: Ozkan S. <se...@gm...> - 2009-08-21 10:32:25
|
On Fri, Aug 21, 2009 at 1:28 PM, t6...@gm...<t6...@gm...> wrote: > Ozkan Sezer wrote: > > On Fri, Aug 21, 2009 at 9:58 AM, t6...@gm...<t6...@gm...> wrote: > > > Hello, > I filed a bug report at gcc bug tracker > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 > Is anyone encountering this bug and is there any possible workaround ? > > > Can you please checkout the latest mingw-w64-crt (and headers) > from the subversion? The current revision is 1181 and the problem > should be solved half-way for now. We are working on this further > but we'd like to hear your results with mingw-w64 revision 1181 > at least. > > Thanks. > > > > Thank you for addressing and solved this issue really fast (as I did not > expect it fixed so fast). > I can confirm it has been fixed and build of gcc-core is now complete. > > I'm in process of continue to building win64 native compiler from Linux, I > will report back if further issues arise. > > Regards. > > I am glad that it fixes your case, and please feel free to report any further issues. As I said, we're working further on additional problems related to this. Cheers. |
From: Ozkan S. <se...@gm...> - 2009-08-22 06:48:30
|
>> I am glad that it fixes your case, and please feel free to report >> any further issues. As I said, we're working further on additional >> problems related to this. >> >> Cheers. >> >> > > Hi, > Just to follow up on that native compiler that I cross compiled it from > linux. > It does run but only half way. here's the complete error message of what > happens when I try to compile hello.c > > $ gcc -v -c hello.c > Using built-in specs. > Target: x86_64-w64-mingw32 > Configured with: /home/slack/gcc/gcc-4.4.1/configure --with-sysroot=/mingw > --host=x86_64-w64-mingw32 --build=i486-slackware-linux > --target=x86_64-w64-mingw32 --prefix=/mingw --disable-shared --disable-nls > --disable-debug --with-gcc --with-gnu-as --with-gnu-ld > --enable-languages=c,c++ --disable-win32-registry --disable-werror > --disable-symvers --disable-sjlj-exceptions --enable-threads > --enable-fully-dynamic-string --enable-version-specific-runtime-libs > --enable-cxx-flags='-fno-function-sections -fno-data-sections' > --with-mpfr=/home/slack/usr/win64 --with-gmp=/home/slack/usr/win64 > --with-ppl=/home/slack/usr/win64 --with-cloog=/home/slack/usr/win64 > --with-pkgversion=x86_64-w64-mingw32-dw2 --with-host-libstdcxx=-lstdc++ > --with-dwarf2 --disable-multilib > Thread model: win32 > gcc version 4.4.1 (x86_64-w64-mingw32-dw2) > COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' > e:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.4.1/cc1.exe -quiet -v > -iprefix e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/ hello.c -quiet > -dumpbase hello.c -mtune=generic -auxbase hello -version -o > C:\Users\wxp\AppData\Local\Temp\ccx0grR6.s > ignoring nonexistent directory > "/mingw/mingw/lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../include" > ignoring duplicate directory > "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/include" > ignoring duplicate directory > "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/include-fixed" > ignoring duplicate directory > "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../x86_64-w64-mingw32/include" > ignoring nonexistent directory "/mingw/mingw/include64" > #include "..." search starts here: > #include <...> search starts here: > e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/include > e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/include-fixed > e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../x86_64-w64-mingw32/include > End of search list. > GNU C (x86_64-w64-mingw32-dw2) version 4.4.1 (x86_64-w64-mingw32) > compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version > 2.4.1. > GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 > Compiler executable checksum: b3c2d96f3e25147e506677ead914124d > COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' > " > gcc.exe: CreateProcess: No such file or directory > > ------ > $ x86_64-w64-mingw32-gcc -v -c hello.c > Using built-in specs. > Target: x86_64-w64-mingw32 > Configured with: /home/slack/gcc/gcc-4.4.1/configure --with-sysroot=/mingw > --host=x86_64-w64-mingw32 --build=i486-slackware-linux > --target=x86_64-w64-mingw32 --prefix=/mingw --disable-shared --disable-nls > --disable-debug --with-gcc --with-gnu-as --with-gnu-ld > --enable-languages=c,c++ --disable-win32-registry --disable-werror > --disable-symvers --disable-sjlj-exceptions --enable-threads > --enable-fully-dynamic-string --enable-version-specific-runtime-libs > --enable-cxx-flags='-fno-function-sections -fno-data-sections' > --with-mpfr=/home/slack/usr/win64 --with-gmp=/home/slack/usr/win64 > --with-ppl=/home/slack/usr/win64 --with-cloog=/home/slack/usr/win64 > --with-pkgversion=x86_64-w64-mingw32-dw2 --with-host-libstdcxx=-lstdc++ > --with-dwarf2 --disable-multilib > Thread model: win32 > gcc version 4.4.1 (x86_64-w64-mingw32-dw2) > COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' > e:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.4.1/cc1.exe -quiet -v > -iprefix e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/ hello.c -quiet > -dumpbase hello.c -mtune=generic -auxbase hello -version -o > C:\Users\wxp\AppData\Local\Temp\ccZxdIWh.s > ignoring nonexistent directory > "/mingw/mingw/lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../include" > ignoring duplicate directory > "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/include" > ignoring duplicate directory > "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/include-fixed" > ignoring duplicate directory > "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../x86_64-w64-mingw32/include" > ignoring nonexistent directory "/mingw/mingw/include64" > #include "..." search starts here: > #include <...> search starts here: > e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/include > e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/include-fixed > e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../x86_64-w64-mingw32/include > End of search list. > GNU C (x86_64-w64-mingw32-dw2) version 4.4.1 (x86_64-w64-mingw32) > compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version > 2.4.1. > GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 > Compiler executable checksum: b3c2d96f3e25147e506677ead914124d > COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' > " > x86_64-w64-mingw32-gcc.exe: CreateProcess: No such file or directory > > -- > It does not seem to be working on Vista x64 SP2, may be this is related to > previous problem? > Is there a problem in the source code you just updated bugged fstat64 ? > I recompiled the cross compiler and native compiler just to check if it is a > problem in the build process. > > Regards. Please CC the mailing list so that others may be able to help, too. For this particular case, I had this once, too, so it needn't be a build system problem. But I haven't been using a native compiler for quite some time, so let's see what others have to say. -- Ozkan |
From: Kai T. <kti...@go...> - 2009-08-22 07:08:16
|
2009/8/22 Ozkan Sezer <se...@gm...>: >>> I am glad that it fixes your case, and please feel free to report >>> any further issues. As I said, we're working further on additional >>> problems related to this. >>> >>> Cheers. >>> >>> >> >> Hi, >> Just to follow up on that native compiler that I cross compiled it from >> linux. >> It does run but only half way. here's the complete error message of what >> happens when I try to compile hello.c >> >> $ gcc -v -c hello.c >> Using built-in specs. >> Target: x86_64-w64-mingw32 >> Configured with: /home/slack/gcc/gcc-4.4.1/configure --with-sysroot=/mingw >> --host=x86_64-w64-mingw32 --build=i486-slackware-linux >> --target=x86_64-w64-mingw32 --prefix=/mingw --disable-shared --disable-nls >> --disable-debug --with-gcc --with-gnu-as --with-gnu-ld >> --enable-languages=c,c++ --disable-win32-registry --disable-werror >> --disable-symvers --disable-sjlj-exceptions --enable-threads >> --enable-fully-dynamic-string --enable-version-specific-runtime-libs >> --enable-cxx-flags='-fno-function-sections -fno-data-sections' >> --with-mpfr=/home/slack/usr/win64 --with-gmp=/home/slack/usr/win64 >> --with-ppl=/home/slack/usr/win64 --with-cloog=/home/slack/usr/win64 >> --with-pkgversion=x86_64-w64-mingw32-dw2 --with-host-libstdcxx=-lstdc++ >> --with-dwarf2 --disable-multilib >> Thread model: win32 >> gcc version 4.4.1 (x86_64-w64-mingw32-dw2) >> COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' >> e:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.4.1/cc1.exe -quiet -v >> -iprefix e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/ hello.c -quiet >> -dumpbase hello.c -mtune=generic -auxbase hello -version -o >> C:\Users\wxp\AppData\Local\Temp\ccx0grR6.s >> ignoring nonexistent directory >> "/mingw/mingw/lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../include" >> ignoring duplicate directory >> "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/include" >> ignoring duplicate directory >> "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/include-fixed" >> ignoring duplicate directory >> "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../x86_64-w64-mingw32/include" >> ignoring nonexistent directory "/mingw/mingw/include64" >> #include "..." search starts here: >> #include <...> search starts here: >> e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/include >> e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/include-fixed >> e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../x86_64-w64-mingw32/include >> End of search list. >> GNU C (x86_64-w64-mingw32-dw2) version 4.4.1 (x86_64-w64-mingw32) >> compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version >> 2.4.1. >> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 >> Compiler executable checksum: b3c2d96f3e25147e506677ead914124d >> COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' >> " >> gcc.exe: CreateProcess: No such file or directory >> >> ------ >> $ x86_64-w64-mingw32-gcc -v -c hello.c >> Using built-in specs. >> Target: x86_64-w64-mingw32 >> Configured with: /home/slack/gcc/gcc-4.4.1/configure --with-sysroot=/mingw >> --host=x86_64-w64-mingw32 --build=i486-slackware-linux >> --target=x86_64-w64-mingw32 --prefix=/mingw --disable-shared --disable-nls >> --disable-debug --with-gcc --with-gnu-as --with-gnu-ld >> --enable-languages=c,c++ --disable-win32-registry --disable-werror >> --disable-symvers --disable-sjlj-exceptions --enable-threads >> --enable-fully-dynamic-string --enable-version-specific-runtime-libs >> --enable-cxx-flags='-fno-function-sections -fno-data-sections' >> --with-mpfr=/home/slack/usr/win64 --with-gmp=/home/slack/usr/win64 >> --with-ppl=/home/slack/usr/win64 --with-cloog=/home/slack/usr/win64 >> --with-pkgversion=x86_64-w64-mingw32-dw2 --with-host-libstdcxx=-lstdc++ >> --with-dwarf2 --disable-multilib >> Thread model: win32 >> gcc version 4.4.1 (x86_64-w64-mingw32-dw2) >> COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' >> e:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.4.1/cc1.exe -quiet -v >> -iprefix e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/ hello.c -quiet >> -dumpbase hello.c -mtune=generic -auxbase hello -version -o >> C:\Users\wxp\AppData\Local\Temp\ccZxdIWh.s >> ignoring nonexistent directory >> "/mingw/mingw/lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../include" >> ignoring duplicate directory >> "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/include" >> ignoring duplicate directory >> "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/include-fixed" >> ignoring duplicate directory >> "e:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../x86_64-w64-mingw32/include" >> ignoring nonexistent directory "/mingw/mingw/include64" >> #include "..." search starts here: >> #include <...> search starts here: >> e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/include >> e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/include-fixed >> e:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.4.1/../../../../x86_64-w64-mingw32/include >> End of search list. >> GNU C (x86_64-w64-mingw32-dw2) version 4.4.1 (x86_64-w64-mingw32) >> compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version >> 2.4.1. >> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 >> Compiler executable checksum: b3c2d96f3e25147e506677ead914124d >> COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' >> " >> x86_64-w64-mingw32-gcc.exe: CreateProcess: No such file or directory >> >> -- >> It does not seem to be working on Vista x64 SP2, may be this is related to >> previous problem? >> Is there a problem in the source code you just updated bugged fstat64 ? >> I recompiled the cross compiler and native compiler just to check if it is a >> problem in the build process. >> >> Regards. > > Please CC the mailing list so that others may be > able to help, too. For this particular case, I had > this once, too, so it needn't be a build system > problem. But I haven't been using a native > compiler for quite some time, so let's see what > others have to say. > > -- > Ozkan > Hello, I hoped this issue was solved by recent modification to fstat/stat, but sadly it doesn't seem so. To fix this driver bug (and it is a driver bug only AFAIK), use for building gcc, g++, gfortan, etc for CFLAGS=-O0 This solves this issue. The question here is what produces the issue here. Maybe you could add to gcc's build the option -Wstrict-aliasing=2 option, too (for -O2 build) and check if there are any new strict aliasing failures are shown. Best regards Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: <t6...@gm...> - 2009-08-23 06:54:33
|
t6...@gm... wrote: > Kai Tietz wrote: >> 2009/8/22 Ozkan Sezer <se...@gm...>: >> Hello, >> >> I hoped this issue was solved by recent modification to fstat/stat, >> but sadly it doesn't seem so. To fix this driver bug (and it is a >> driver bug only AFAIK), use for building gcc, g++, gfortan, etc for >> CFLAGS=-O0 >> This solves this issue. The question here is what produces the issue >> here. Maybe you could add to gcc's build the option >> -Wstrict-aliasing=2 option, too (for -O2 build) and check if there are >> any new strict aliasing failures are shown. >> >> Best regards >> Kai >> >> > > >From line 813 libiberty/pex-win32.c > /* Create the child process. */ pid = win32_spawn (executable, > (flags & PEX_SEARCH) != 0, > argv, env, dwCreationFlags, &si, &pi); > if (pid == (pid_t) -1) > pid = spawn_script (executable, argv, env, dwCreationFlags, > &si, &pi); > if (pid == (pid_t) -1) > { > *err = ENOENT; > *errmsg = "CreateProcess"; > } > > > This is where it started to failed apparently ... > > > There's a use of a function "alloca" in the win32_spawn() but this is just a guess. I also compiled target = host = x86_64-w64-mingw32 compiler with -O0 as you suggested, indeed it worked on Vista 64bit. I also compiled native compiler target = x86_64-w64-mingw32, host = mingw32 and without the -O0 it does not have any trouble in "CreateProcess" running on Vista 64-bit, so this bug is specific to the gcc (w64 64-Bit binary). Hopefully this may be of some interest when someone does hunt down this bug. Thanks. Regards. |