Re: [Mingw-w64-public] Help building a win64 native compiler from Linux
t66...@gmail.com wrote:
Kai Tietz wrote:
2009/8/22 Ozkan Sezer seze...@gmail.com:
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.
--
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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Help building a win64 native compiler from Linux
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
Re: [Mingw-w64-public] Help building a win64 native compiler from Linux
On Fri, Aug 21, 2009 at 10:42 AM, Ozkan Sezerseze...@gmail.com wrote:
On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietzktiet...@googlemail.com wrote:
2009/8/21 t66...@gmail.com t66...@gmail.com:
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
Mingw-w64-public@lists.sourceforge.net
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
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report
Re: [Mingw-w64-public] Help building a win64 native compiler from Linux
2009/8/21 Ozkan Sezer seze...@gmail.com: On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietzktiet...@googlemail.com wrote: 2009/8/21 t66...@gmail.com t66...@gmail.com: 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 Mingw-w64-public@lists.sourceforge.net 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 -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Help building a win64 native compiler from Linux
2009/8/21 Ozkan Sezer seze...@gmail.com:
On Fri, Aug 21, 2009 at 10:42 AM, Ozkan Sezerseze...@gmail.com wrote:
On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietzktiet...@googlemail.com wrote:
2009/8/21 t66...@gmail.com t66...@gmail.com:
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
Mingw-w64-public@lists.sourceforge.net
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
Re: [Mingw-w64-public] Help building a win64 native compiler from Linux
On Fri, Aug 21, 2009 at 10:57 AM, Kai Tietzktiet...@googlemail.com wrote: 2009/8/21 Ozkan Sezer seze...@gmail.com: On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietzktiet...@googlemail.com wrote: 2009/8/21 t66...@gmail.com t66...@gmail.com: 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 Mingw-w64-public@lists.sourceforge.net 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..) -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Help building a win64 native compiler from Linux
2009/8/21 Ozkan Sezer seze...@gmail.com: On Fri, Aug 21, 2009 at 10:57 AM, Kai Tietzktiet...@googlemail.com wrote: 2009/8/21 Ozkan Sezer seze...@gmail.com: On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietzktiet...@googlemail.com wrote: 2009/8/21 t66...@gmail.com t66...@gmail.com: 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 Mingw-w64-public@lists.sourceforge.net 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 -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Help building a win64 native compiler from Linux
On Fri, Aug 21, 2009 at 9:58 AM, t66...@gmail.comt66...@gmail.com 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. -- 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
