Re: [Mingw-w64-public] Linking against msvcrt90

[Ozkan Sezer]

On Fri, Aug 14, 2009 at 7:48 PM, Kai Tietz wrote:
> 2009/8/14 NightStrike :
>> On Sat, Jun 27, 2009 at 11:41 PM, David Cournapeau wrote:
>>> Hi,
>>>
>>> I am building a plugin (dll) for a software built with VS 2008, which
>>> linked against the msvcrt90.dll. I am building the plugin with
>>> mingw-w64, and would like to build it such as it is guaranteed that it
>>> uses the same CRT as the main program. Is this possible, assuming I
>>> know the exact version of the msvcrt90.dll ? Up to now, I was building
>>> the import lib as follows (copied from somewhere, maybe mingw32
>>> sources):
>>>
>>> PATH=/cygdive/c/Mingw-w64/bin:$PATH
>>> gcc -DRUNTIME=msvcr90 -D__msvcr90__=1 -D__MSVCRT__ -C -E -P -xc-header
>>> msvcrt.def.in > msvcr90.def
>>> dlltool --as=as -k --dllname msvcr90.dll --output-lib libmsvcr90.a
>>> --def msvcr90.def
>>> for key in printf fprintf sprintf vprintf vfprintf vsprintf; do
>>>          src=`nm libmsvcr90.a | sed -n -e '/:$/h;/^[0-7][0-7]*  *T
>>> */{s///;H;g;s/\n//p' -e '}' | sed -n 's/:_'"$key"'$//p'`;
>>>          if test -n "$src"; then
>>>            dst=`echo "$src" | sed 's/0/4/'`; repl="$repl $dst";
>>>            tmpfiles="$tmpfiles $src $dst";
>>>            ar x libmsvcr90.a $src;
>>>            objcopy --redefine-sym _$key=___msvcrt_$key \
>>>              --redefine-sym __imp__$key=__impmsvcrt_$key \
>>>              $src $dst;
>>>          fi;
>>> done;
>>> test `key=_get_output_format; nm libmsvcr90.a | sed -n -e
>>> '/:$/h;/^[0-7][0-7]*  *T  */{s///;H;g;s/\n//p' -e '}' | sed -n
>>> 's/:_'"$key"'$//p'` || repl="$repl ofmt_stub.o";
>>> test -n "$repl" && ar rcs libmsvcr90.a $repl;
>>> rm -f $tmpfiles
>>>
>>> But it seems that it does not work, in the sense that passing objects
>>> across dll boundaries crashes. Is there a better way ?
>>
>> Sorry for the delay in answering you.  Are you still having difficulties?
>>
>> --
>> 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
>>
>
> Yes, sorry for this delayed answer. You can specify at link time of
> your executable -lmvcr90. Sadly we don't provide at the moment a
> library for msvcr90,dll. But you can generate the .def file for by
> using the gendef tool (to be found in our experimental tree
> /experimental/tools/gendef). If you sent us the generated msvcr90.def
> file, we will happily add it to our generated libraries.
>
> Best regards,
> Kai

If I understand you correctly, you are already generating msvrt90.def
and using it to build the necessary *.a file, but your dll file
crashes when used along with a MSVC-compiled *.exe or dll, is this
correct?  If yes,  did you build the mingw-w64 CRT using
-mms-bitfields flag?

--
Ozkan

--
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] Linking against msvcrt90

[Ozkan Sezer]

On Sat, Aug 15, 2009 at 5:14 AM, David Cournapeau wrote:
> On Fri, Aug 14, 2009 at 10:20 AM, Ozkan Sezer wrote:
>> On Fri, Aug 14, 2009 at 7:48 PM, Kai Tietz wrote:
>>> 2009/8/14 NightStrike :
>>>> On Sat, Jun 27, 2009 at 11:41 PM, David Cournapeau 
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I am building a plugin (dll) for a software built with VS 2008, which
>>>>> linked against the msvcrt90.dll. I am building the plugin with
>>>>> mingw-w64, and would like to build it such as it is guaranteed that it
>>>>> uses the same CRT as the main program. Is this possible, assuming I
>>>>> know the exact version of the msvcrt90.dll ? Up to now, I was building
>>>>> the import lib as follows (copied from somewhere, maybe mingw32
>>>>> sources):
>>>>>
>>>>> PATH=/cygdive/c/Mingw-w64/bin:$PATH
>>>>> gcc -DRUNTIME=msvcr90 -D__msvcr90__=1 -D__MSVCRT__ -C -E -P -xc-header
>>>>> msvcrt.def.in > msvcr90.def
>>>>> dlltool --as=as -k --dllname msvcr90.dll --output-lib libmsvcr90.a
>>>>> --def msvcr90.def
>>>>> for key in printf fprintf sprintf vprintf vfprintf vsprintf; do
>>>>>          src=`nm libmsvcr90.a | sed -n -e '/:$/h;/^[0-7][0-7]*  *T
>>>>> */{s///;H;g;s/\n//p' -e '}' | sed -n 's/:_'"$key"'$//p'`;
>>>>>          if test -n "$src"; then
>>>>>            dst=`echo "$src" | sed 's/0/4/'`; repl="$repl $dst";
>>>>>            tmpfiles="$tmpfiles $src $dst";
>>>>>            ar x libmsvcr90.a $src;
>>>>>            objcopy --redefine-sym _$key=___msvcrt_$key \
>>>>>              --redefine-sym __imp__$key=__impmsvcrt_$key \
>>>>>              $src $dst;
>>>>>          fi;
>>>>> done;
>>>>> test `key=_get_output_format; nm libmsvcr90.a | sed -n -e
>>>>> '/:$/h;/^[0-7][0-7]*  *T  */{s///;H;g;s/\n//p' -e '}' | sed -n
>>>>> 's/:_'"$key"'$//p'` || repl="$repl ofmt_stub.o";
>>>>> test -n "$repl" && ar rcs libmsvcr90.a $repl;
>>>>> rm -f $tmpfiles
>>>>>
>>>>> But it seems that it does not work, in the sense that passing objects
>>>>> across dll boundaries crashes. Is there a better way ?
>>>>
>>>> Sorry for the delay in answering you.  Are you still having difficulties?
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>> Yes, sorry for this delayed answer. You can specify at link time of
>>> your executable -lmvcr90. Sadly we don't provide at the moment a
>>> library for msvcr90,dll. But you can generate the .def file for by
>>> using the gendef tool (to be found in our experimental tree
>>> /experimental/tools/gendef). If you sent us the generated msvcr90.def
>>> file, we will happily add it to our generated libraries.
>>>
>>> Best regards,
>>> Kai
>>
>> If I understand you correctly, you are already generating msvrt90.def
>> and using it to build the necessary *.a file, but your dll file
>> crashes when used along with a MSVC-compiled *.exe or dll, is this
>> correct?  If yes,  did you build the mingw-w64 CRT using
>> -mms-bitfields flag?
>
> No, I will try this. I gave up on mingw-w64 because of this problem,
> actually. Do I need to build only the runtime with -mms-bitfields, or
> the native compilers as well ?
>
> David
>

As far as I know, building the runtime with that flag should
be enough.  We would be very interested to hear your
results.

--
Ozkan

--
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] [PATCH] Add warning flags to CRT build

[Ozkan Sezer]

On Mon, Aug 17, 2009 at 10:49 AM, JonY<10wa...@gmail.com> wrote:
> Hi,
>
> This patch will add warning flags.
>
> There are currently 5 warning levels, which defaults to level 3. It gets
> noisier for higher levels. Level 0 is equivalent to no additional flags. Use
> "--with-warnings[=n]" to set the levels.
>
> I really wanted -Werror by default, so you can stop to see *all* the
> warnings, but its too strict for buildbot.
>
> The warning levels can still be fine tuned. If needed, there can also be
> more warning levels.
>
> Comments?

This is a good one. I'd also suggest that you remove the
default -Wno-strict-aliasing flag from Makefile.am. And also
yocan increase the -Wstrict-aliasing level with increased
level of warning to -Wstrict-aliasing=2, say at level four?

--
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

[Ozkan Sezer]

On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietz wrote:
> 2009/8/21 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

--
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

[Ozkan Sezer]

On Fri, Aug 21, 2009 at 10:42 AM, Ozkan Sezer wrote:
> On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietz wrote:
>> 2009/8/21 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 
|#include 
|#include 
|
| 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 version

Re: [Mingw-w64-public] Help building a win64 native compiler from Linux

[Ozkan Sezer]

On Fri, Aug 21, 2009 at 10:57 AM, Kai Tietz wrote:
> 2009/8/21 Ozkan Sezer :
>> On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietz wrote:
>>> 2009/8/21 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

[Ozkan Sezer]

On Fri, Aug 21, 2009 at 9:58 AM, t66...@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

Re: [Mingw-w64-public] Help building a win64 native compiler from Linux

[Ozkan Sezer]

On Fri, Aug 21, 2009 at 1:28 PM, t66...@gmail.com wrote:
> Ozkan Sezer wrote:
>
> On Fri, Aug 21, 2009 at 9:58 AM, t66...@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.
>
>
>
> 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.

--
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

[Ozkan Sezer]

>> 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)
> 

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Thu, Sep 17, 2009 at 5:55 AM, Erik de Castro Lopo
 wrote:
> Hi all,
>
> I'm using mingw-w64-bin_i686-linux_20090612.tar.bz2 which is the latest
> I can find and running into problems compiling stuff like:
>
>    printf ("Bad file length (%" PRId64 " should be %zd).\n", retval, sizeof 
> (data_out)) ;
>
> The code works correctly for standard modern gccs on Linux systems
> and in the Ubuntu Linux -> mingw32 cross compiler.
>
> However, for the Linux -> mingw-win64 cross compiler I get:
>
>    test.c:135:2: error: unknown conversion type character 'z' in format
>    test.c:135:2: error: too many arguments for format
>
> In all of the above I am compiling with -std=gnu99.
>
> It would be really nice it this could be fixed.
>
> Cheers,
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/

I'm not sure whether msvcrt supports the %z size_t conversion.
You can, however, use the posix compliant mingw version.  You
can do it by either of these two ways:

1.  You can compile your source with the __USE_MINGW_ANSI_STDIO
macro defined as 1,  adding -D__USE_MINGW_ANSI_STDIO=1 to your
gcc command line.  This way, all printf family of functions will
be relaced by __mingw_printf, __mingw_fprintf, etc.

2.  Or, you can explicitly use __mingw_printf at the specific
places that is required.

Hope this helps.

--
Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Fri, Sep 18, 2009 at 1:14 AM, Erik de Castro Lopo
 wrote:
> Ozkan Sezer wrote:
>
>> I'm not sure whether msvcrt supports the %z size_t conversion.
>
> I'm pretty damn sure it doesn't :-).
>
>> You can, however, use the posix compliant mingw version.
>
> Its not POSIX, its  ISO C99 :-).
>
>> You can do it by either of these two ways:
>>
>> 1.  You can compile your source with the __USE_MINGW_ANSI_STDIO
>> macro defined as 1,  adding -D__USE_MINGW_ANSI_STDIO=1 to your
>> gcc command line.  This way, all printf family of functions will
>> be relaced by __mingw_printf, __mingw_fprintf, etc.
>
> I tried putting:
>
>   #define __USE_MINGW_ANSI_STDIO 1
>
> as the very first non-comment line of the file in questions and I still
> get:
>
>   test_file_io.c:136: error: unknown conversion type character 'z' in format
>   test_file_io.c:136: error: too many arguments for format
>
> If I replace that printf with __mingw_printf I get:
>
>   test_file_io.c:136: error: implicit declaration of function '__mingw_printf'
>   test_file_io.c:136: error: nested extern declaration of '__mingw_printf'
>
> Erik

Do you  #include   ?
If you do, then I'm baffled..

--
Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Sat, Sep 19, 2009 at 1:12 AM, Erik de Castro Lopo
 wrote:
>    Using built-in specs.
>    Target: x86_64-w64-mingw32
>    Configured with: ../../../build/gcc/gcc/configure 
> --target=x86_64-w64-mingw32
>       --prefix=/Testing/build/root --with-sysroot=/Testing/build/root
>      --enable-languages=all,obj-c++ --enable-fully-dynamic-string 
> --disable-multilib
>    Thread model: win32
>    gcc version 4.5.0 20090918 (experimental) (GCC)
>
> but I'm still getting:
>
>    test.c:135:2: error: unknown conversion type character 'z' in format
>    test.c:135:2: error: too many arguments for format

- Which svn revision of mingw-w64 headers and crt did you
use in your toolchain ?

- Contents of test.c (cat test.c), at least the relevant parts of it
including the headers you include and macros you define that
would affect things ?

- Your exact command line for compiling test.c ?

--
Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Sat, Sep 19, 2009 at 9:20 AM, Erik de Castro Lopo
 wrote:
> Ozkan Sezer wrote:
>
>> - Which svn revision of mingw-w64 headers and crt did you
>> use in your toolchain ?
>
> Same revision for both :
>
>    Path: .
>    URL: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk
>    Repository Root: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64
>    Repository UUID: 4407c894-4637-0410-b4f5-ada5f102cad1
>    Revision: 1375
>    Node Kind: directory
>    Schedule: normal
>    Last Changed Author: ktietz70
>    Last Changed Rev: 1375
>    Last Changed Date: 2009-09-18 17:08:14 +1000 (Fri, 18 Sep 2009)
>
>> - Contents of test.c (cat test.c), at least the relevant parts of it
>> including the headers you include and macros you define that
>> would affect things ?
>
> Well that test.c was a bit big, but this little snippet hits the same
> problem:
>
>  #include 
>  #include 
>  int main (void)
>  {   int64_t big_number = 1LL << 34 ;
>      big_number *= 1027LL ;
>      printf ("%-12" PRId64 "   %zd\n", big_number, sizeof (big_number)) ;
>      return 0 ;
>  }
>
>> - Your exact command line for compiling test.c ?
>
>    x86_64-w64-mingw32-gcc -Wall -std=gnu99 test.c -o test
>
> Erik

Hmm, with my versions gcc-4.4.2 (svn r151768, patched but
nothing that would affect this) and mingw-w64 r1375-r1378,
I get:

x86_64-pc-mingw32-gcc -Wall -std=gnu99 test.c
test.c: In function 'main':
test.c:6: warning: unknown conversion type character 'z' in format
test.c:6: warning: too many arguments for format

Notice that it's not an 'error' but a warning.  How come you
get an error?  And if I add -D__USE_MINGW_ANSI_STDIO=1
to the command line, then I get no warnings at all.  Did you try
with -D__USE_MINGW_ANSI_STDIO=1 ?

--
Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Sat, Sep 19, 2009 at 11:02 AM, Erik de Castro Lopo
 wrote:
> Ozkan Sezer wrote:
>
>> Hmm, with my versions gcc-4.4.2 (svn r151768, patched but
>> nothing that would affect this) and mingw-w64 r1375-r1378,
>> I get:
>>
>> x86_64-pc-mingw32-gcc -Wall -std=gnu99 test.c
>> test.c: In function 'main':
>> test.c:6: warning: unknown conversion type character 'z' in format
>> test.c:6: warning: too many arguments for format
>>
>> Notice that it's not an 'error' but a warning.  How come you
>> get an error?
>
> Quite honestly, I think an unknown conversion type should be an
> error. The compiler is saying it doesn't understand the format
> conversion so it is almost certainly not going to do  the right
> thing.
>
>>  And if I add -D__USE_MINGW_ANSI_STDIO=1
>> to the command line, then I get no warnings at all.  Did you try
>> with -D__USE_MINGW_ANSI_STDIO=1 ?
>
> Yes, that fixes it. How come I have to use that for the w64 cross
> compiler but I don't need it for the w32 cross compiler?
>

You need it with both.  (Although, if your w32 toolchain is
a mingw.org toolchain and not ours, they may have automatically
defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99.  Kai,
should we do that?)

> Erik

--
Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Sat, Sep 19, 2009 at 1:13 PM, Erik de Castro Lopo
 wrote:
> Ozkan Sezer wrote:
>
>> You need it with both.  (Although, if your w32 toolchain is
>> a mingw.org toolchain and not ours, they may have automatically
>> defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99.  Kai,
>> should we do that?)
>
> Yes, please!
>
> Cheers,
> Erik
> --

Hmm this is what the mingw.org guys do in their _mingw.h:

#ifndef __USE_MINGW_ANSI_STDIO
/*
 * If user didn't specify it explicitly...
 */
# if   defined __STRICT_ANSI__  ||  defined _ISOC99_SOURCE \
   ||  defined _POSIX_SOURCE||  defined _POSIX_C_SOURCE \
   ||  defined _XOPEN_SOURCE||  defined _XOPEN_SOURCE_EXTENDED \
   ||  defined _GNU_SOURCE  ||  defined _BSD_SOURCE \
   ||  defined _SVID_SOURCE
   /*
* but where any of these source code qualifiers are specified,
* then assume ANSI I/O standards are preferred over Microsoft's...
*/
#  define __USE_MINGW_ANSI_STDIO1
# endif
#endif

(FWIW, we can also check for _POSIX for consistency with
other parts of our headers, too.)

Kai, we can add it to our _mingw.h, too.  What do you think?
Can this kind of thing cause any incompatibilities when a
piece of software is compiled with -std=c99 or -std=gnu99 ?

--
Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Sat, Sep 19, 2009 at 1:38 PM, Kai Tietz  wrote:
> Ok, add it to our _mingw.h file, too. We can then simplify our logic

Will do.

> in our _mingw_printf_(push/pop).h headers, too, as we know that
> __USE_MINGW_ANSI_STDIO is defined in any case to zero or one, isn't
> it?

If you are referring to the rev. 1377 change, I wouldn't rely
on it being definitely defined as 0 or 1.  User may be buggy
and would just do -D__USE_MINGW_ANSI_STDIO without
an =0 or =1, would he not?

>
> Cheers,
> Kai

--
Ozkan

> 2009/9/19 Ozkan Sezer :
>> On Sat, Sep 19, 2009 at 1:13 PM, Erik de Castro Lopo
>>  wrote:
>>> Ozkan Sezer wrote:
>>>
>>>> You need it with both.  (Although, if your w32 toolchain is
>>>> a mingw.org toolchain and not ours, they may have automatically
>>>> defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99.  Kai,
>>>> should we do that?)
>>>
>>> Yes, please!
>>>
>>> Cheers,
>>> Erik
>>> --
>>
>> Hmm this is what the mingw.org guys do in their _mingw.h:
>>
>> #ifndef __USE_MINGW_ANSI_STDIO
>> /*
>>  * If user didn't specify it explicitly...
>>  */
>> # if   defined __STRICT_ANSI__  ||  defined _ISOC99_SOURCE \
>>   ||  defined _POSIX_SOURCE    ||  defined _POSIX_C_SOURCE \
>>   ||  defined _XOPEN_SOURCE    ||  defined _XOPEN_SOURCE_EXTENDED \
>>   ||  defined _GNU_SOURCE      ||  defined _BSD_SOURCE \
>>   ||  defined _SVID_SOURCE
>>   /*
>>    * but where any of these source code qualifiers are specified,
>>    * then assume ANSI I/O standards are preferred over Microsoft's...
>>    */
>> #  define __USE_MINGW_ANSI_STDIO    1
>> # endif
>> #endif
>>
>> (FWIW, we can also check for _POSIX for consistency with
>> other parts of our headers, too.)
>>
>> Kai, we can add it to our _mingw.h, too.  What do you think?
>> Can this kind of thing cause any incompatibilities when a
>> piece of software is compiled with -std=c99 or -std=gnu99 ?
>>
>> --
>> Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

OK, applied this as rev. 1395:
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=rev&revision=1395
Please test.

--
Ozkan


On Sat, Sep 19, 2009 at 1:41 PM, Ozkan Sezer  wrote:
> On Sat, Sep 19, 2009 at 1:38 PM, Kai Tietz  wrote:
>> Ok, add it to our _mingw.h file, too. We can then simplify our logic
>
> Will do.
>
>> in our _mingw_printf_(push/pop).h headers, too, as we know that
>> __USE_MINGW_ANSI_STDIO is defined in any case to zero or one, isn't
>> it?
>
> If you are referring to the rev. 1377 change, I wouldn't rely
> on it being definitely defined as 0 or 1.  User may be buggy
> and would just do -D__USE_MINGW_ANSI_STDIO without
> an =0 or =1, would he not?
>
>>
>> Cheers,
>> Kai
>
> --
> Ozkan
>
>> 2009/9/19 Ozkan Sezer :
>>> On Sat, Sep 19, 2009 at 1:13 PM, Erik de Castro Lopo
>>>  wrote:
>>>> Ozkan Sezer wrote:
>>>>
>>>>> You need it with both.  (Although, if your w32 toolchain is
>>>>> a mingw.org toolchain and not ours, they may have automatically
>>>>> defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99.  Kai,
>>>>> should we do that?)
>>>>
>>>> Yes, please!
>>>>
>>>> Cheers,
>>>> Erik
>>>> --
>>>
>>> Hmm this is what the mingw.org guys do in their _mingw.h:
>>>
>>> #ifndef __USE_MINGW_ANSI_STDIO
>>> /*
>>>  * If user didn't specify it explicitly...
>>>  */
>>> # if   defined __STRICT_ANSI__  ||  defined _ISOC99_SOURCE \
>>>   ||  defined _POSIX_SOURCE    ||  defined _POSIX_C_SOURCE \
>>>   ||  defined _XOPEN_SOURCE    ||  defined _XOPEN_SOURCE_EXTENDED \
>>>   ||  defined _GNU_SOURCE      ||  defined _BSD_SOURCE \
>>>   ||  defined _SVID_SOURCE
>>>   /*
>>>    * but where any of these source code qualifiers are specified,
>>>    * then assume ANSI I/O standards are preferred over Microsoft's...
>>>    */
>>> #  define __USE_MINGW_ANSI_STDIO    1
>>> # endif
>>> #endif
>>>
>>> (FWIW, we can also check for _POSIX for consistency with
>>> other parts of our headers, too.)
>>>
>>> Kai, we can add it to our _mingw.h, too.  What do you think?
>>> Can this kind of thing cause any incompatibilities when a
>>> piece of software is compiled with -std=c99 or -std=gnu99 ?
>>>
>>> --
>>> Ozkan
>

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Sun, Sep 20, 2009 at 1:08 AM, Erik de Castro Lopo
 wrote:
> Ozkan Sezer wrote:
>
>> OK, applied this as rev. 1395:
>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=rev&revision=1395
>> Please test.
>
> Real close!
>
> I get the proper C99 behaviour if I compile with:
>
>     x86_64-w64-mingw32-gcc -Wall -std=c99 test.c -o test
>
> but with this:
>
>     x86_64-w64-mingw32-gcc -Wall -std=gnu99 test.c -o test
>
> I still get the same error. It would be nice if this could be fixed for
> gnu99 as well.
>
> Cheers,
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/

That is because with -std=c99, gcc predefines __STRICT_ANSI_,  but
with -std=gnu99 it does not, because gnu99 is not _strictly_ ansi and
includes gnu extensions.  The idea behind our commit rev. 1395 is
trying to catch ith implications of user's need of ansi i/o, and in
my opinion -std=gnu99 may not be in that category.  Please define
__USE_MINGW_ANSI_STDIO=1 for it.

Enabling the __mingw_printf family for both c99 and gnu99 mode is
actually easy, I would only add a  __STDC_VERSION__ >= 199901L
preprocessor check, but as I said I think it might not be right.
Kai, what do you think?

A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org
compiler for your w32 builds?  I think the warning may be a gcc-4.4+
thing and not actually a mingw-w64 issue, but I don't know for sure.

--
Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] makebuildroot.mk

[Ozkan Sezer]

On Sun, Sep 20, 2009 at 3:02 AM, Erik de Castro Lopo
 wrote:
> HI all,
>
> I've had a bit of a look at the makebuildroot.mk build script. It
> seems like this may be able to make both a win32  and a win64 cross
> compiler.
>
> Is that correct?
>
> Cheers,
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
>

Yes. Note that wi9x family may not be supported
with the win32 runtime, but all nt family is fine as far
as I know.

--
Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Sun, Sep 20, 2009 at 2:55 AM, Erik de Castro Lopo
 wrote:
>
> Please note, I am subscribed to the list. No need to CC me on reply.
>
> Ozkan Sezer wrote:
>
>> A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org
>> compiler for your w32 builds?  I think the warning may be a gcc-4.4+
>> thing and not actually a mingw-w64 issue, but I don't know for sure.
>
> Now that I've checked, it seems a little more complicated than I first
> thought.
>
> The mingw32 compiler that I'm using is the one from the Ubuntu 9.04
> mingw32 package. It reports its version as:
>
>    gcc version 4.2.1-sjlj (mingw32-2)
>
> This compiler JustWorks(tm) and accepts '%zd" in printf/snprintf as well
> as the other C99 format string stuff.
>

OK, looked at the mingw.org phovided gcc4.2.1-2 source
and they add windows specific format specifiers like %I32
in gcc/config/i386/mingw32.h but with a note like:

/* MSVCRT supports additional length specifiers for "printf".  (In
   fact, it does not support some of the C99 specifiers, like
   "ll".  However, we do not presently have a mechanism for disabling
   a specifier.)  */

4.4 was the version that ms-printf format support officially
went into gcc along with mechanisms catching what is OK
and what is not.

A note out of curiosity: Does your versions compiled by
gcc < 4.4 of mingw.org give correct output ?

> The mingw32 package on Debian Sid is:
>
>    gcc version 4.4.1 (GCC)
>
> and it too gives a warning on both c99 and gnu99.  For this compiler,
> not even -D__USE_MINGW_ANSI_STDIO=1 can fix it.
>
> Me, I'd just like to compile the one piece of source code on as many systems
> as possible without hacking it to bits with  #ifdefs. I'd  also like,
> where possible, to get the compiler using apt-get, instead of compling it
> myself.
>
> Erik
> --
> --
> Erik de Castro Lopo
> http://www.mega-nerd.com/
>

--
Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Sun, Sep 20, 2009 at 11:52 AM, Kai Tietz  wrote:
> To solve those kind of issues inttypes.h is there, and is btw also
> adjusted by our header-set when __USE_MINGW_ANSI_STDIO is defined. A
> mix mode between platform M$ printf formats and gnu'ish one is in
> general a bad idea.
>
> Kai
>

Should I commit this then:

Index: _mingw.h
===
--- _mingw.h(revision 1397)
+++ _mingw.h(working copy)
@@ -441,20 +441,10 @@
 #define _TRUNCATE ((size_t)-1)
 #endif

-#ifndef __USE_MINGW_ANSI_STDIO
-/* If user didn't specify it explicitly... */
-# if defined(__STRICT_ANSI__) || defined(_ISOC99_SOURCE)   \
-|| defined(_POSIX) \
-|| defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE)  \
-|| defined(_XOPEN_SOURCE) || defined(_XOPEN_SOURCE_EXTENDED)\
-|| defined(_GNU_SOURCE)   || defined(_BSD_SOURCE)  \
-|| defined(_SVID_SOURCE)
-   /*
-* but where any of these source code qualifiers are specified,
-* then assume ANSI I/O standards are preferred over Microsoft's...
-*/
+#if defined(_POSIX) && !defined(__USE_MINGW_ANSI_STDIO)
+/* Enable __USE_MINGW_ANSI_STDIO if _POSIX defined
+ * and If user did _not_ specify it explicitly... */
 #  define __USE_MINGW_ANSI_STDIO   1
-# endif
 #endif


--
Ozkan


> 2009/9/20 Kai Tietz :
>> 2009/9/20 Ozkan Sezer :
>>> On Sun, Sep 20, 2009 at 2:55 AM, Erik de Castro Lopo
>>>  wrote:
>>>>
>>>> Please note, I am subscribed to the list. No need to CC me on reply.
>>>>
>>>> Ozkan Sezer wrote:
>>>>
>>>>> A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org
>>>>> compiler for your w32 builds?  I think the warning may be a gcc-4.4+
>>>>> thing and not actually a mingw-w64 issue, but I don't know for sure.
>>>>
>>>> Now that I've checked, it seems a little more complicated than I first
>>>> thought.
>>>>
>>>> The mingw32 compiler that I'm using is the one from the Ubuntu 9.04
>>>> mingw32 package. It reports its version as:
>>>>
>>>>    gcc version 4.2.1-sjlj (mingw32-2)
>>>>
>>>> This compiler JustWorks(tm) and accepts '%zd" in printf/snprintf as well
>>>> as the other C99 format string stuff.
>>>>
>>>
>>> OK, looked at the mingw.org phovided gcc4.2.1-2 source
>>> and they add windows specific format specifiers like %I32
>>> in gcc/config/i386/mingw32.h but with a note like:
>>>
>>> /* MSVCRT supports additional length specifiers for "printf".  (In
>>>   fact, it does not support some of the C99 specifiers, like
>>>   "ll".  However, we do not presently have a mechanism for disabling
>>>   a specifier.)  */
>>>
>>> 4.4 was the version that ms-printf format support officially
>>> went into gcc along with mechanisms catching what is OK
>>> and what is not.
>>>
>>> A note out of curiosity: Does your versions compiled by
>>> gcc < 4.4 of mingw.org give correct output ?
>>>
>>>> The mingw32 package on Debian Sid is:
>>>>
>>>>    gcc version 4.4.1 (GCC)
>>>>
>>>> and it too gives a warning on both c99 and gnu99.  For this compiler,
>>>> not even -D__USE_MINGW_ANSI_STDIO=1 can fix it.
>>>>
>>>> Me, I'd just like to compile the one piece of source code on as many 
>>>> systems
>>>> as possible without hacking it to bits with  #ifdefs. I'd  also like,
>>>> where possible, to get the compiler using apt-get, instead of compling it
>>>> myself.
>>>>
>>>> Erik
>>>> --
>>>> --
>>>> Erik de Castro Lopo
>>>> http://www.mega-nerd.com/
>>>>
>>>
>>> --
>>> Ozkan
>>>
>>
>> As mingw.org doesn't use any printf formatter rules for their
>> redirected functions (which is IMHO a bug), they don't get warnings
>> for anything passed into this functions.
>> IMHO as more as I think about this feature, it should be turned on on
>> user demand by defining __USE_MINGW_ANSI_STDIO explicit. To turn it on
>> for some cX9 standards, or for __GNU_SOURCE, etc is misleading and a
>> mis-concept. We can automatically turn it on, if _POSIX is defined,
>> but the rest is just buggy.
>>
>> Cheers,
>> Kai

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Sun, Sep 20, 2009 at 12:00 PM, Kai Tietz  wrote:
> 2009/9/20 Ozkan Sezer :
>> On Sun, Sep 20, 2009 at 11:52 AM, Kai Tietz  wrote:
>>> To solve those kind of issues inttypes.h is there, and is btw also
>>> adjusted by our header-set when __USE_MINGW_ANSI_STDIO is defined. A
>>> mix mode between platform M$ printf formats and gnu'ish one is in
>>> general a bad idea.
>>>
>>> Kai
>>>
>>
>> Should I commit this then:
>>
>> Index: _mingw.h
>> ===
>> --- _mingw.h    (revision 1397)
>> +++ _mingw.h    (working copy)
>> @@ -441,20 +441,10 @@
>>  #define _TRUNCATE ((size_t)-1)
>>  #endif
>>
>> -#ifndef __USE_MINGW_ANSI_STDIO
>> -/* If user didn't specify it explicitly... */
>> -# if defined(__STRICT_ANSI__) || defined(_ISOC99_SOURCE)       \
>> -    || defined(_POSIX)                                         \
>> -    || defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE)      \
>> -    || defined(_XOPEN_SOURCE) || defined(_XOPEN_SOURCE_EXTENDED)\
>> -    || defined(_GNU_SOURCE)   || defined(_BSD_SOURCE)          \
>> -    || defined(_SVID_SOURCE)
>> -   /*
>> -    * but where any of these source code qualifiers are specified,
>> -    * then assume ANSI I/O standards are preferred over Microsoft's...
>> -    */
>> +#if defined(_POSIX) && !defined(__USE_MINGW_ANSI_STDIO)
>> +/* Enable __USE_MINGW_ANSI_STDIO if _POSIX defined
>> + * and If user did _not_ specify it explicitly... */
>>  #  define __USE_MINGW_ANSI_STDIO                       1
>> -# endif
>>  #endif
>>
>>
>> --
>> Ozkan
>>
>>
>>> 2009/9/20 Kai Tietz :
>>>> 2009/9/20 Ozkan Sezer :
>>>>> On Sun, Sep 20, 2009 at 2:55 AM, Erik de Castro Lopo
>>>>>  wrote:
>>>>>>
>>>>>> Please note, I am subscribed to the list. No need to CC me on reply.
>>>>>>
>>>>>> Ozkan Sezer wrote:
>>>>>>
>>>>>>> A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org
>>>>>>> compiler for your w32 builds?  I think the warning may be a gcc-4.4+
>>>>>>> thing and not actually a mingw-w64 issue, but I don't know for sure.
>>>>>>
>>>>>> Now that I've checked, it seems a little more complicated than I first
>>>>>> thought.
>>>>>>
>>>>>> The mingw32 compiler that I'm using is the one from the Ubuntu 9.04
>>>>>> mingw32 package. It reports its version as:
>>>>>>
>>>>>>    gcc version 4.2.1-sjlj (mingw32-2)
>>>>>>
>>>>>> This compiler JustWorks(tm) and accepts '%zd" in printf/snprintf as well
>>>>>> as the other C99 format string stuff.
>>>>>>
>>>>>
>>>>> OK, looked at the mingw.org phovided gcc4.2.1-2 source
>>>>> and they add windows specific format specifiers like %I32
>>>>> in gcc/config/i386/mingw32.h but with a note like:
>>>>>
>>>>> /* MSVCRT supports additional length specifiers for "printf".  (In
>>>>>   fact, it does not support some of the C99 specifiers, like
>>>>>   "ll".  However, we do not presently have a mechanism for disabling
>>>>>   a specifier.)  */
>>>>>
>>>>> 4.4 was the version that ms-printf format support officially
>>>>> went into gcc along with mechanisms catching what is OK
>>>>> and what is not.
>>>>>
>>>>> A note out of curiosity: Does your versions compiled by
>>>>> gcc < 4.4 of mingw.org give correct output ?
>>>>>
>>>>>> The mingw32 package on Debian Sid is:
>>>>>>
>>>>>>    gcc version 4.4.1 (GCC)
>>>>>>
>>>>>> and it too gives a warning on both c99 and gnu99.  For this compiler,
>>>>>> not even -D__USE_MINGW_ANSI_STDIO=1 can fix it.
>>>>>>
>>>>>> Me, I'd just like to compile the one piece of source code on as many 
>>>>>> systems
>>>>>> as possible without hacking it to bits with  #ifdefs. I'd  also like,
>>>>>> where possible, to get the compiler using apt-get, instead of compling it
>>>>>> myself.
>>>>>>
>>>>>> 

Re: [Mingw-w64-public] Printf %z format specifier?

[Ozkan Sezer]

On Sun, Sep 20, 2009 at 12:05 PM, Erik de Castro Lopo
 wrote:
> Ozkan Sezer wrote:
>
>> Should I commit this then:
>>
>> Index: _mingw.h
>> ===
>> --- _mingw.h  (revision 1397)
>> +++ _mingw.h  (working copy)
>> @@ -441,20 +441,10 @@
>>  #define _TRUNCATE ((size_t)-1)
>>  #endif
>>
>> -#ifndef __USE_MINGW_ANSI_STDIO
>> -/* If user didn't specify it explicitly... */
>> -# if defined(__STRICT_ANSI__) || defined(_ISOC99_SOURCE)     \
>> -    || defined(_POSIX)                                               \
>> -    || defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE)    \
>> -    || defined(_XOPEN_SOURCE) || defined(_XOPEN_SOURCE_EXTENDED)\
>> -    || defined(_GNU_SOURCE)   || defined(_BSD_SOURCE)                \
>> -    || defined(_SVID_SOURCE)
>> -   /*
>> -    * but where any of these source code qualifiers are specified,
>> -    * then assume ANSI I/O standards are preferred over Microsoft's...
>> -    */
>> +#if defined(_POSIX) && !defined(__USE_MINGW_ANSI_STDIO)
>> +/* Enable __USE_MINGW_ANSI_STDIO if _POSIX defined
>> + * and If user did _not_ specify it explicitly... */
>>  #  define __USE_MINGW_ANSI_STDIO                     1
>> -# endif
>>  #endif
>
>
> Yes, I can live with that.
>
> Cheers,
> Erik

In the svn, as rev. 1398.

--
Ozkan

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] WIA UUIDs for mingw-w64-crt.

[Ozkan Sezer]

On Fri, Oct 9, 2009 at 5:22 PM, Kai Tietz  wrote:
> Hello Wolfgang,
>
> 2009/10/4 Wolfgang Glas :
>> Hello Kia,
>>
>>  Thanks for applying ;-)
>>
>>  I found some time to think about the remaining problems, which you were 
>> unable
>> to push upstream like float.h, stddef.h header clash between mingw-w64-crt 
>> and
>> gcc or making -mms-bitfields default. IMHO I would be best to maintain a 
>> small
>> set of patches to gcc, which should be applied to a gcc tarball before 
>> building.
>>
>>  This solution is not very elegant, but it might help to convince the gcc
>> developers, that a patch, which is useful to many users should be applied to 
>> the
>> mainline dispite all concerns...
>
> To prepare such a patch and provide it as optional could be a way to
> solve this. But the experience has shown that such patches don't
> getting applied to mainline. So I have here some concerns about such a
> approach.
>
> Kai
>
> --
> |  (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination

Another way would be adding a mingw_branch to gcc branches svn.
Patches even applied upstream are being neglected and does not
get reviewed for backporting to 4.4-stable by the maintainers
these days.  So, it may serve both for such backports, as well
as for features which are being approached with reservations,
such as stddef.h & co.

--
Ozkan

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] WIA UUIDs for mingw-w64-crt.

[Ozkan Sezer]

On Fri, Oct 9, 2009 at 8:00 PM, NightStrike  wrote:
> On Fri, Oct 9, 2009 at 12:54 PM, Ozkan Sezer  wrote:
>> On Fri, Oct 9, 2009 at 5:22 PM, Kai Tietz  wrote:
>>> Hello Wolfgang,
>>>
>>> 2009/10/4 Wolfgang Glas :
>>>> Hello Kia,
>>>>
>>>>  Thanks for applying ;-)
>>>>
>>>>  I found some time to think about the remaining problems, which you were 
>>>> unable
>>>> to push upstream like float.h, stddef.h header clash between mingw-w64-crt 
>>>> and
>>>> gcc or making -mms-bitfields default. IMHO I would be best to maintain a 
>>>> small
>>>> set of patches to gcc, which should be applied to a gcc tarball before 
>>>> building.
>>>>
>>>>  This solution is not very elegant, but it might help to convince the gcc
>>>> developers, that a patch, which is useful to many users should be applied 
>>>> to the
>>>> mainline dispite all concerns...
>>>
>>> To prepare such a patch and provide it as optional could be a way to
>>> solve this. But the experience has shown that such patches don't
>>> getting applied to mainline. So I have here some concerns about such a
>>> approach.
>>>
>>> Kai
>>>
>>> --
>>> |  (\_/) This is Bunny. Copy and paste
>>> | (='.'=) Bunny into your signature to help
>>> | (")_(") him gain world domination
>>
>> Another way would be adding a mingw_branch to gcc branches svn.
>> Patches even applied upstream are being neglected and does not
>> get reviewed for backporting to 4.4-stable by the maintainers
>> these days.  So, it may serve both for such backports, as well
>> as for features which are being approached with reservations,
>> such as stddef.h & co.
>
> Creating our own gcc branch to support backports is definitely not
> where we want to go.  If someone goes through the trouble of
> backporting, the patches do get accepted.  It's just that people
> generally don't do it.  If you can find the time to put ti into some
> mingw special gcc branch, then it can go into 4.4 upstream.
>

See:
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02202.html
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00317.html

.. and remember that 4.4 is frozen at RC state.

> We do NOT want to be like mingw.org in this area -- **at all**.
>

Read what I said.  I suggesed a branch at gcc.gnu.org.  If
you don't like that, either, well, I disagree.

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] WIA UUIDs for mingw-w64-crt.

[Ozkan Sezer]

On Fri, Oct 9, 2009 at 8:21 PM, NightStrike  wrote:
> On Fri, Oct 9, 2009 at 1:17 PM, Ozkan Sezer  wrote:
>> On Fri, Oct 9, 2009 at 8:00 PM, NightStrike  wrote:
>>> On Fri, Oct 9, 2009 at 12:54 PM, Ozkan Sezer  wrote:
>>>> On Fri, Oct 9, 2009 at 5:22 PM, Kai Tietz  wrote:
>>>>> Hello Wolfgang,
>>>>>
>>>>> 2009/10/4 Wolfgang Glas :
>>>>>> Hello Kia,
>>>>>>
>>>>>>  Thanks for applying ;-)
>>>>>>
>>>>>>  I found some time to think about the remaining problems, which you were 
>>>>>> unable
>>>>>> to push upstream like float.h, stddef.h header clash between 
>>>>>> mingw-w64-crt and
>>>>>> gcc or making -mms-bitfields default. IMHO I would be best to maintain a 
>>>>>> small
>>>>>> set of patches to gcc, which should be applied to a gcc tarball before 
>>>>>> building.
>>>>>>
>>>>>>  This solution is not very elegant, but it might help to convince the gcc
>>>>>> developers, that a patch, which is useful to many users should be 
>>>>>> applied to the
>>>>>> mainline dispite all concerns...
>>>>>
>>>>> To prepare such a patch and provide it as optional could be a way to
>>>>> solve this. But the experience has shown that such patches don't
>>>>> getting applied to mainline. So I have here some concerns about such a
>>>>> approach.
>>>>>
>>>>> Kai
>>>>>
>>>>> --
>>>>> |  (\_/) This is Bunny. Copy and paste
>>>>> | (='.'=) Bunny into your signature to help
>>>>> | (")_(") him gain world domination
>>>>
>>>> Another way would be adding a mingw_branch to gcc branches svn.
>>>> Patches even applied upstream are being neglected and does not
>>>> get reviewed for backporting to 4.4-stable by the maintainers
>>>> these days.  So, it may serve both for such backports, as well
>>>> as for features which are being approached with reservations,
>>>> such as stddef.h & co.
>>>
>>> Creating our own gcc branch to support backports is definitely not
>>> where we want to go.  If someone goes through the trouble of
>>> backporting, the patches do get accepted.  It's just that people
>>> generally don't do it.  If you can find the time to put ti into some
>>> mingw special gcc branch, then it can go into 4.4 upstream.
>>>
>>
>> See:
>> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02202.html
>> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00317.html
>>
>> .. and remember that 4.4 is frozen at RC state.
>
> I didn't say it would be instant :)
>

Bravo.  It will be put behind a thousand times and
at that time gcc-4.5 will be the current "stable" with
its own bugs which will be fixed in 4.6 but being
neglected for backporting, a.s.o.  Do you see my
point at all?

>>> We do NOT want to be like mingw.org in this area -- **at all**.
>>>
>>
>> Read what I said.  I suggesed a branch at gcc.gnu.org.  If
>> you don't like that, either, well, I disagree.
>
> Yes, I realize that.  But a release branch at gcc is really not the
> way to go with this.  The real issue is in restoring our connections
> so that things are addressed in a timely fashion.
>
> Having two separate release branches, one that's special cased to a
> specific subset of targets, is just creating more dichotomy where it
> need not exist.
>
> Now that I am back, I will talk to the gcc maintainers to try to
> address the real underlying issue.
>

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] asm eror msg build crt with gcc44 branch

[Ozkan Sezer]

> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -m32 -pipe -std=gnu99
> -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked
> -Winline
> -Wimplicit-function-declaration -Wmissing-noreturn
> -Wmissing-prototypes -O3 -mms-bitfields -MT
> profile/lib32_libgmon_a-profil.o -MD -MP -MF
> profile/.deps/lib32_libgmon_a-profil.Tpo -c -o
> profile/lib32_libgmon_a-profil.o `test -f 'profile/profil.c' ||
> echo
> './'`profile/profil.c
> {standard input}: Assembler messages:
> {standard input}:8: Error: suffix or operands invalid for `push'
> {standard input}:46: Error: suffix or operands invalid for `pop'
> {standard input}:80: Error: suffix or operands invalid for `call'
> {standard input}:84: Error: suffix or operands invalid for `call'
> {standard input}:141: Error: suffix or operands invalid for
> `push'
> {standard input}:170: Error: suffix or operands invalid for `pop'
> {standard input}:175: Error: suffix or operands invalid for
> `push'
> {standard input}:177: Error: suffix or operands invalid for
> `push'
> {standard input}:178: Error: suffix or operands invalid for
> `push'
> {standard input}:200: Error: suffix or operands invalid for
> `call'
> {standard input}:207: Error: suffix or operands invalid for
> `push'
> {standard input}:245: Error: suffix or operands invalid for `pop'
> {standard input}:277: Error: suffix or operands invalid for
> `call'
> {standard input}:281: Error: suffix or operands invalid for
> `call'
> make[2]: *** [profile/lib32_libgmon_a-profil.o] Error 1
>
> Hello:
> the above error build with gcc-4_4-branch
> mingw-w64-cry
> I assue this is a gcc's bug?
>
>
>
> oh this is with building multilib oiption if it matters
>
>
>
> I don't understand, gcc was configured with multilib
> enable-targets=all,
> no error produced without m32 option this means gcc-4_4-branch
> does not
> support or binutils's problem?
> Anyone?
>
>
>
>
> Hi,
> there is a high chance that binutils wasn't configured for multilib,
> how did you configure binutils?
>
>
> It was configured with :
> --enable-multilib
> --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32
> objdump --help show this
> objdump: supported targets: pe-x86-64 pei-x86-64 elf64-x86-64
> elf64-l1om elf64-little elf64-big elf32-little elf32-big pe-i386
> pei-i386 elf32-i386 srec symbolsrec verilog tekhex binary ihex
> objdump: supported architectures: i386 i386:x86-64 i8086 i386:intel
> i386:x86-64:intel l1om l1om:intel
> I read "http://www.cadforte.com/wiki/index.php/How_to_build"; and
> pretty much followed the instructions.
> objdump on this object file which was compiled successfully
> lib32_libm_a-_libm_dummy.o: file format pe-x86-64
>
>
>
> Also ld --help output correctly showing
> ld: supported targets: pe-x86-64 pei-x86-64 elf64-x86-64 elf64-l1om
> elf64-little elf64-big elf32-little elf32-big pe-i386 pei-i386
> elf32-i386 srec symbolsrec verilog tekhex binary ihex
> ld: supported emulations: i386pep i386pe
>
> Is there something wrong with my build or gcc or mingw-w64-crt?
>
> What's the real difference between pe-x86-64 pei-x86-64?
>
>
>
> Hi,
>
> I've just built the crt a few days ago without issues. PE and PEI are
> the executable format and object format used on Windows.
>
> It really looks like the assembler is not able to understand 32bit
> asm. BTW, ld != x86_64-w64-mingw32-ld.
>
> What does "x86_64-w64-mingw32-ld --help|grep supported\ targets" say?
>
>
>
> x86_64-w64-mingw32-ld: supported targets: pe-x86-64 pei-x86-64
> elf64-x86-64 elf64-l1om elf64-little elf64-big elf32-little elf32-big
> pe-i386 pei-i386 elf32-i386 srec symbolsrec verilog tekhex binary ihex
> I have the PATH so ld is the actual x86_64-w64 target's ld
>
>
>
> [Adding mingw-w64-public back, my mail client dropped it]
>
> Hi,
> What does "x86_64-w64-mingw32-gcc -print-prog-name=as" say?
>
> I suspect the wrong "as" was called.
>
>
> It points to the exact place of where I installed it in PREFIX/TARGET/bin
> x86_64-w64-mingw32/bin/as
>
>
>
>
> Hi,
> I forgot a crucial information from xenofear's guide that you referred to:
>
> Important: Multilib is not supported in the GCC 4.4.x branch for any
> mingw targets. You can build as if it was multilib, but you will not get
> multilib executables or libraries from GCC. GCC 4.5.0 is recommended,
> despite being in Stage 1 development, it is usually in excellent status.
> The best way to get it is via SVN detailed below. However, for this
> cross-compiler, you can use anything from gcc 4.3 upwards, with gcc
> 4.4.1 currently (20090913)the most recent stable gcc release, and you
> should not use gcc 4.5.0/trunk for production.
>
> Sorry, I forgot about that, looks like gcc 4.4 wasn't set to call "as"
> properly.
>
>
>
> Well, I read that line too, and decided to try it since I also read it was
> resolved? he said in the GCC PR
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40922
> So, yeah probably the main reason for this failure.
>
> Hello Can anyone tell me does gcc-4.4 branch works with multilib option with
> mingw-w

Re: [Mingw-w64-public] gmp-4.3.1-w64.patch issues

[Ozkan Sezer]

> when applying gmp-4.3.1-w64.patch, some of entries for configure script
> are been rejected due to inconsistance between 20091006 tarball's
> configure and patch...
>
> Most rejected entries are just about line echoing, but the last one is
> more important and rejected due to context comment differences between
> configure file and lines searched by patch.

I think this issue is solved in recently released source tarballs
which have the patch already applied to gmp.

> Sorry for my poor english, it isn't my natural language

No problems at all.

--
Ozkan

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] custom w64 cross-compiler build with gcc-4.4.2 (2009-10-16)

[Ozkan Sezer]

To anyone who might be interested:  I updated my
custom w64 cross-compiler build with gcc-4.4.2 with
many backports / fixes from mainstream and uploaded
to uhexen2 support files section.

Versions:

binutils : 2.20.51 (cvs, 2009-10-16 23:55 GMT)
mingw-w64-headers: svn revision 1473 (2009-10-11)
mingw-w64-crt: svn revision 1473 (2009-10-11)
gcc  : svn revision 152901 + misc patches.

Links:

ReadMe file:
http://downloads.sourceforge.net/uhexen2/cross_win64_20091016.txt

Sources:
http://downloads.sourceforge.net/uhexen2/cross_win64_20091016-src.tgz

Binary for i686-linux:
http://downloads.sourceforge.net/uhexen2/cross_win64_20091016.tgz

Cheers.

--
Ozkan

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] 64-bit printf question...

[Ozkan Sezer]

On Sun, Oct 25, 2009 at 5:55 PM, David Cleaver  wrote:
> Hello,
>
> I'm having problems printing out values that are larger than 32 bits.  My 
> usual
> printf using %llu only outputs the lower 32 bits of my 64-bit numbers.
>
> Here's an example program that produces incorrect output.
>
> #include 
>
> typedef unsigned long long u64_t;
>
> int main(int argc, char* argv[])
> {
>   u64_t y=6981463658333LL;
>   printf("y=%llu\n", y);

%llu is not supported by printf in msvcrt.dll.  You can use
%I64u which is the one supported by ms. Or you can use
__mingw_printf(), instead, either explicitly, or indirectly by
defining __USE_MINGW_ANSI_STDIO as 1, for example
by adding -D__USE_MINGW_ANSI_STDIO=1 to your
CFLAGS, which will automaticly replace all printf family
of functions with their __mingw_ counterparts.


>   printf("y=%PRIu64\n", y);

Wrong syntax.  First you must #include  for
this. Then, the correct form should be like

printf("y=%" PRIu64 "\n", y);

>   printf("y=%qd\n", y);

Same as %ll stuff.

>   printf("y=%x\n", y);
>   return 0;
> }
>
> Here is the output I get.
> y=2141802333
> y=PRIu64
> y=qd
> y=7fa94f5d
>
> Can anyone see what I'm doing wrong?  What is the proper way to output 64-bit
> numbers?  I'm using mingw-w64-bin_i686-mingw_20091025.zip for my development
> environment and I've called the compiler like:
> x86_64-w64-mingw32-gcc.exe -o test.exe test.c
>
> Thanks for any help.
>
> -David C.

Use -Wall (or -Wformat) to get warnings about what is
supported and what is not.  Hope these help.

--
Ozkan

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Another compilation problem binutils... after updated the mingw-w64-headers to svn-trunk

[Ozkan Sezer]

On Mon, Nov 2, 2009 at 11:49 AM, t66...@gmail.com  wrote:
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c: In function
> '_getopt_internal':
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:683: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:708: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:713: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:731: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:760: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:764: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:790: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:793: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:823: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:870: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:888: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:904: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:953: error: called
> object '1' is not a function
> make[3]: *** [getopt.o] Error 1
>
> Hi
> I have no idea what is happening with the w64-headers it seems to be
> unable to compile binutils target=x86_64-w64-mingw32 the
> mingw-w64-headers from 101009 worked Ok.
> Anyone got a solution ? Or idea of which commit caused the breakage?
> Thanks.

Is this problem reproducible with revision 1508 of the
headers?

--
Ozkan

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Another compilation problem binutils... after updated the mingw-w64-headers to svn-trunk

[Ozkan Sezer]

On Mon, Nov 2, 2009 at 12:14 PM, Kai Tietz  wrote:
> 2009/11/2 Ozkan Sezer :
>> On Mon, Nov 2, 2009 at 11:49 AM, t66...@gmail.com  wrote:
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c: In function
>>> '_getopt_internal':
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:683: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:708: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:713: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:731: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:760: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:764: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:790: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:793: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:823: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:870: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:888: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:904: error: called
>>> object '1' is not a function
>>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:953: error: called
>>> object '1' is not a function
>>> make[3]: *** [getopt.o] Error 1
>>>
>>> Hi
>>> I have no idea what is happening with the w64-headers it seems to be
>>> unable to compile binutils target=x86_64-w64-mingw32 the
>>> mingw-w64-headers from 101009 worked Ok.
>>> Anyone got a solution ? Or idea of which commit caused the breakage?
>>> Thanks.
>>
>> Is this problem reproducible with revision 1508 of the
>> headers?
>>
>> --
>> Ozkan
>>
>
> This issue is related to the definition in _mingw_mac.h of a temporary
> _ as 1. If you add here before the pop_macro call an '#undef _' (we
> did this already on our trees), does it helps?
>
> Kai

Kai, this will bite us, and it will bite us very hard
if it isn't fixed properly.  Our workaround in the
headers is very fragile because it relies on the
assumption that _mingw.h or _mingw_mac.h is
included early enough and all other possible
definitions of "_" would come *after* that include
which may not be the case at all.

--
Ozkan

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Another compilation problem binutils... after updated the mingw-w64-headers to svn-trunk

[Ozkan Sezer]

On Mon, Nov 2, 2009 at 1:18 PM, t66...@gmail.com  wrote:
> Ozkan Sezer wrote:
>
> On Mon, Nov 2, 2009 at 12:14 PM, Kai Tietz  wrote:
>
> 2009/11/2 Ozkan Sezer :
>
> On Mon, Nov 2, 2009 at 11:49 AM, t66...@gmail.com  wrote:
>
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c: In function
> '_getopt_internal':
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:683: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:708: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:713: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:731: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:760: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:764: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:790: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:793: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:823: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:870: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:888: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:904: error: called
> object '1' is not a function
> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:953: error: called
> object '1' is not a function
> make[3]: *** [getopt.o] Error 1
>
> Hi
> I have no idea what is happening with the w64-headers it seems to be
> unable to compile binutils target=x86_64-w64-mingw32 the
> mingw-w64-headers from 101009 worked Ok.
> Anyone got a solution ? Or idea of which commit caused the breakage?
> Thanks.
>
>
> Is this problem reproducible with revision 1508 of the
> headers?
>
>
> Worked fine after cp -R headers
>


Please don't drop the mailing list from the CC
so that others can see the feedback, too.
And glad to hear that it is solved for you.

--
Ozkan

>
>
> This issue is related to the definition in _mingw_mac.h of a temporary
> _ as 1. If you add here before the pop_macro call an '#undef _' (we
> did this already on our trees), does it helps?
>
>
>
> Yeah thanks for the fast help!
>
> Kai
>
>
> Kai, this will bite us, and it will bite us very hard
> if it isn't fixed properly.  Our workaround in the
> headers is very fragile because it relies on the
> assumption that _mingw.h or _mingw_mac.h is
> included early enough and all other possible
> definitions of "_" would come *after* that include
> which may not be the case at all.
>
> --
> Ozkan
>

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Custom toolchain build with gcc-4.4.3 (2009-11-01)

[Ozkan Sezer]

To anyone who might be interested: I updated my
custom w64 cross-compiler build with gcc-4.4.3 with
many backports / fixes from mainstream and uploaded
to uhexen2 support files section.

Versions:

binutils : 2.20.51 (cvs, 2009-10-31 18:35 GMT)
mingw-w64-crt : svn revision 1505 (2009-10-26)
mingw-w64-headers : svn revision 1509 (2009-10-31)
gcc : svn revision 153794 (4.4.3 prerelease with patches)

This revision has the -w64- stuff and several
x86 fixes backported, along with other things.

Links:

Sources:
 
http://sourceforge.net/project/downloading.php?group_id=124987&filename=cross_win64_20091101-src.tgz
Binary for i686-linux:
 
http://sourceforge.net/project/downloading.php?group_id=124987&filename=cross_win64_20091101.tgz
ReadMe file:
 
http://sourceforge.net/project/downloading.php?group_id=124987&filename=cross_win64_20091101.txt

The native win64 (and win32) toolchains based
on these sources are being experimented by the
Strawberry Perl folks, too. I happen to upload
those builds to http://uhexen2.sf.net/tmp/ from
time to time.  They seem to keep them here:
http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/
Files for this revision:
http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/mingw64-w64-20091101.7z
http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/mingw64-w32-20091101.7z


Cheers.

--
Ozkan

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.3 (2009-11-01)

[Ozkan Sezer]

On Mon, Nov 2, 2009 at 4:05 PM, NightStrike  wrote:
> Since this seems to be semi-regular, do you want to create a separate
> directory under "Toolchains targetting WinXX" for your stuff, called
> something like "Personal Builds" or something, and send your stuff
> there?
>

As suggested by NightStrike, I put my builds under
the mingw-w64 sf.net file release system under the
subdirectories: Toolchain sources -> Personal Builds,
Toolchains targetting Win32 -> Personal Builds  and
Toolchains targetting Win64 -> Personal Builds

--
Ozkan


> On Mon, Nov 2, 2009 at 7:38 AM, Ozkan Sezer  wrote:
>> To anyone who might be interested: I updated my
>> custom w64 cross-compiler build with gcc-4.4.3 with
>> many backports / fixes from mainstream and uploaded
>> to uhexen2 support files section.
>>
>> Versions:
>>
>> binutils : 2.20.51 (cvs, 2009-10-31 18:35 GMT)
>> mingw-w64-crt : svn revision 1505 (2009-10-26)
>> mingw-w64-headers : svn revision 1509 (2009-10-31)
>> gcc : svn revision 153794 (4.4.3 prerelease with patches)
>>
>> This revision has the -w64- stuff and several
>> x86 fixes backported, along with other things.
>>
>> Links:
>>
>> Sources:
>>  http://sourceforge.net/project/downloading.php?group_id=124987&filename=cross_win64_20091101-src.tgz
>> Binary for i686-linux:
>>  http://sourceforge.net/project/downloading.php?group_id=124987&filename=cross_win64_20091101.tgz
>> ReadMe file:
>>  http://sourceforge.net/project/downloading.php?group_id=124987&filename=cross_win64_20091101.txt
>>
>> The native win64 (and win32) toolchains based
>> on these sources are being experimented by the
>> Strawberry Perl folks, too. I happen to upload
>> those builds to http://uhexen2.sf.net/tmp/ from
>> time to time.  They seem to keep them here:
>> http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/
>> Files for this revision:
>> http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/mingw64-w64-20091101.7z
>> http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/mingw64-w32-20091101.7z
>>
>>
>> Cheers.
>>
>> --
>> Ozkan
>>
>

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.3 (2009-11-01)

[Ozkan Sezer]

On Mon, Nov 2, 2009 at 8:46 PM, Wolfgang Glas  wrote:
> Ozkan Sezer schrieb:
>> To anyone who might be interested: I updated my
>> custom w64 cross-compiler build with gcc-4.4.3 with
>> many backports / fixes from mainstream and uploaded
>> to uhexen2 support files section.
>>
>> Versions:
>>
>> binutils : 2.20.51 (cvs, 2009-10-31 18:35 GMT)
>> mingw-w64-crt : svn revision 1505 (2009-10-26)
>> mingw-w64-headers : svn revision 1509 (2009-10-31)
>> gcc : svn revision 153794 (4.4.3 prerelease with patches)
>
> Hi Ozkan,
>
>  Could you please post the patches against gcc-4.4-branch either to this list
> or on a website? A short comment on each patch would be appreciated very much.
>

See the source tarball under Toolchain sources -> Personal Builds.
Most, if not all, of the binaries also contain the used patches under
a subdirectory called _build_info within themselves.

>  Moreover, is there a reason, why you are using a gcc-4.4.3 prerelease rather
> than the official gcc-4.4.2 release?
>

Well, 4.4.3 contain more fixes and, as far as I can follow,
there aren't any regressions since 4.4.2.

>  And, if I got the right understanding, you are using the mingw-w64 v1.0
> branch, isn't it?
>

Yep.

>  The reason behind my questions is, that I'd like to upgrade my ubuntu 
> packages
> from mingw-w64-gcc-4.4.1-1 to gcc-4.4.2. We've made excellent experience with
> our mingw-w64-gcc-4.4.1-1 packages, so I'm not in a hurry ;-)

Really good to hear that you have success with us.
I'm fairly sure that there will be official 4.4.2-based
packages from our packagers, too.

>
>  Best regards,
>
>     Wolfgang

Cheers.

--
Ozkan


>
>> This revision has the -w64- stuff and several
>> x86 fixes backported, along with other things.
>>
>> Links:
>>
>> Sources:
>>  http://sourceforge.net/project/downloading.php?group_id=124987&filename=cross_win64_20091101-src.tgz
>> Binary for i686-linux:
>>  http://sourceforge.net/project/downloading.php?group_id=124987&filename=cross_win64_20091101.tgz
>> ReadMe file:
>>  http://sourceforge.net/project/downloading.php?group_id=124987&filename=cross_win64_20091101.txt
>>
>> The native win64 (and win32) toolchains based
>> on these sources are being experimented by the
>> Strawberry Perl folks, too. I happen to upload
>> those builds to http://uhexen2.sf.net/tmp/ from
>> time to time.  They seem to keep them here:
>> http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/
>> Files for this revision:
>> http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/mingw64-w64-20091101.7z
>> http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/mingw64-w32-20091101.7z
>>
>>
>> Cheers.
>>
>> --
>> Ozkan
>>
>> --
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> --
> Dr. Wolfgang Glas               ev-i Informationstechnologie GmbH
> Geschäftsführer                           Sebastian-Kneipp-Weg 17
> wolfgang.g...@ev-i.at                    A-6020 Innsbruck/Austria
> phone: +43-512-284883-2 +43-699-12665927      fax: +43-720-699931
>

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.3 (2009-11-01)

[Ozkan Sezer]

On Mon, Nov 2, 2009 at 10:52 PM, Wolfgang Glas  wrote:
> Ozkan Sezer schrieb:
>> On Mon, Nov 2, 2009 at 8:46 PM, Wolfgang Glas  wrote:
>>> Ozkan Sezer schrieb:
>>>> To anyone who might be interested: I updated my
>>>> custom w64 cross-compiler build with gcc-4.4.3 with
>>>> many backports / fixes from mainstream and uploaded
>>>> to uhexen2 support files section.
>>>>
>>>> Versions:
>>>>
>>>> binutils : 2.20.51 (cvs, 2009-10-31 18:35 GMT)
>>>> mingw-w64-crt : svn revision 1505 (2009-10-26)
>>>> mingw-w64-headers : svn revision 1509 (2009-10-31)
>>>> gcc : svn revision 153794 (4.4.3 prerelease with patches)
>>> Hi Ozkan,
>>>
>>>  Could you please post the patches against gcc-4.4-branch either to this 
>>> list
>>> or on a website? A short comment on each patch would be appreciated very 
>>> much.
>>>
>>
>> See the source tarball under Toolchain sources -> Personal Builds.
>> Most, if not all, of the binaries also contain the used patches under
>> a subdirectory called _build_info within themselves.
>
> Oh, TX, I'll hava a look at these.
>

Mostly PR patches that went into 4.5 but not
planned for a 4.4 backport.

>>>  Moreover, is there a reason, why you are using a gcc-4.4.3 prerelease 
>>> rather
>>> than the official gcc-4.4.2 release?
>>
>> Well, 4.4.3 contain more fixes and, as far as I can follow,
>> there aren't any regressions since 4.4.2.
>
> Good point, ThX.

My reason is the same as yours when you asking
about a 4.4.2 based release whereas you already
report that you are perfectly fine with 4.4.1 based
releases. You see that 4.4.2 out you feel the urge
to upgrade. For me, well I feel that urge a little
earlier ;)

>
>>>  The reason behind my questions is, that I'd like to upgrade my ubuntu 
>>> packages
>>> from mingw-w64-gcc-4.4.1-1 to gcc-4.4.2. We've made excellent experience 
>>> with
>>> our mingw-w64-gcc-4.4.1-1 packages, so I'm not in a hurry ;-)
>>
>> Really good to hear that you have success with us.
>> I'm fairly sure that there will be official 4.4.2-based
>> packages from our packagers, too.
>
> Everytime the same story: No feedback for developers, if everything is working
> OK ;-)
>
> We have ported multihreaded server-applications (omniORB-4.1.4 based) as well 
> as
> multithreaded GUI-Programs (Qt3 and Qt4) from mingw.org to mingw-w64 cross
> compilers and observed no regression yet ;-)

We really need some web space (a wiki maybe?)
for such success stories.  Out of curiosity, are your
successes with x86 or x86_64 or both?

>
> And, yes, the ported programs are non-trivial in many ways, the server
> application is an image-rendering engine behind a JAVA-webapp, which is under
> heavy use by 1500 users.
>
> So, that's why I wonder how you mange to further increase mingw-w64's 
> stability ;->>
>
>  Wolfgang
>

--
Ozkan

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] recent svn changes

[Ozkan Sezer]

Hi all:  I've been away for a while due to personal issues
and it seems like there have been several changes in the svn.
While I'm trying to make a new personal 4.4.3-based toolchain
build, I'm trying to catch up and understand those changes:

- trunk, rev. 1590: Remove override of _lseeki64.
What is the reason?  Besides, our bug #2892010 says that might
fix the bug mentioned therein. How / why? Should it be applied
to the 1.0 branch, too?

- trunk revs. 1644 and 1645 updating kernel32.def and ntdll.def
for x86:  needed/planned for 1.0 branch, too? Same for r1581 of
crypt32.def.

- the wspiapi changes both in the trunk and in the 1.0 branch?
What was the reason?

Cheers.

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] recent svn changes

[Ozkan Sezer]

On Thu, Dec 24, 2009 at 9:34 PM, Kai Tietz  wrote:
> Hello Ozkan,
>
> nice to hear you are back. Yes, there were some changes on svn. Some
> are back-merged, because they were triggered by bug reports of wrong
> behavior.
>
> 2009/12/24 Ozkan Sezer :
>> Hi all:  I've been away for a while due to personal issues
>> and it seems like there have been several changes in the svn.
>> While I'm trying to make a new personal 4.4.3-based toolchain
>> build, I'm trying to catch up and understand those changes:
>>
>> - trunk, rev. 1590: Remove override of _lseeki64.
>> What is the reason?  Besides, our bug #2892010 says that might
>> fix the bug mentioned therein. How / why? Should it be applied
>> to the 1.0 branch, too?
>
> Well, we had an issue here. The file locking done in the local lseek
> function wasn't compatible and in some scenarios dead-locks were
> recent by this. We found that at office. As it is a serious
> regression, 1.0 and trunk got this patch.

The 1.0 branch does _not_ have this change.  Should I do
it or would you do it?

>
>> - trunk revs. 1644 and 1645 updating kernel32.def and ntdll.def
>> for x86:  needed/planned for 1.0 branch, too? Same for r1581 of
>> crypt32.def.
>
> Well, the kernel32.def and ntdll.def are updates of the existing one.
> As there wasn't a real regression reported for those import libraries,
> a back-merge isn't planned. But well, some function in kernel32.def
> and ntdll.def indeed had wrong argument counts (the .def files in 1.0
> for x86 are mainly the same as for w32api). It would be good to extend
> and review the .def files for x86, so we get better support for x86 in
> supported import-libraries, too.
> PS: The ntdll and kernel32 .def-files were done with some minor
> changes by the output of gendef, which got major improvements last
> weeks.
>

Back-merge of at least the fixing parts would be nice (don't know
which ones they are..)

>> - the wspiapi changes both in the trunk and in the 1.0 branch?
>> What was the reason?
>
> Yes, here we got reports of warning due the inline function with
> static members. So we removed them and just keep for them the
> implementation (without inline) version.

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] recent svn changes

[Ozkan Sezer]

On Thu, Dec 24, 2009 at 9:55 PM, Kai Tietz  wrote:
> 2009/12/24 Ozkan Sezer :
>> On Thu, Dec 24, 2009 at 9:34 PM, Kai Tietz  wrote:
>>> Hello Ozkan,
>>>
>>> nice to hear you are back. Yes, there were some changes on svn. Some
>>> are back-merged, because they were triggered by bug reports of wrong
>>> behavior.
>>>
>>> 2009/12/24 Ozkan Sezer :
>>>> Hi all:  I've been away for a while due to personal issues
>>>> and it seems like there have been several changes in the svn.
>>>> While I'm trying to make a new personal 4.4.3-based toolchain
>>>> build, I'm trying to catch up and understand those changes:
>>>>
>>>> - trunk, rev. 1590: Remove override of _lseeki64.
>>>> What is the reason?  Besides, our bug #2892010 says that might
>>>> fix the bug mentioned therein. How / why? Should it be applied
>>>> to the 1.0 branch, too?
>>>
>>> Well, we had an issue here. The file locking done in the local lseek
>>> function wasn't compatible and in some scenarios dead-locks were
>>> recent by this. We found that at office. As it is a serious
>>> regression, 1.0 and trunk got this patch.
>>
>> The 1.0 branch does _not_ have this change.  Should I do
>> it or would you do it?
>
> Not, ups. Have I missed that. Feel free to do a back-merge of this
> change. Thanks for spotting this.
>

Committed as r1684.


>>>> - trunk revs. 1644 and 1645 updating kernel32.def and ntdll.def
>>>> for x86:  needed/planned for 1.0 branch, too? Same for r1581 of
>>>> crypt32.def.
>>>
>>> Well, the kernel32.def and ntdll.def are updates of the existing one.
>>> As there wasn't a real regression reported for those import libraries,
>>> a back-merge isn't planned. But well, some function in kernel32.def
>>> and ntdll.def indeed had wrong argument counts (the .def files in 1.0
>>> for x86 are mainly the same as for w32api). It would be good to extend
>>> and review the .def files for x86, so we get better support for x86 in
>>> supported import-libraries, too.
>>> PS: The ntdll and kernel32 .def-files were done with some minor
>>> changes by the output of gendef, which got major improvements last
>>> weeks.
>>>
>>
>> Back-merge of at least the fixing parts would be nice (don't know
>> which ones they are..)
>
> Well, we could, but I am not that sure if those functions are of much
> interest here. The changes to API are mostly related to internal Rtl
> functions (IIRC two of them had wrong argument counts).
>
>>>> - the wspiapi changes both in the trunk and in the 1.0 branch?
>>>> What was the reason?
>>>
>>> Yes, here we got reports of warning due the inline function with
>>> static members. So we removed them and just keep for them the
>>> implementation (without inline) version.
>>
>> --
>> Ozkan
>>
>
> Kai

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] recent svn changes

[Ozkan Sezer]

On Fri, Dec 25, 2009 at 12:02 AM, kmx  wrote:
>
> - trunk revs. 1644 and 1645 updating kernel32.def and ntdll.def
> for x86:  needed/planned for 1.0 branch, too? Same for r1581 of
> crypt32.def.

 ..
>>>
>>> Back-merge of at least the fixing parts would be nice (don't know
>>> which ones they are..)
>>
>> Well, we could, but I am not that sure if those functions are of much
>> interest here. ...
>
> It would be nice to have updated crypt32.def in 1.0 branche; if I can ask for 
> this. It is necessary for building openssl 1.0.0 with native 32bit mingw-w64 
> compiler.
>

That particular one seems to have already been back-
merged into the 1.0 branch.

> Thanks.
>
> --
> kmx

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Custom toolchain build with gcc-4.4.3 (2009-12-24)

[Ozkan Sezer]

To anyone who might be interested: I updated my custom
w32/w64 native and cross-compiler build with gcc-4.4.3
with several backports and fixes from mainstream and put
them under the mingw-w64 sf.net file release system under
the subdirectories: Toolchain sources -> Personal Builds,
Toolchains targetting Win32 -> Personal Builds  and
Toolchains targetting Win64 -> Personal Builds

File names:

mingw-w64-src_20091224_sezero.tar.gz
mingw-w32-bin_i686-linux_20091224_sezero.tar.gz
mingw-w32-bin_i686-mingw_20091224_sezero.zip
mingw-w64-bin_i686-linux_20091224_sezero.tar.gz
mingw-w64-bin_x86_64-linux_20091224_sezero.tar.gz
mingw-w64-bin_x86_64-mingw_20091224_sezero.zip


Versions:

binutils : 2.20.51 (cvs, 2009-12-24 15:33 GMT)
mingw-w64-crt : svn revision 1684 (2009-12-24)
mingw-w64-headers : svn revision 1674 (2009-12-23)
gcc : svn revision 155431 (4.4.3 prerelease with patches)


--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.3 (2009-12-24)

[Ozkan Sezer]

On Sun, Dec 27, 2009 at 1:07 PM, Grant Pedersen  wrote:
>> -Original Message-
>> From: Ozkan Sezer [mailto:seze...@gmail.com]
>> Sent: 25 December 2009 15:13
>> To: mingw-w64-public@lists.sourceforge.net
>> Subject: [Mingw-w64-public] Custom toolchain build with gcc-4.4.3
>> (2009-12-24)
>>
>> To anyone who might be interested: I updated my custom
>> w32/w64 native and cross-compiler build with gcc-4.4.3
>> with several backports and fixes from mainstream and put
>> them under the mingw-w64 sf.net file release system under
>> the subdirectories: Toolchain sources -> Personal Builds,
>> Toolchains targetting Win32 -> Personal Builds  and
>> Toolchains targetting Win64 -> Personal Builds
>
> Thanks Ozkan, your builds have been working well for me.  Any chance of also

Thanks for the feedback. Glad to hear that they are
useful for you.

> providing a shared libstdc++ as a supplement?
>

No, at least not at the moment. As far as I know, the
4.4 branch doesn't have all things required for a
shared libstdc++.dll (I may be wrong, though).  I don't
know which parts to backport from trunk-4.5, yet.

> Thanks,
> Grant.

Cheers.

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] command line globbing

[Ozkan Sezer]

kmx came up with this issue:

-- Forwarded message --
From: SourceForge.net 
Date: Sat, Jan 2, 2010 at 11:04 AM
Subject: [mingw-w64 - Help] RE: 64-bit native toolchain binaries

Read and respond to this message at:
https://sourceforge.net/projects/mingw-w64/forums/forum/723798/topic/3436580

> **1) strip.exe issue (maybe it is a feature)**
>
> With old gcc toolchain from mingw.org project I can run
> strip.exe with a wildcard like this: strip d:\dir\*.dll
>
> However with mingw-w64 binaries it returns:
> d:\> strip.exe d:\dir\*.dll
> strip.exe: 'd:\dir\*.dll': No such file
> (even if there are *.dll files in d:\dir)
>
> Maybe it is a new feature of new biutils, I do not know.
> Anyway the behaviour of the old toolchain was more
> convenient.

Hmm, command line parsing/glob'bing seem to not
work. I beleive, if you were to run it under msys instead
of cmd.exe it would work. The reason may be that
our crt disables globbing by default (see crt/wildcard.c,
also see crt/CRT_glob.c), whereas the mingw.org crt
enables it by default. I am not sure whether we should
enable it. Kai?

***

What do you guys think? Should we enable cmdline globbing
by default as the mingw32 guys do?

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] command line globbing

[Ozkan Sezer]

On Sun, Jan 3, 2010 at 12:57 PM, Kai Tietz  wrote:
> Hi Ozkan,
>
> 2010/1/3 Ozkan Sezer :
>> kmx came up with this issue:
>>
>> -- Forwarded message --
>> From: SourceForge.net 
>> Date: Sat, Jan 2, 2010 at 11:04 AM
>> Subject: [mingw-w64 - Help] RE: 64-bit native toolchain binaries
>>
>> Read and respond to this message at:
>> https://sourceforge.net/projects/mingw-w64/forums/forum/723798/topic/3436580
>>
>>> **1) strip.exe issue (maybe it is a feature)**
>>>
>>> With old gcc toolchain from mingw.org project I can run
>>> strip.exe with a wildcard like this: strip d:\dir\*.dll
>>>
>>> However with mingw-w64 binaries it returns:
>>> d:\> strip.exe d:\dir\*.dll
>>> strip.exe: 'd:\dir\*.dll': No such file
>>> (even if there are *.dll files in d:\dir)
>>>
>>> Maybe it is a new feature of new biutils, I do not know.
>>> Anyway the behaviour of the old toolchain was more
>>> convenient.
>>
>> Hmm, command line parsing/glob'bing seem to not
>> work. I beleive, if you were to run it under msys instead
>> of cmd.exe it would work. The reason may be that
>> our crt disables globbing by default (see crt/wildcard.c,
>> also see crt/CRT_glob.c), whereas the mingw.org crt
>> enables it by default. I am not sure whether we should
>> enable it. Kai?
>>
>> ***
>>
>> What do you guys think? Should we enable cmdline globbing
>> by default as the mingw32 guys do?
>>
>> --
>> Ozkan
>>
>
> Well, we can do. But we should provide then the object for disabling
> it as .o file, too.
>
> Fine by me.
>
> Cheers,
> Kai

OK, I made the attached patch, against the 1.0 branch,
also applies to the trunk.  It keeps the old behavior,
which is globbing off by default, but adds a new configure
option --enable-wildcard which enables it.  It also adds
CRT_noglob.c which gives the means of disabling globbing,
like its counterpart CRT_glob.c. The patch doesn't include
the diffs to the generated files.  If the patch is OK, I
can apply it to the 1.0 branch and to the trunk, and can
also regenerate the necessary files, or nightstrike can do
it himself (the three commands autoheader, autoconf and
automake must be run.)

--
Ozkan


w1.diff
Description: Binary data
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] command line globbing

[Ozkan Sezer]

On Sun, Jan 3, 2010 at 3:35 PM, Ozkan Sezer  wrote:
> On Sun, Jan 3, 2010 at 12:57 PM, Kai Tietz  wrote:
>> Hi Ozkan,
>>
>> 2010/1/3 Ozkan Sezer :
>>> kmx came up with this issue:
>>>
>>> -- Forwarded message --
>>> From: SourceForge.net 
>>> Date: Sat, Jan 2, 2010 at 11:04 AM
>>> Subject: [mingw-w64 - Help] RE: 64-bit native toolchain binaries
>>>
>>> Read and respond to this message at:
>>> https://sourceforge.net/projects/mingw-w64/forums/forum/723798/topic/3436580
>>>
>>>> **1) strip.exe issue (maybe it is a feature)**
>>>>
>>>> With old gcc toolchain from mingw.org project I can run
>>>> strip.exe with a wildcard like this: strip d:\dir\*.dll
>>>>
>>>> However with mingw-w64 binaries it returns:
>>>> d:\> strip.exe d:\dir\*.dll
>>>> strip.exe: 'd:\dir\*.dll': No such file
>>>> (even if there are *.dll files in d:\dir)
>>>>
>>>> Maybe it is a new feature of new biutils, I do not know.
>>>> Anyway the behaviour of the old toolchain was more
>>>> convenient.
>>>
>>> Hmm, command line parsing/glob'bing seem to not
>>> work. I beleive, if you were to run it under msys instead
>>> of cmd.exe it would work. The reason may be that
>>> our crt disables globbing by default (see crt/wildcard.c,
>>> also see crt/CRT_glob.c), whereas the mingw.org crt
>>> enables it by default. I am not sure whether we should
>>> enable it. Kai?
>>>
>>> ***
>>>
>>> What do you guys think? Should we enable cmdline globbing
>>> by default as the mingw32 guys do?
>>>
>>> --
>>> Ozkan
>>>
>>
>> Well, we can do. But we should provide then the object for disabling
>> it as .o file, too.
>>
>> Fine by me.
>>
>> Cheers,
>> Kai
>
> OK, I made the attached patch, against the 1.0 branch,
> also applies to the trunk.  It keeps the old behavior,
> which is globbing off by default, but adds a new configure
> option --enable-wildcard which enables it.  It also adds
> CRT_noglob.c which gives the means of disabling globbing,
> like its counterpart CRT_glob.c. The patch doesn't include
> the diffs to the generated files.  If the patch is OK, I
> can apply it to the 1.0 branch and to the trunk, and can
> also regenerate the necessary files, or nightstrike can do
> it himself (the three commands autoheader, autoconf and
> automake must be run.)
>
> --

OK, here is a better diff.  Previous one was messed up somehow..

--
Ozkan


w2.diff
Description: Binary data
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] command line globbing

[Ozkan Sezer]

On Mon, Jan 4, 2010 at 11:13 AM, Kai Tietz  wrote:
> Ozkan Sezer  wrote on 03.01.2010 15:16:40:
>
>> On Sun, Jan 3, 2010 at 3:35 PM, Ozkan Sezer  wrote:
>> > On Sun, Jan 3, 2010 at 12:57 PM, Kai Tietz 
> wrote:
>> >> Hi Ozkan,
>> >>
>> >> 2010/1/3 Ozkan Sezer :
>> >>> kmx came up with this issue:
>> >>>
>> >>> -- Forwarded message --
>> >>> From: SourceForge.net 
>> >>> Date: Sat, Jan 2, 2010 at 11:04 AM
>> >>> Subject: [mingw-w64 - Help] RE: 64-bit native toolchain binaries
>> >>>
>> >>> Read and respond to this message at:
>> >>> https://sourceforge.net/projects/mingw-
>> w64/forums/forum/723798/topic/3436580
>> >>>
>> >>>> **1) strip.exe issue (maybe it is a feature)**
>> >>>>
>> >>>> With old gcc toolchain from mingw.org project I can run
>> >>>> strip.exe with a wildcard like this: strip d:\dir\*.dll
>> >>>>
>> >>>> However with mingw-w64 binaries it returns:
>> >>>> d:\> strip.exe d:\dir\*.dll
>> >>>> strip.exe: 'd:\dir\*.dll': No such file
>> >>>> (even if there are *.dll files in d:\dir)
>> >>>>
>> >>>> Maybe it is a new feature of new biutils, I do not know.
>> >>>> Anyway the behaviour of the old toolchain was more
>> >>>> convenient.
>> >>>
>> >>> Hmm, command line parsing/glob'bing seem to not
>> >>> work. I beleive, if you were to run it under msys instead
>> >>> of cmd.exe it would work. The reason may be that
>> >>> our crt disables globbing by default (see crt/wildcard.c,
>> >>> also see crt/CRT_glob.c), whereas the mingw.org crt
>> >>> enables it by default. I am not sure whether we should
>> >>> enable it. Kai?
>> >>>
>> >>> ***
>> >>>
>> >>> What do you guys think? Should we enable cmdline globbing
>> >>> by default as the mingw32 guys do?
>> >>>
>> >>> --
>> >>> Ozkan
>> >>>
>> >>
>> >> Well, we can do. But we should provide then the object for disabling
>> >> it as .o file, too.
>> >>
>> >> Fine by me.
>> >>
>> >> Cheers,
>> >> Kai
>> >
>> > OK, I made the attached patch, against the 1.0 branch,
>> > also applies to the trunk.  It keeps the old behavior,
>> > which is globbing off by default, but adds a new configure
>> > option --enable-wildcard which enables it.  It also adds
>> > CRT_noglob.c which gives the means of disabling globbing,
>> > like its counterpart CRT_glob.c. The patch doesn't include
>> > the diffs to the generated files.  If the patch is OK, I
>> > can apply it to the 1.0 branch and to the trunk, and can
>> > also regenerate the necessary files, or nightstrike can do
>> > it himself (the three commands autoheader, autoconf and
>> > automake must be run.)
>> >
>> > --
>>
>> OK, here is a better diff.  Previous one was messed up somehow..
>
> Thank you. For me this patch looks ok. Of course configure/makefile needs
> update then. If you tested it (as I assume) this patch is ok from my side.
>
> Thanks,
> Kai
>
> |  (\_/)  This is Bunny. Copy and paste Bunny
> | (='.'=) into your signature to help him gain
> | (")_(") world domination.
>
>

Applied to the trunk as rev. 1694 and to the 1.0 branch as rev. 1695.

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Missing twalk in search.h

[Ozkan Sezer]

On Thu, Jan 7, 2010 at 8:11 AM, t66...@gmail.com  wrote:
> Hi
> Due to the latest change in vlc.git
> http://git.videolan.org/gitweb.cgi/vlc.git/?a=commitdiff;h=19adcbe5be83ce12a07d83092503c3f4a622b3b6
> Now breaks build due to mingw-w64-headers crt search.h is missing twalk
> I found twalk inside mingw.org's mingwrt search.h implementation.
> Is there some reason why mingw-w64 have this missing definitions.
>
> regards

Seems like they're just missing, that's all.
mingw.org implements the tsearch code
in mingwex, public domain, taken from
netbsd. I suggest we add them too, both
to the trunk and to the 1.0 branch.

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Missing twalk in search.h

[Ozkan Sezer]

On Thu, Jan 7, 2010 at 9:48 AM, JonY  wrote:
> On 1/7/2010 15:19, Ozkan Sezer wrote:
>> On Thu, Jan 7, 2010 at 8:11 AM, t66...@gmail.com  wrote:
>>> Hi
>>> Due to the latest change in vlc.git
>>> http://git.videolan.org/gitweb.cgi/vlc.git/?a=commitdiff;h=19adcbe5be83ce12a07d83092503c3f4a622b3b6
>>> Now breaks build due to mingw-w64-headers crt search.h is missing twalk
>>> I found twalk inside mingw.org's mingwrt search.h implementation.
>>> Is there some reason why mingw-w64 have this missing definitions.
>>>
>>> regards
>>
>> Seems like they're just missing, that's all.
>> mingw.org implements the tsearch code
>> in mingwex, public domain, taken from
>> netbsd. I suggest we add them too, both
>> to the trunk and to the 1.0 branch.
>>
>> --
>> Ozkan
>
> Hi,
>
> I'm currently working on it, seems like copy and pasting from mingw.org
> could fix this, but I'm sure you can do the commit and testing faster. :)

Copy+paste maybe, but sorry, cannot test at
the moment. So, if you're already working on
it, please do.

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GDB 7.0.1

[Ozkan Sezer]

> Also previously it was not possible to debug 64bits binary using GDB
> until this release.
> Tried gdb_20091224.tar.gz also was impossible to get any debugging info out.
>

It was built from gdb CVS HEAD (their development version)
and yes the gdb.exe was stripped.  Maybe the development
version broke at some point, you had better try and report-
discuss your experience to their developers.

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Should I expect to find a version of make in the mingw-w64 download?

[Ozkan Sezer]

On Tue, Jan 12, 2010 at 2:10 AM, JonY  wrote:
> On 1/12/2010 05:41, Frank R. Brown wrote:
>> To All:
>>
>> I do not see a version of make in my mingw-w64 installation.  Am I 
>> overlooking
>> something, or is this to be expected?  (I have looked for things like 
>> make.exe,
>> mingw-make.exe, mingw32-make.exe, etc.)
>>
>> I downloaded and unzipped mingw-w64-bin_i686-mingw_20091231.zip, and have
>> been able to compile simple test programs.  (This is on 64-bit windows 7.)
>>
>> Background:  I am looking to build 64-bit versions of some third-party 
>> packages
>> (at the moment, qt), and this usually requires a make utility.
>>
>> Thanks.
>>
>> kf
>>
>
> Hi,
>
> make is not part of mingw-w64.
>
> Try mingw32-make instead from the mingw.org project, or MSYS make if
> you are using MSYS.
>
> If you are using Cygwin, it already provides its own GNU make.
>

There actually are make binaries posted under
"External binary packages (Win64 hosted) -> make"
on the downloads page. You can try downloading
make_20091224a_bin.tar.gz for example and
using it.

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Custom toolchain build with gcc-4.4.3 (2010-01-12)

[Ozkan Sezer]

To anyone who might be interested: I updated my custom
w32/w64 native and cross-compiler build with gcc-4.4.3
with several backports and fixes from mainstream and put
them under the mingw-w64 sf.net file release system under
the subdirectories: Toolchain sources -> Personal Builds,
Toolchains targetting Win32 -> Personal Builds  and
Toolchains targetting Win64 -> Personal Builds

File names:

mingw-w64-src_20100112_sezero.tar.gz
mingw-w32-bin_i686-linux_20100112_sezero.tar.gz
mingw-w32-bin_i686-mingw_20100112_sezero.zip
mingw-w64-bin_i686-linux_20100112_sezero.tar.gz
mingw-w64-bin_x86_64-linux_20100112_sezero.tar.gz
mingw-w64-bin_x86_64-mingw_20100112_sezero.zip

Versions:

gcc : svn revision 155836 (4.4.3 prerelease with patches)
binutils : 2.20.51 (cvs, 2010-01-12 12:37 GMT)
mingw-w64-crt : svn revision 1733 (2010-01-12)
mingw-w64-headers : svn revision 1733 (2010-01-12)

Changes since the previous builds: includes the latest
v1.0-release branch fixes to mingw-w64-crt and headers and
the crt is built using the newly added --enable-wildcard
configuration option to avoid several reported problems-
incompatibilities. All included software is updated to
the latest available versions as of today and the gcc is
patched with some more backports from the mainline version.
The gendef tool and the libmangle library are added to the
wirdows-native builds.

--
Ozkan

--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Bulding gmp-5.0.0 with MinGW64 (in MSYS shell).

[Ozkan Sezer]

On Tue, Jan 19, 2010 at 7:29 AM, Sisyphus  wrote:
> Hi,
> Has anyone here done this without getting test failures ?
> I've tried using mingw-w64-bin_i686-mingw_20091118.zip and
> mingw-w64-bin_i686-mingw_20100118.zip binaries, but I get the same 2 test
> failures.
>
> Firstly, the command I'm running to build and test gmp-5.0.0 is:
>
> ./configure --disable-shared --enable-static --host=none-none-none
> CC="x86_64-w64-mingw32-gcc -std=gnu99" CXX=x86_64-w64-mingw32-g++
> AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm
> RANLIB=x86_64-w64-mingw32-ranlib ABI=longlong && make && make check -i
>

I would have suggested using configure --build=x86_64-w64-mingw32
--target=x86_64-w64-mingw32

Make sure that you configured correctly (check your
generated gmp.h for #define _LONG_LONG_LIMB 1)

> That worked fine with gmp-4.3.1 (haven't tried 4.3.2). But with gmp-5.0.0
> I'm getting a crash when t-perfpow.exe is run:
>
> ##
> PASS: t-perfsqr.exe
> n = 97327602995864.23156412530688
> n was destroyed, but perfpow_p still believes n is a perfect power
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> FAIL: t-perfpow.exe
> ##

Don't know about this one, but ...

>
> "n" (whose value I've abbreviated) is in fact a perfect power, but has
> supposedly been destroyed.
>
> A second test failure is that t-locale.exe fails to build:
>
> ##
> x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. 
> -I../../tests
>  -DNO_ASM  -O2 -pedantic -c t-locale.c
> t-locale.c:50:1: warning: 'localeconv' redeclared without dllimport
> attribute: previous dllimport ignored
> /bin/sh ../../libtool --mode=link
> x86_64-w64-mingw32-gcc -std=gnu99  -O2 -pedantic   -o t-locale.exe
> t-locale.o ../../tests/libtests.la ../../libgmp.la
> x86_64-w64-mingw32-gcc -std=gnu99 -O2 -pedantic -o t-locale.exe t-locale.o
> ../../tests/.libs/libtests.a /c/_32/comp/gmp-5.0.0/.libs/libgmp.a
> ../../.libs/libgmp.a
> c:/_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a(dsdds00649.o):(.text+0x0):
> multiple definition of `localeconv'
> t-locale.o:t-locale.c:(.text+0x0): first defined here
> collect2: ld returned 1 exit status
> make[4]: [t-locale.exe] Error 1 (ignored)
> make[4]: Leaving directory `/c/_32/comp/gmp-5.0.0/tests/misc'
> make  check-TESTS
> make[4]: Entering directory `/c/_32/comp/gmp-5.0.0/tests/misc'
> /bin/sh ../../libtool --mode=link
> x86_64-w64-mingw32-gcc -std=gnu99  -O2 -pedantic   -o t-locale.exe
> t-locale.o ../../tests/libtests.la ../../libgmp.la
> x86_64-w64-mingw32-gcc -std=gnu99 -O2 -pedantic -o t-locale.exe t-locale.o
> ../../tests/.libs/libtests.a /c/_32/comp/gmp-5.0.0/.libs/libgmp.a
> ../../.libs/libgmp.a
> c:/_64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.0/../../../../x86_64-w64-mingw32/lib/libmsvcrt.a(dsdds00649.o):(.text+0x0):
> multiple definition of `localeconv'
> t-locale.o:t-locale.c:(.text+0x0): first defined here
> collect2: ld returned 1 exit status
> make[4]: [t-locale.exe] Error 1 (ignored)

... This is known already, it shouwde up when I first
submitted the w64 patches to gmp.  Kai may help
more with this.

> PASS: t-printf.exe
> PASS: t-scanf.exe
> /bin/sh: ./t-locale.exe: No such file or directory
> FAIL: t-locale.exe
> ##
>
> Does anyone here have any views on whether these are mingw64 bugs or
> gmp-5.0.0 bugs ?
>
> Using the 32-bit compiler from mingw.org (gcc-3.4.5), gmp-5.0.0 builds fine
> and passes
> all tests.
>
> Finally, in the gmp-5.0.0 ChangeLog we find:
> * configure.in: Handle mingw64.
>
> Does this change have any impact (wrt MinGW64 builds) on our capacity to
> build gmp-5.0.0, or on the way we go about building gmp-5.0.0 ?
> (I'm still using the same command I used with gmp-4.x.x - I'm wondering if
> anything useful was achieved by that addition to configure.in.)
>
> Cheers,
> Rob
>

--
Ozkan

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Are win64 headers the same as win32 headers?

[Ozkan Sezer]

On Tue, Jan 19, 2010 at 7:42 AM, Zuxy Meng  wrote:
> Hi,
>
> I wonder if the win32api headers from mingw32 can be used directly in
> mingw64.

No, they cannot.

> If I have already a working msys+mingw32 env installed, can I just
> copy binutils, gcc and libraries from mingw64 to have a working native
> compilation env?
> --
> Zuxy

--
Ozkan

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Bulding gmp-5.0.0 with MinGW64 (in MSYS shell).

[Ozkan Sezer]

On Tue, Jan 19, 2010 at 3:50 PM, JonY  wrote:
> On 1/19/2010 20:03, Sisyphus wrote:
>>
>> - Original Message -
>> From: "Ozkan Sezer"
>>
>>>> Firstly, the command I'm running to build and test gmp-5.0.0 is:
>>>>
>>>> ./configure --disable-shared --enable-static --host=none-none-none
>>>> CC="x86_64-w64-mingw32-gcc -std=gnu99" CXX=x86_64-w64-mingw32-g++
>>>> AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld
>>>> NM=x86_64-w64-mingw32-nm
>>>> RANLIB=x86_64-w64-mingw32-ranlib ABI=longlong&&  make&&  make check -i
>>>>
>>>
>>> I would have suggested using configure --build=x86_64-w64-mingw32
>>> --target=x86_64-w64-mingw32
>>
>> Unfortunately that doesn't get me very far:
>>
>> #
>> r...@desktop2 /c/_32/comp/gmp-5.0.0
>> $ ./configure --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
>> configure: error: --target is not appropriate for GMP
>> Use --build=CPU-VENDOR-OS if you need to specify your CPU and/or system
>> explicitly.  Use --host if cross-compiling (see "Installing GMP" in the
>> manual for more on this).
>>
>> r...@desktop2 /c/_32/comp/gmp-5.0.0
>>
>> #
>>
>> Cheers,
>> Rob
>>
>
> Hi,
>
> --target is only valid for GCC/Binutils, use --build/--host instead.

Oops, really meant --host, not --target when I wrote that.
I guess people can't read mind, don't they ;)

>
> The localeconv error is a known problem for win32/win64 target, you can
> ignore it.
>

The thing is, that particular problem doesn't show up
with mingw.org compiler (I had tested with their
gcc-3.4.5 based toolchain in the past, don't know about
the behavior with their newer 4.4-based compilers).

--
Ozkan

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Custom toolchain build with gcc-4.4.3 (2010-01-18)

[Ozkan Sezer]

To anyone who might be interested: I updated my custom
w32/w64 native and cross-compiler build with gcc-4.4.3
with several backports and fixes from mainstream and put
them under the mingw-w64 sf.net file release system under
the subdirectories: Toolchain sources -> Personal Builds,
Toolchains targetting Win32 -> Personal Builds  and
Toolchains targetting Win64 -> Personal Builds

Changes since the previous 2010-01-12 build:  The tchar.h
fix is in (mingw-w64-headers rev.1737).  Fixed installation
of float.h, stdarg.h and stddef.h, on both gcc and mingw-w64
sides.  The directx headers are now installed by default.
Gcc updated to the svn revision 156014, added Andi Kleen's
x86 patches amongst the applied backported fixes.

Note: the /include and /lib paths
problem of the native builds is not looked into, yet. Maybe
in the future builds.

Versions:
-

Common in both cross- and native-toolchains:

gcc : svn rev. 156014 (4.4.3 prerelease with many patches)
binutils : 2.20.51 (cvs, 2010-01-16 18:11 GMT)
mingw-w64-crt : svn revision 1733 (2010-01-12)
mingw-w64-headers : svn revision 1737 (2010-01-14), with a
  couple of patches.

In native-toolchains only:

gmp : 4.3.2 (with w64 patch applied)
mpfr: 2.4.2-p3
mpc : 0.8.1
gdb : 7.0.50 (cvs, 2010-01-16 23:15 GMT, with
  minor w64 patches applied.)
make: 3.81.90 (cvs, 2009-12-24 16:00 GMT, with
  w64 patches applied according to savannah bug
  items 27809 and 27825)
gendef, libmangle: froım mingw-w64 svn/trunk


File names:
---

mingw-w64-src_20100118_sezero.tar.gz  (all sources.)

mingw-w64-bin_x86_64-mingw_20100118_sezero.zip
  native compiler toolchain for running on
  x64-windows host and creating x64-windows
  binaries.

mingw-w64-bin_i686-linux_20100118_sezero.tar.gz
  cross compiler toolchain for running on a
  i686-linux host and creating x64-windows
  binaries.

mingw-w64-bin_x86_64-linux_20100118_sezero.tar.gz
  cross compiler toolchain for running on a
  x86_64-linux host and creating x64-windows
  binaries.

mingw-w32-bin_i686-mingw_20100118_sezero.zip
  native compiler toolchain for running on
  x86-windows host and creating x86-windows
  binaries.

mingw-w32-bin_i686-linux_20100118_sezero.tar.gz
  cross compiler toolchain for running on a
  i686-linux host and creating x86-windows
  binaries.

--
Ozkan

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Bulding gmp-5.0.0 with MinGW64 (in MSYS shell).

[Ozkan Sezer]

On Tue, Jan 19, 2010 at 4:06 PM, JonY  wrote:
> On 1/19/2010 21:55, Ozkan Sezer wrote:
>>
>> On Tue, Jan 19, 2010 at 3:50 PM, JonY  wrote:
>>>
>>> On 1/19/2010 20:03, Sisyphus wrote:
>>>>
>>>> - Original Message -
>>>> From: "Ozkan Sezer"
>>>>
>>>>>> Firstly, the command I'm running to build and test gmp-5.0.0 is:
>>>>>>
>>>>>> ./configure --disable-shared --enable-static --host=none-none-none
>>>>>> CC="x86_64-w64-mingw32-gcc -std=gnu99" CXX=x86_64-w64-mingw32-g++
>>>>>> AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld
>>>>>> NM=x86_64-w64-mingw32-nm
>>>>>> RANLIB=x86_64-w64-mingw32-ranlib ABI=longlong&&   make&&   make check
>>>>>> -i
>>>>>>
>>>>>
>>>>> I would have suggested using configure --build=x86_64-w64-mingw32
>>>>> --target=x86_64-w64-mingw32
>>>>
>>>> Unfortunately that doesn't get me very far:
>>>>
>>>> #
>>>> r...@desktop2 /c/_32/comp/gmp-5.0.0
>>>> $ ./configure --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
>>>> configure: error: --target is not appropriate for GMP
>>>> Use --build=CPU-VENDOR-OS if you need to specify your CPU and/or system
>>>> explicitly.  Use --host if cross-compiling (see "Installing GMP" in the
>>>> manual for more on this).
>>>>
>>>> r...@desktop2 /c/_32/comp/gmp-5.0.0
>>>>
>>>> #
>>>>
>>>> Cheers,
>>>> Rob
>>>>
>>>
>>> Hi,
>>>
>>> --target is only valid for GCC/Binutils, use --build/--host instead.
>>
>> Oops, really meant --host, not --target when I wrote that.
>> I guess people can't read mind, don't they ;)
>>
>>>
>>> The localeconv error is a known problem for win32/win64 target, you can
>>> ignore it.
>>>
>>
>> The thing is, that particular problem doesn't show up
>> with mingw.org compiler (I had tested with their
>> gcc-3.4.5 based toolchain in the past, don't know about
>> the behavior with their newer 4.4-based compilers).
>>
>
> hi,
>
> iiuc, it will fail on modern mingw.org too.
>

This is good to know, we won't be alone.

> libmsvcrt.a now exports localeconv, but t-locale is trying to use its
> own implementation, hence the multiple definition error.

Yep, exactly.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Custom toolchain build with gcc-4.4.3 (2010-01-23)

[Ozkan Sezer]

To anyone who might be interested: I updated my custom
w32/w64 native and cross-compiler build with gcc-4.4.3
with several backports and fixes from mainstream and put
them under the mingw-w64 sf.net file release system under
the subdirectories: Toolchain sources -> Personal Builds,
Toolchains targetting Win32 -> Personal Builds  and
Toolchains targetting Win64 -> Personal Builds

Changes since the previous 2010-01-18 build:  A minor
maintainence build since the previous one:  The _WIN32_IE
version requirement in commctrl.h was relaxed to 0x0500 for
now (mingw-w64-headers and crt rev. 1772).  Gcc is updated
to the 4.4.3 release version (svn rev. 156151).

Note: the /include path problem of the native
builds is not looked into, yet. Maybe in the future builds.

Versions:
-

Common in both cross- and native-toolchains:

gcc : svn rev. 156151 (4.4.3 release with many patches)
binutils : 2.20.51 (cvs, 2010-01-23 18:32 GMT)
mingw-w64-crt : svn revision 1772 (2010-01-22)
mingw-w64-headers : svn revision 1772 (2010-01-22), with a
 couple of patches.

In native-toolchains only:

gmp : 4.3.2 (with w64 patch applied)
mpfr: 2.4.2-p3
mpc : 0.8.1
gdb : 7.0.50 (cvs, 2010-01-23 16:22 GMT, with
 minor w64 patches applied.)
make: 3.81.90 (cvs, 2009-12-24 16:00 GMT, with
 w64 patches applied according to savannah bug
 items 27809 and 27825)
gendef, libmangle: from mingw-w64 svn/trunk


File names:
---

Source:

mingw-w64-src_20100123_sezero.tar.gz


Targetting Win64:

mingw-w64-bin_x86_64-mingw_20100123_sezero.zip
 native compiler toolchain for running on
 x64-windows host and creating x64-windows
 binaries.

mingw-w64-bin_i686-linux_20100123_sezero.tar.gz
 cross compiler toolchain for running on a
 i686-linux host and creating x64-windows
 binaries.

mingw-w64-bin_x86_64-linux_20100123_sezero.tar.gz
 cross compiler toolchain for running on a
 x86_64-linux host and creating x64-windows
 binaries.

Targetting Win32:

mingw-w32-bin_i686-mingw_20100123_sezero.zip
 native compiler toolchain for running on
 x86-windows host and creating x86-windows
 binaries.

mingw-w32-bin_i686-linux_20100123_sezero.tar.gz
 cross compiler toolchain for running on a
 i686-linux host and creating x86-windows
 binaries.

mingw-w32-bin_x86_64-linux_20100123_sezero.tar.gz
 cross compiler toolchain for running on a
 x86_64-linux host and creating x86-windows
 binaries.

--
Ozkan

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] gcc-4.4 branch svn failed to compile

[Ozkan Sezer]

On Mon, Jan 25, 2010 at 9:55 AM, t66...@gmail.com  wrote:
> Hello:
>
> Anyone have build issues with current gcc-4.4 branch ?
> x86_64-w64-mingw32/include/wincrypt.h:1512: error: expected
> specifier-qualifier-list before 'CERT_DATA_BLOB'
> make[4]: *** [_muldi3.o] Error 1
>

it doesn't know CERT_DATA_BLOB. Nightstrike's
revision 1784 is to blame.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Question on scanf and modifiers...

[Ozkan Sezer]

On Mon, Feb 1, 2010 at 4:59 AM, David Cleaver  wrote:
>
> JonY wrote:
>> There is no such macro as __MINGW64__, use __MINGW64_VERSION_MAJOR
>> instead, its guaranteed to be defined if you include any mingw-w64
>> headers.
>>

To clarify things: __MINGW32__ and __MINGW64__ :
They are both compiler 's built-in macros. __MINGW32__
is valid for both mingw.org and mingw-w64, for both
x86 *and* for x64.  __MINGW64__ is *only* valid for x64,
therefore effectively for mingw-w64, because mingw.org
doesn't support x64 (at least not yet.)

__MINGW64_VERSION_MAJOR, on the other hand, is *not* a
compiler built-in macro. It is a macro defined by the
mingw-w64 headers, specifically through _mingw.h. Most,
if not all, of the headers already include _mingw.h,
so if you want to check for .__MINGW64_VERSION_MAJOR
you must do it *after* including some standart headers
such as stdio.h or stdlib.h or even windows.h

>> I think __USE_MINGW_ANSI_STDIO only applies to the printf family, the
>> scanf family has not been ported yet, so you'll need to use %I64u
>> instead of %llu.
>>
>
> Hello, thank you all for your replies.  I seem to be having some trouble 
> getting
> __MINGW64_VERSION_MAJOR to work for me.  Perhaps I have set up my environment
> wrong?  I've downloaded mingw-w64-bin_x86_64-mingw_20100123_sezero.zip and
> extracted it to its own folder, at c:\mingw64-20100123\ (which has bin, lib,
> lib64, etc in it).  Then I have created a command prompt, that when I start 
> it,
> it sets the PATH to: PATH C:\mingw64-20100123\bin;C:\msys\1.0\bin;%PATH%
> Does this look reasonable so for?
>

Yes.

> I was wondering, how does it know where the correct *.h or *.a files are?  I 
> see
> that most of them are not in \include or \lib, but are under
> \x86_64-w64-mingw32\include and \x86_64-w64-mingw32\lib.  Does the gcc.exe in
> \bin know where to look for these files.  For example, I've created a test

Yes.

> program that includes  and .  I've tried putting:
> #ifdef __MINGW64_VERSION_MAJOR
> #define __USE_MINGW_ANSI_STDIO 1
> #endif
> before those 2 includes, but it doesn't seem to work.  If I leave off the 
> ifdef,
> it does work.  Can anyone see what I might be doing wrong?
>

Please do the check *after* the includes. If you truly want
to define the things for mingw-w64 *and* before including
further headers yet, try something like this at the top of
your source:

#ifdef __MINGW32__
#include <_mingw.h>
#endif

#ifdef __MINGW64_VERSION_MAJOR
[your stuff here]
#endif

#include [your actual includes here]

Hope these help.

--
Ozkan

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] broken dshow in dx-sdk

[Ozkan Sezer]

On Thu, Feb 11, 2010 at 11:21 PM, Kai Tietz  wrote:
> 2010/2/11 Ozkan Sezer :
>> Regarding this thread from today:
>> http://sourceforge.net/projects/mingw-w64/forums/forum/723798/topic/3550908
>>
>> Our dshow.h (seems to be based on an old wine version)
>> is broken due to missing extra headers that it depends
>> on.
>>
>> I included the lastest versions from wine-1.1.38 here
>> (see the attached wine_version.zip: includes the missing
>> *.h files, as well as the latest dshow.h as it is in wine
>> project.)  (A note about our old version of dshow: For
>> who know whatever reason, we seem to include dmdls.h and
>> then define VIDEOINFOHEADER...)
>>
>> There is also the version in w32api of mingw/cygwin, for
>> that, well, get the latest w32api package.
>>
>> The two versions are different, though. One version depends
>> on one header, the other depends on another, and the
>> difference is not just in the names of the headers, also
>> in their contents, too.  For example, Wine version doesn't
>> include these ones, but mingw version does:
>> amaudio.h (commented out with a fixme)
>> dvdevcod.h (wine doesn't have one, )
>> vidcap.h (we can use ks.h instead)
>> vptype.h (we have ksmedia.h instead, it has the struct names
>>  prefixed with KS_ )
>> bdatypes.h (neither wine nor we have this one)
>> il21dec.h (neither wine nor we have this one)
>> dvdmedia.h (we dont have this. wine does, but doesnt include)
>>
>> Among this mess, I don't know which set is reliable, because
>> I don't know a thing about dshow, and I don't know what good
>> can result from blindly adding the attached wine version, so
>> please advise.
>>
>
> Well, in general I would say that Wine headers are more trustable
> here. The w32api I distrust in some points pretty strongly. Bad side
> here is, that a lot of projects possible adjusted their code in
> direction of w32api here. But IMHO we should trust in Wine headers
> here.
>
> For the missing headers you see, we should do some research on msdn
> for them and find out, if they are part of standard, and if so, what
> they really contain. Information for this should be possible (at least
> in most cases) by the direct-x API shown on msdn.
>
> Kai

Ok, updated the svn using the wine version of the headers:
r1895, r1897 for the trunk, and r1896, 1898 for the 1.0 branch.
Let's see how this turns out (can't be more broken than how
it already is ;)  Also notified rubenv about the update.

As for the extra headers only present in the cygwin/mingw
repo, I may wrestle with the msdn site for it, although not
immediately.

--
Ozkan

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Custom toolchain build with gcc-4.4.4 (2010-02-12)

[Ozkan Sezer]

To anyone who might be interested: I updated my custom
w32/w64 native and cross-compiler build with gcc-4.4
with several backports and fixes from mainstream and put
them under the mingw-w64 sf.net file release system under
the subdirectories: Toolchain sources -> Personal Builds,
Toolchains targetting Win32 -> Personal Builds  and
Toolchains targetting Win64 -> Personal Builds

Changes since the previous 2010-01-23 build: The mingw-w64
crt and headers updated to r1910 to cover the latest fixes
and improvements, including several win32 library fixes and
many directx header updates.  Gcc updated to the 4.4.4
prerelease version (svn rev. 156740).  All other software
has been updated to the latest available versions as of
2010-02-12.  I also enabled the fortran, objc and obj-c++
languages this time.

Note: the /include path problem of the native
builds is not looked into, yet. Maybe in the future builds.

Versions:
-

Common in both cross- and native-toolchains:

gcc : svn rev. 156740 (4.4.4 prerelease with many patches)
binutils : 2.20.51 (cvs, 2010-02-12 23:00 GMT)
mingw-w64-crt : svn revision 1887 (2010-02-10)
mingw-w64-headers : svn revision 1910 (2010-02-12), with a
 couple of patches.

In native-toolchains only:

gmp : 4.3.2 (with w64 patch applied)
mpfr: 2.4.2-p3
mpc : 0.8.1
gdb : 7.0.50 (cvs, 2010-02-12 23:00 GMT, with
 minor w64 patches applied.)
make: 3.81.90 (cvs, 2010-02-02 15:20 GMT, with
 w64 patches applied according to savannah bug
 items 27809 and 27825, and patched further to
 kill a horde of compiler warnings)
gendef, libmangle: from mingw-w64 svn/trunk


File names:
---

Source:

mingw-w64-src_20100212_sezero.tar.gz


Targetting Win64:

mingw-w64-bin_x86_64-mingw_20100212_sezero.zip
 native compiler toolchain for running on
 x64-windows host and creating x64-windows
 binaries.

mingw-w64-bin_i686-mingw_20100212_sezero.zip
 cross compiler toolchain for running on
 x86-windows host but creating x64-windows
 binaries.

mingw-w64-bin_i686-linux_20100212_sezero.tar.gz
 cross compiler toolchain for running on a
 i686-linux host and creating x64-windows
 binaries.

mingw-w64-bin_x86_64-linux_20100212_sezero.tar.gz
 cross compiler toolchain for running on a
 x86_64-linux host and creating x64-windows
 binaries.


Targetting Win32:

mingw-w32-bin_i686-mingw_20100212_sezero.zip
 native compiler toolchain for running on
 x86-windows host and creating x86-windows
 binaries.

mingw-w32-bin_i686-linux_20100212_sezero.tar.gz
 cross compiler toolchain for running on a
 i686-linux host and creating x86-windows
 binaries.

mingw-w32-bin_x86_64-linux_20100212_sezero.tar.gz
 cross compiler toolchain for running on a
 x86_64-linux host and creating x86-windows
 binaries.

--
Ozkan

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problem with cpuid when compiling Xerces-C++ 3.1.0

[Ozkan Sezer]

On Mon, Feb 15, 2010 at 11:54 AM, Tommi Vainikainen  wrote:
> Tommi Vainikainen  writes:
>> I was trying to cross-compile Xerces-C++ 3.1 on Debian to 64 bit
>> Windows. However this triggered compilation error with cpuid macro.
>>
>> error: macro "__cpuid" requires 5 arguments, but only 2 given
>>
>> MSDN's prototype for __cpuid is "void __cpuid(int CPUInfo[4], int InfoType)",
>> which is also what I found from w64's intrin.h
>
> I'm replying to myself now I resolved the problem.
>

Sorry for seeing this one late.

> The problem lies in the fact that Xerces-C++ configure checks for
> existence of cpuid.h (provided by GCC) and intrin.h (provided by
> mingw-w64). When those headers are included, they provide conflicting
> definition of __cpuid.
>

One work aronund maybe doing an #undef __cpuid
before including intrin.h, or ..

> So, one should not include both cpuid.h and intrin.h, but instead select
> which API to use.
>
> (Xerces-C++ reported on http://issues.apache.org/jira/browse/XERCESC-1912)
>

.. the solution suggested here seems good, too, and
is a better one.

> --
> Tommi Vainikainen

Glad that your issue is solved.

--
Ozkan

--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] x64 can't cast ptr to DWORD

[Ozkan Sezer]

On Fri, Feb 19, 2010 at 11:25 AM, Jim Michaels  wrote:
> after much difficulty trying to get subscribed to the list, here is my
> question.
>
> #define CAST(x) reinterpret_cast( x )
> or
> #define CAST(x) (DWORD)( x )
> ...
>     // All msdos data structures must be packed on a 1 byte boundary
>     #pragma pack (1)
>     struct {
>       DWORD StartingSector ;
>       WORD NumberOfSectors ;
>       DWORD pBuffer;
>     } ControlBlock;
>     #pragma pack ()
> ...
>       ControlBlock.pBuffer = CAST(buffer) ;
>
> "dgeomlib.cpp:178: error: cast from 'unsigned char*' to 'DWORD' loses
> precision"
>
> this only occurs on 64-bit target compiler.
> how can I circumvent?

Use DWORD_PTR instead.

> or, how can I use ifdefs to disable this windows 9x code only for x64 target
> (obviously the x64-output compiler must have some sort of #define?)?
>

#ifdef _WIN64 ... #endif  should do?

>
> Jim Michaels
> jmich...@yahoo.com(main)
> JesusnJim.com (my site)

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] x64 can't cast ptr to DWORD

[Ozkan Sezer]

>>> it's 32-bit windows 9x code, but the target is 64-bit, so I have to disable 
>>> the 9x code.
>>> I found a workaround on the internet (great place to look for solutions):
>>> #if !defined(_WIN64)
>>> ...//win9x code
>>> #endif

Yep.

>>> Use DWORD_PTR instead.
>>>
>>> I don't think it's going to fit in 32 bits.

It surely won't if it is _WIN64, and if it is only
for x86 (32 bits) the ifdef'fery above will do
the trick.

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] cross compiler uses 32 bits long type and cannot be changed into 64 bits

[Ozkan Sezer]

On Thu, Feb 25, 2010 at 4:01 PM, Simon de Graaf  wrote:
> Hello,
>
> I am working under opensuse and cross compiling for 64 bits Windows.
> I cannot compile the gmp library because mp_limb_t is 32 bits, because of
> the 32 bit long type.  I have tried to use the -m64 option but it does
> not work.
> Why can a long integer not be set to 64 bits?
> I have used the binary package from source froge.
> Must i maybe download the source package and compile to cross-compiler
> myself
> to get this behaviour?

Is this gmp.4.3? The 4.3 series need a patch to
compiling for win64 (see our files page, under
mingw-w64 -> toolchain patches; gmp-5.0.x does
not need a patch.) Then you should configure it
with --host=x64_64-w64-mingw32.

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC

[Ozkan Sezer]

On Fri, Mar 5, 2010 at 12:20 AM, Jim Michaels  wrote:
> in MSVC,
> __int64 x=12345678901234567i64;
>
> point 1: this type __int64 doesn't require me to #include  to
> define it.  in mingw and mingw-w64, one must #include . why?

It is enough, I guess.. Include windows.h if you want,
why is that a problem?

>
> point 2: there are also __int32 __int16 and __int8 types.
>

MinGW has them all of as macros, because :
- gcc doesn't have native support for them
- and for some compatibility issues.

> point 3: mingw does not utilize the i64 constant thingy (whatever it's
> called) that tells the compiler that this number is of __int64 type.  I do
> not know if there is an i32 or i16 or i8 definition.

Not mingw, but GCC doesn't support those suffixes. I suggest:

#include 
__int64 x=INT64_C(12345678901234567);

Yeah, msvc doesn't have stdint.h, inttypes.h, but
you can get msvc-compatible versions of them from
http://msinttypes.googlecode.com/

>
>
> BTW, 128-bit number type is in the C9X standard.  the new integral data
> types in C++ will be something like int64, int32, int128, int16, int8.
>
> http://www.open-std.org/JTC1/sc22/wg14/www/docs/n615.htm
>

Hmm, mingw-w64 has an __int128 as a typedef.
If it goes as planned, gcc-4.6 will have that natively
in future.

> Jim Michaels
> jmich...@yahoo.com(main)

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] OpenCL & Cuda - def files from windows dll's

[Ozkan Sezer]

On Tue, Mar 9, 2010 at 9:13 AM, Pauli Sundberg  wrote:
> Hello!
>
> I mentioned last week on IRC that i succesfully compiled with mingw64
> 64bit windows (7) applications, that used OpenCL and Cuda (GPU computing
> libraries).
>
> The thing worked well by using gendef to create .def files from the
> corresponding .dll's and then using libtool to create import libraries.
>
> Link and run, and everything went fine.
>
> The def files for 32bit and 64bit OpenCL are attached (original dll
> names are OpenCL.dll for both).
>
> The def files for 32bit and 64bit CUDA are attached (original dll names
> are nvcuda.dll for both)
>
>
>
> Pauli!


On Mon, Mar 15, 2010 at 11:07 AM, Pauli Salmivuori  wrote:
> Hallo!
>
> Header files for 32b/64bit windows api for OpenCL and Cuda (driver
> interface) attached as requested.
>
> I fast checked with diff and all 32bit header files are identical to
> corresponding 64bit headers.
> I attached them all anyway as size is small and human error is more than
> possible.
>
> If you want to confirm this, the headers can be found from Nvidia site:
> http://forums.nvidia.com/index.php?showtopic=149959 (Beta 3 download)
> and there X bit toolkit.
>
> Currently:
> http://developer.download.nvidia.com/compute/cuda/3_0-Beta1/toolkit/cudatoolkit_3.0-beta1_win_32.exe
> http://developer.download.nvidia.com/compute/cuda/3_0-Beta1/toolkit/cudatoolkit_3.0-beta1_win_64.exe
>
> About 50Mb each.
>
> What i have tested so far is to compile 32bit and 64bit program against
> single 64bit headers and use
> corresponding import library from Xbit .dll, and everything seemed to work
> fine (numerical results were ok).
>
> The .zip files contains original headers in ./ directory, the 32bits_cuda.h
> original name is "cuda.h" as
> is the case with 64bit.
>
> Pauli!

In the 32 bit version of the OpenCL def file, you need the
__stcall suffix of @0 for clUnloadCompiler, ie:
clunloadcompi...@0
This is a problem with gendef which cannot differentiate
a function accepting no arguments from being __cdecl
or __stdcall.  Of course the 64 bit version is not affected.

The headers: the 32 bit and 64 bit versions are identical.

For cuda, they look way too commercial, but for OpenCL
from the Khronos group, that is fine for anyone to include
or distribute, I think. This may serve as a reference to users
seeking this kind of knowledge, thanks.

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Need help debugging...

[Ozkan Sezer]

On Tue, Mar 16, 2010 at 5:15 AM, David Cleaver  wrote:
>
> Kai Tietz wrote:
>> Hello David,
>>
>> The problem you've shown is reasoned by using a gdb built without
>> libexpat. You can download a more current version from our SF file
>> sections (see Tools), which is build with libexpat. If gdb isn't built
>> by it, debugging information from DLLs won't be loaded.
>>
>> Hope this solves your issue,
>>
>> Kai
>
> Hello Kai,  the original version of gdb I had gave this output:
> GNU gdb (GDB) 7.0.50.20100123-cvs
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-w64-mingw32".
> For bug reporting instructions, please see:
> .
>
> I just downloaded the latest personal build from Ozkan and now it says:
> GNU gdb (GDB) 7.1.50.20100313-cvs
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-w64-mingw32".
> For bug reporting instructions, please see:
> .
>
> How can I tell if either one was built with libexpat?  When I run my program
> through either gdb, it gives the same error.  I'm going to try and step 
> through
> the whole program and see what happens just before the crash.
>
> -David C.

AFAIK, you may not tell the difference, and I'm afraid
that the 20100123 version you just tried may not have
been compiled against expat either. FWIW, I will compile
gdb against expat in my next personal builds. ... and
even made a version just now, see if this works for you:
http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/gdb/x86_64-w64-mingw32-gdb-7.0.50.20100314.zip/download

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Need help debugging...

[Ozkan Sezer]

On Tue, Mar 16, 2010 at 2:18 PM, David Cleaver  wrote:
>
> Ozkan Sezer wrote:
>> AFAIK, you may not tell the difference, and I'm afraid
>> that the 20100123 version you just tried may not have
>> been compiled against expat either. FWIW, I will compile
>> gdb against expat in my next personal builds. ... and
>> even made a version just now, see if this works for you:
>> http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/gdb/x86_64-w64-mingw32-gdb-7.0.50.20100314.zip/download
>>
>> --
>> Ozkan
>>
>
> Thank you for that build.  I no longer get the "built without XML" error from
> before.  However, I still get the same info from gdb.  Now that I'm stepping
> through the code one line at a time until the crash, gdb isn't giving me any
> output from the assembly code file where it is crashing.  Is there another
> option I should use when I compile to enable this?  Here is a sample of output
> from stepping through gdb:
> (gdb) s
> 92      in redc.s
> (gdb) s
> 93      in redc.s
> (gdb) s
> UnrollLoop () at redc.s:96
> 96      in redc.s
> (gdb) s
> 97      in redc.s
> (gdb) s
> 98      in redc.s
> (gdb) s
> 99      in redc.s
> (gdb) s
> 100     in redc.s
> (gdb) s
> 101     in redc.s
> (gdb) s
> 102     in redc.s
> (gdb) s
> 105     in redc.s
> (gdb) s
>
> Program received signal SIGSEGV, Segmentation fault.
> UnrollLoop () at redc.s:105
> 105     in redc.s
> (gdb) s
>
> Program received signal SIGSEGV, Segmentation fault.
> UnrollLoop () at redc.s:105
> 105     in redc.s
> (gdb) s
>
> Program exited with code 0200.
> (gdb) s
> (gdb) The program is not being run.
>
> Any suggestions on how I should proceed?  I don't know how to use gdb very 
> well.
>  If anyone has any tips or tricks on how to trouble shoot this problem I'd
> appreciate it very much.  Thanks for your time.
>
> -David C.

I'm not very much competent in using gdb, either,
(and I did lose the beginnings of this thread, sorry ;)
so others, especially Kai would be of more help I
think.

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Question about the undercore in svn

[Ozkan Sezer]

On Sun, Mar 21, 2010 at 7:21 PM, NightStrike  wrote:
> Well, this is a problem, yes.  It only affects the multilib builds,
> though, which don't really work anyway without a lot of effort.  And
> this will all be fixed for 4.6, o we won't need to worry about it.
>
> If users really want it, though, I can rework things to exclude 32-bit
> entirely.  It's just a little messy in Makefile.am.
>
> On Sun, Mar 21, 2010 at 12:24 PM, Doug Semler  wrote:
>> Quick question:
>>
>> Are you sure you want to disable the leading underscore on the 32bit side 
>> with
>> the --disable-leading-underscore and multilib?  Looking at it (without 
>> testing
>> it, that is), it doesn't seem to me that it is appropriate...

I think the flag really should be added to the lib64
versions in the makefiles. Otherwise things would
go far messier the may think of.

Besides that, there really is no way to tell the user
as to how the crt was actually compiled. If there
were a config header installed from within the crt
build, maybe..

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Question about the undercore in svn

[Ozkan Sezer]

On Sun, Mar 21, 2010 at 7:55 PM, Kai Tietz  wrote:
> 2010/3/21 Ozkan Sezer :
>> On Sun, Mar 21, 2010 at 7:21 PM, NightStrike  wrote:
>>> Well, this is a problem, yes.  It only affects the multilib builds,
>>> though, which don't really work anyway without a lot of effort.  And
>>> this will all be fixed for 4.6, o we won't need to worry about it.
>>>
>>> If users really want it, though, I can rework things to exclude 32-bit
>>> entirely.  It's just a little messy in Makefile.am.
>>>
>>> On Sun, Mar 21, 2010 at 12:24 PM, Doug Semler  wrote:
>>>> Quick question:
>>>>
>>>> Are you sure you want to disable the leading underscore on the 32bit side 
>>>> with
>>>> the --disable-leading-underscore and multilib?  Looking at it (without 
>>>> testing
>>>> it, that is), it doesn't seem to me that it is appropriate...
>>
>> I think the flag really should be added to the lib64
>> versions in the makefiles. Otherwise things would
>> go far messier the may think of.
>
> I agree, that it maybe gets for x86 much messier. And if possible, it
> would be better to have this underscoring just active for x64.
>

You mean that we should make no-underscore the
default for x64?

>> Besides that, there really is no way to tell the user
>> as to how the crt was actually compiled. If there
>> were a config header installed from within the crt
>> build, maybe..
>
> Hmm, for what this header should be? I see the issue that an user
> can't see directly by which option for underscoring the crt was built,
> but for this a header makes also no sense. To detect this a call of nm
> reveals, if underscoring was active or not.
> I don't think that we should introduce for this something in
> configure. The header itself aren't affected, as they are checking the
> underscoring mode of gcc directly.

Yes, _mingw_mac.h does that, figures what mode
gcc is currently in. A generated header from crt
compile time would be designed to indicate how
it was compiled would be helpful to user: Suppose
you compile a tree but the result was a link failure
after one or two hours, how many remaining teeth
would the user have after such an experience?

>
> Kai
>
>
> --
> |  (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Include paths, float.h

[Ozkan Sezer]

On Sun, Mar 21, 2010 at 10:42 PM, Dave Camarillo
 wrote:
> Hello, I'm having a little trouble with the include paths used by mingw-w64
> and was hoping for some insight... I have this chunk of code compiling
> correctly under the normal mingw system, but have some problems with include
> search paths with the w64 version... As far as I can tell, it's just pulling
> in the wrong version of float.h? but since it's system include paths, I'm
> not entirely sure how to get it to use the right paths After inspecting
> the header it looks like this is an MS specific feature, thus the reason
> it's not in the normal GCC header. I'm actually trying to compile a larger
> linear-algebra library, but it wants the MS specifics when it's being
> compiled on a MS box. Trivial source code, error messages and debug output
> are below...
>
> Thoughts?
>
>
> Thanks,
> -d
>
> #include 
> int main(int argc, char* argv) {
>     long i = _EM_DENORMAL;
>     return(0);
> }
>
>
> $ gcc -c test.c
> test.c: In function 'main':
> test.c:5:11: error: '_EM_DENORMAL' undeclared (first use in this function)
> test.c:5:11: error: (Each undeclared identifier is reported only once
> test.c:5:11: error: for each function it appears in.)
>
>
> $ gcc -M -c test.c
> test.o: test.c \
>  c:\msys\system64\bin-4.5.0\../lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h

Just delete this particular one from your installation ...

>
>
> $ cat /c/msys/system64/lib/gcc/x86_64-w64-mingw32/4.5.0/include/float.h |
> grep EM_DENORMAL
> 
>
>
> There is a different header that has what I'm looking for:
>
> $ cat /c/msys/system64/x86_64-w64-mingw32/include/float.h | grep EM_DENORMAL
> #define _EM_DENORMAL    0x0008

... and this will be included by your source, instead.

For some reason yet unknown to me, the gcc-provided headers
have priority over the system provided headers and float.h is
especially problematic: Not installing or deleting it is the solution,
at least for now.

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Include paths, float.h

[Ozkan Sezer]

On Mon, Mar 22, 2010 at 2:51 AM, NightStrike  wrote:
> On Sun, Mar 21, 2010 at 7:41 PM, Doug Semler  wrote:
>> On Sun, 21 Mar 2010 19:22:48 NightStrike wrote:
>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer  wrote:
>>> > For some reason yet unknown to me, the gcc-provided headers
>>> > have priority over the system provided headers and float.h is
>>> > especially problematic: Not installing or deleting it is the solution,
>>> > at least for now.
>>>
>>> If gcc headers didn't take priority, then fixincludes wouldn't work.
>>>
>>> The real question is why gcc forces changes to system headers instead
>>> of working with system headers.
>>>
>>
>> Does gcc even necessarily have the system headers available to it on a clean
>> system during a build?   I don't think so...which means that gcc may not know
>> about the system headers when it runs through the stage of installation...
>>
>> In other words, for it to even work with the system headers, the system
>> headers have to be installed correctly before you do the first make 
>> install-gcc
>> during a bootstrap...
>>
>> (and I know the one howto build doc says install the headers first, but
>> unfortunately building the toolchain does not fail if you do NOT do this...)
>>
>
> Building the toolchain does in fact fail.  Just, not at the all-gcc
> stage (the bootstrapping stage).  Do a make all-gcc.  When it
> finishes, do "make all".  It'll die immediately asking for a valid
> sysroot.
>

Building with the --with-sysroot option makes the toolchain nicely
relocatable, but we have this issue of gcc-provided headers having
priority over the system provided headers. (and also the problem
with the native toolchains that the /include directory not
being used for the header search, too.) AFAIK, mingw.org doesn't
build with sysroot option, and they don't have the problem specified
in this thread, however that method of build seems to result in some
relocation issues as in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
The current situation of gcc on this thing is a big 'Ouch'..

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Include paths, float.h

[Ozkan Sezer]

On Tue, Mar 23, 2010 at 2:17 PM, NightStrike  wrote:
> On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz  wrote:
>> 2010/3/23 NightStrike :
>>> On Tue, Mar 23, 2010 at 12:57 AM, Mook
>>>  wrote:
>>>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike  wrote:
>>>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer  wrote:
>>>>>> For some reason yet unknown to me, the gcc-provided headers
>>>>>> have priority over the system provided headers and float.h is
>>>>>> especially problematic: Not installing or deleting it is the solution,
>>>>>> at least for now.
>>>>>
>>>>> If gcc headers didn't take priority, then fixincludes wouldn't work.
>>>>>
>>>>> The real question is why gcc forces changes to system headers instead
>>>>> of working with system headers.
>>>>
>>>> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't
>>>> been able to come up with a patch that I don't hate yet.  If something
>>>> can be done, it would probably involve defining INCLUDE_DEFAULTS in
>>>> config/i386/mingw-w64.h somehow, but the temporary workaround I have
>>>> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot
>>>> prefix builds, so that's not useful.
>>>>
>>>> Mostly sending this just so the mailing list archive can help remember
>>>> this for me ;)
>>>>
>>>> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44
>>>>
>>>> --
>>>> Mook
>>>>
>>>
>>> The real fix is to sync what gcc wants with what we have, with
>>> appropriate changes on both sides.
>>>
>>> --
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> ___
>>> Mingw-w64-public mailing list
>>> Mingw-w64-public@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>>
>>
>> We (Ozkan and I) already tried to push necessary changes to gcc. But
>> well, people love their POSIX stuff and dislike even an include next
>> here. Problem is also that mingw.org don't provide those headers in
>> their CRT at all, so a change here as to be runtime-specific, which
>> messes things a bit (include of _mingw.h and checking for runtime).
>> Best solution is (as work-around) to remove those headers from gcc's
>> /lib/gcc///include directory
>
> That's hardly "best".  We need to try again, and get GCC to listen.
>
> I don't care about mingw.org... we can do something vendor-specific
> for that.  But I do care about having GCC do a fixincludes on our

My first suggestion *was* vendor specific which disabled
those three headers' installation by gcc:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html
The thread went some time and then get lost, feel free
to revive it if you want. The solution in that initial post above
is what I already use in my personal builds and it works.

> headers, that we then revert.  That's just plain stupid.
>
> Who's the GCC maintainer that we need to hit over the head?

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Include paths, float.h

[Ozkan Sezer]

On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz  wrote:
> 2010/3/23 Ozkan Sezer :
>> On Tue, Mar 23, 2010 at 2:17 PM, NightStrike  wrote:
>>> On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz  wrote:
>>>> 2010/3/23 NightStrike :
>>>>> On Tue, Mar 23, 2010 at 12:57 AM, Mook
>>>>>  wrote:
>>>>>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike  
>>>>>> wrote:
>>>>>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer  wrote:
>>>>>>>> For some reason yet unknown to me, the gcc-provided headers
>>>>>>>> have priority over the system provided headers and float.h is
>>>>>>>> especially problematic: Not installing or deleting it is the solution,
>>>>>>>> at least for now.
>>>>>>>
>>>>>>> If gcc headers didn't take priority, then fixincludes wouldn't work.
>>>>>>>
>>>>>>> The real question is why gcc forces changes to system headers instead
>>>>>>> of working with system headers.
>>>>>>
>>>>>> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't
>>>>>> been able to come up with a patch that I don't hate yet.  If something
>>>>>> can be done, it would probably involve defining INCLUDE_DEFAULTS in
>>>>>> config/i386/mingw-w64.h somehow, but the temporary workaround I have
>>>>>> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot
>>>>>> prefix builds, so that's not useful.
>>>>>>
>>>>>> Mostly sending this just so the mailing list archive can help remember
>>>>>> this for me ;)
>>>>>>
>>>>>> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44
>>>>>>
>>>>>> --
>>>>>> Mook
>>>>>>
>>>>>
>>>>> The real fix is to sync what gcc wants with what we have, with
>>>>> appropriate changes on both sides.
>>>>>
>>>>
>>>> We (Ozkan and I) already tried to push necessary changes to gcc. But
>>>> well, people love their POSIX stuff and dislike even an include next
>>>> here. Problem is also that mingw.org don't provide those headers in
>>>> their CRT at all, so a change here as to be runtime-specific, which
>>>> messes things a bit (include of _mingw.h and checking for runtime).
>>>> Best solution is (as work-around) to remove those headers from gcc's
>>>> /lib/gcc///include directory
>>>
>>> That's hardly "best".  We need to try again, and get GCC to listen.
>>>
>>> I don't care about mingw.org... we can do something vendor-specific
>>> for that.  But I do care about having GCC do a fixincludes on our
>>
>> My first suggestion *was* vendor specific which disabled
>> those three headers' installation by gcc:
>> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html
>> The thread went some time and then get lost, feel free
>> to revive it if you want. The solution in that initial post above
>> is what I already use in my personal builds and it works.
>>
>>> headers, that we then revert.  That's just plain stupid.
>>>
>>> Who's the GCC maintainer that we need to hit over the head?
>>
>> --
>> Ozkan
>>
>
> It is the use of USER, right? This is fine at the moment, but I

Yes, the USER_H mechanism.

> dislike it as we then have to maintain changes of gcc within our
> headers. What's about using fixinclude here? See gcc's bug-tracker
> 40722 item, where HJ uses this to fix _rotl/_rolr issue.

I can't understand, how can a fixinclude fix this thing??

>
> Kai

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Include paths, float.h

[Ozkan Sezer]

On Tue, Mar 23, 2010 at 2:52 PM, Kai Tietz  wrote:
> 2010/3/23 Ozkan Sezer :
>> On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz  wrote:
>>> 2010/3/23 Ozkan Sezer :
>>>> On Tue, Mar 23, 2010 at 2:17 PM, NightStrike  wrote:
>>>>> On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz  
>>>>> wrote:
>>>>>> 2010/3/23 NightStrike :
>>>>>>> On Tue, Mar 23, 2010 at 12:57 AM, Mook
>>>>>>>  wrote:
>>>>>>>> On Sun, Mar 21, 2010 at 4:22 PM, NightStrike  
>>>>>>>> wrote:
>>>>>>>>> On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer  
>>>>>>>>> wrote:
>>>>>>>>>> For some reason yet unknown to me, the gcc-provided headers
>>>>>>>>>> have priority over the system provided headers and float.h is
>>>>>>>>>> especially problematic: Not installing or deleting it is the 
>>>>>>>>>> solution,
>>>>>>>>>> at least for now.
>>>>>>>>>
>>>>>>>>> If gcc headers didn't take priority, then fixincludes wouldn't work.
>>>>>>>>>
>>>>>>>>> The real question is why gcc forces changes to system headers instead
>>>>>>>>> of working with system headers.
>>>>>>>>
>>>>>>>> FWIW, I believe this is set in gcc/cppdefaults.c [1] but I haven't
>>>>>>>> been able to come up with a patch that I don't hate yet.  If something
>>>>>>>> can be done, it would probably involve defining INCLUDE_DEFAULTS in
>>>>>>>> config/i386/mingw-w64.h somehow, but the temporary workaround I have
>>>>>>>> (#define PREFIX_INCLUDE_DIR TOOL_INCLUDE_DIR) breaks non-sysroot
>>>>>>>> prefix builds, so that's not useful.
>>>>>>>>
>>>>>>>> Mostly sending this just so the mailing list archive can help remember
>>>>>>>> this for me ;)
>>>>>>>>
>>>>>>>> [1] http://gcc.gnu.org/viewcvs/trunk/gcc/cppdefault.c?view=markup#l44
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mook
>>>>>>>>
>>>>>>>
>>>>>>> The real fix is to sync what gcc wants with what we have, with
>>>>>>> appropriate changes on both sides.
>>>>>>>
>>>>>>
>>>>>> We (Ozkan and I) already tried to push necessary changes to gcc. But
>>>>>> well, people love their POSIX stuff and dislike even an include next
>>>>>> here. Problem is also that mingw.org don't provide those headers in
>>>>>> their CRT at all, so a change here as to be runtime-specific, which
>>>>>> messes things a bit (include of _mingw.h and checking for runtime).
>>>>>> Best solution is (as work-around) to remove those headers from gcc's
>>>>>> /lib/gcc///include directory
>>>>>
>>>>> That's hardly "best".  We need to try again, and get GCC to listen.
>>>>>
>>>>> I don't care about mingw.org... we can do something vendor-specific
>>>>> for that.  But I do care about having GCC do a fixincludes on our
>>>>
>>>> My first suggestion *was* vendor specific which disabled
>>>> those three headers' installation by gcc:
>>>> http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01034.html
>>>> The thread went some time and then get lost, feel free
>>>> to revive it if you want. The solution in that initial post above
>>>> is what I already use in my personal builds and it works.
>>>>
>>>>> headers, that we then revert.  That's just plain stupid.
>>>>>
>>>>> Who's the GCC maintainer that we need to hit over the head?
>>>>
>>>> --
>>>> Ozkan
>>>>
>>>
>>> It is the use of USER, right? This is fine at the moment, but I
>>
>> Yes, the USER_H mechanism.
>>
>>> dislike it as we then have to maintain changes of gcc within our
>>> headers. What's about using fixinclude here? See gcc's bug-tracker
>>> 40722 item, where HJ uses this to fix _rotl/_rolr issue.
>>
>> I can't understand, how can a fixinclude fix this thing??
>
> It could add the include pattern to those headers. Did I got here
> something wrong?
> (a fix-include can be target-specific as shown in HJ's code).
>

Hmm, well, I'd like to see such a patch hopefully fixing
all problems with float.h, stddef.h and stdarg.h...

> Kai
>

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Include paths, float.h

[Ozkan Sezer]

On Tue, Mar 23, 2010 at 3:00 PM, NightStrike  wrote:
> On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer  wrote:
>> I can't understand, how can a fixinclude fix this thing??
>
> As I understand it, our headers are already being fixincluded. It's
> fixincludes that causes GCC to override us.  That means that there's
> stuff in our headers that GCC doesn't like.
>

No, absolutely not. Can't you see what is already
in your own fixinclude directory in your installation?
The problem is with the headers installed by gcc
by default.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problem building a static gsl-1.14

[Ozkan Sezer]

On Wed, Mar 24, 2010 at 2:15 PM, Sisyphus  wrote:
> Hi,
>
> I've posted to gsl-bugs about this ... without success. I'm not even sure
> that it's a gsl bug - there's a thread at
> http://www.mail-archive.com/bug-libt...@gnu.org/msg00374.html where the
> error is of a very similar type. In that particular instance it turned out
> to be a libtool (ltmain.sh) bug. However, I've been unable to adapt the
> ltmain.sh patch that worked there to my particular situation.
>
> No problems with a dynamic build of gsl-1.14, btw ... it's just the static
> build that's being uncooperative.
>
> When trying to build a static gsl-1.14 library with mingw64 in the MSYS
> shell, I start with:
>
> $ ./configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
> CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++
> AR=x86_64-w64-mingw32-ar
> LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm
> RANLIB=x86_64-w64-mingw32-ranlib --disable-shared --enable-static && make
>
> (For the dynamic build I use the same, except that it's
> "--disable-static --enable-shared".)
> Everything is fine until we get near the end of the make process, when this
> happens:
>
> ##
> /bin/sh ./libtool --tag=CC   --mode=link
> x86_64-w64-mingw32-gcc  -g -O2 -version-info 15:0:15 -no-undefined  -o
> libgsl.la -rpath /usr/local/lib version.lo block/libgslblock.la
> blas/libgslblas.la bspline/libgslbspline.la
> [SNIP lots of other.la files]
> wavelet/libgslwavelet.la cblas/libgslcblas.la -lm
> libtool: link: (cd .libs/libgsl.lax/libgslblock.a && x86_64-w64-mingw32-ar x
> "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a")
> libtool: link: object name conflicts in archive:
> .libs/libgsl.lax/libgslblock.a//c/_64/comp/gsl-1.14/block/.libs/libgslblock.a
> make[2]: *** [libgsl.la] Error 1
> make[2]: Leaving directory `/c/_64/comp/gsl-1.14'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/c/_64/comp/gsl-1.14'
> make: *** [all] Error 2
> ###
>
> The 'cd .libs/libgsl.lax/libgslblock.a && x86_64-w64-mingw32-ar x
> "/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a"' command apparently
> succeeds - the 3
> object files in libgslblock.a are to be found in the
> .libs/libgsl.lax/libgslblock.a/ folder.
>
> Does that error mean anything to anyone here ?
> Any advice on something I could try to get around it ?
>
> My "x86_64-w64-mingw32-gcc -v" is provided below my sig.
>
> Cheers,
> Rob
>
> r...@desktop2 ~
> $ x86_64-w64-mingw32-gcc -v
> Using built-in specs.
> Target: x86_64-w64-mingw32
> Configured with:
> ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 
> --prefix=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root
>  --with-sysroot=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root 
> --with-gmp=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/gmp/install
>  
> --with-mpfr=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpfr/install
>  
> --with-mpc=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpc/install
>  --enable-languages=all,obj-c++ --enable-fully-dynamic-string 
> --disable-multilibThread model: win32gcc version 4.4.4 20100208 
> (prerelease)(GCC)
>

Interesting, I cant reproduce this error: I cross-compiled
the package on linux for x64, configured like
../gsl-1.14/configure --host=x86_64-w64-mingw32 --disable-shared --enable-static
and did a 'make -j2', no errors, make install to a temporary
also succeeded. Notice that I built in a separate
directory, although I'm unsure about how it can make
a difference here. My 'x86_64-w64-mingw32-gcc -v' output:
Using built-in specs.
Target: x86_64-w64-mingw32
Configured with: ../gcc44-svn/configure --target=x86_64-w64-mingw32
--disable-multilib --enable-checking=release --prefix=/opt/cross_win64
--with-sysroot=/opt/cross_win64
--enable-languages=c,c++,fortran,objc,obj-c++ --disable-nls
Thread model: win32
gcc version 4.4.4 20100322 (prerelease) [svn/rev.157644 - mingw-w64/oz] (GCC)

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fixes for ddk headers

[Ozkan Sezer]

On Wed, Mar 31, 2010 at 9:21 PM, NightStrike  wrote:
> You can send them to our patch tracker:
>
> http://sourceforge.net/tracker/?group_id=202880&atid=983356
>
> On Wed, Mar 31, 2010 at 2:17 PM, Wiljan Derks  wrote:
>> I have been trying to build 64 bits drivers for windows and finally
>> succeeded to get it working.
>> It looks as if I am the first to try, since I found several errors in the
>> header files.
>> I would like to share these updates, but do not know where to send them.
>>
>> Does anyone know who deals with them ?
>>
>> Wiljan

The ddk headers in our repository are by an external svn link to the
reactos repository. Therefore they come from the ReactOS project.
Note: Even if the revision number of our repository seems unchanged,
always do a "svn update" to see if the ddk headers have had any
change at the reactos site. And any changes to the ddk headers
may probably need sending to the ReactOS developers, but
NightStrike & other admins may correct me here.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problem using gcc (now with correct bin path)

[Ozkan Sezer]

On Wed, Apr 7, 2010 at 6:44 PM, Simon de Graaf  wrote:
> I have installed the mingw-w64 compiler etc. in my 3rdparty directory
> but cannot run it like the mingw32 compiler.
> For example:
>
> % set path = ( /my3rdparty/win64/x86_64-w64-mingw32/bin /usr/bin /bin )

The executables under that /my3rdparty/win64/x86_64-w64-mingw32/bin
are not supposed to be run directly by the user. Try running the ones under
your /my3rdparty/win64/bin instead.

> % rehash
> % gcc addcr.c
> gcc: error trying to exec 'cc1': execvp: No such file or directory
>
> % set path = ( /my3rdparty/win64/bin /usr/bin /bin )
> % rehash
> % x86_64-w64-mingw32-gcc addcr.c
> this works (also if i install gcc in the same bin directory, it works)
>
> Not all the 3rdparty packages, i have, uses this full cross compiler name.
> Note, that the mingw32 compiler does not have this problem.
>
> Simon de Graaf
>

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Custom toolchain build with gcc-4.4.4 (2010-04-10)

[Ozkan Sezer]

To anyone who might be interested: I updated my custom w32/w64 native
and cross-compiler build with gcc-4.4 with several backports and fixes
from mainstream and put them under the mingw-w64 sf.net file release
system under the subdirectories:
-  Toolchain sources -> Personal Builds,
-  Toolchains targetting Win32 -> Personal Builds  and
-  Toolchains targetting Win64 -> Personal Builds
[as of this writing, uploading still in progress.]

Changes since the previous 2010-03-27 build:
- The mingw-w64 crt and headers updated to r2159.
- Gcc updated to the 4.4.4 prerelease version, svn rev. 158146.
- All other software has been updated to the latest available versions
  as of 2010-04-10, 13:00 GMT.
- New in this build is that I enabled OpenMP (libgomp) and providing
  pthreads-win32 because libgomp requires it. As a safeguard, pthreads
  is not "installed" by default (several reasons), but it is provided as
  a zip or a tar.gz archive in the binary packages. If you need pthreads
  or OpenMP (libgomp), then just extract the pthreads-win32 package into
  your toolchain installation.

- Note: the /include path "problem" of the native builds is
  not looked into, yet. Maybe in the future builds.


Versions:
-

Common in both cross- and native-toolchains:

gcc : svn rev. 158146 (4.4.4 prerelease with many patches)
binutils : 2.20.51 (cvs, 2010-03-10 12:55 GMT)
mingw-w64-crt : svn revision 2159 (2010-04-08)
mingw-w64-headers : svn revision 2157 (2010-04-08), with a
 couple of patches.
glext headers: 2010-03-11 (from the Khronos Group)
pthreads-win32: 2.9.0 (cvs, 2010-02-28 20:00 GMT)
 with w64 patch applied.

In native-toolchains only:

gmp : 4.3.2 (with w64 patch applied)
mpfr: 2.4.2-p3
mpc : 0.8.1
gdb : 7.1.50 (cvs, 2010-04-10 12:55 GMT, with
 minor w64 patches applied.)
make: 3.81.90 (cvs, 2010-02-02 15:20 GMT, with
 w64 patches applied according to savannah bug
 items 27809 and 27825, and patched further to
 kill a horde of compiler warnings)
gendef, libmangle: from mingw-w64 svn/trunk


File names:
---

* Source:

- mingw-w64-src_20100410_sezero.tar.gz


* Targetting Win64:

- mingw-w64-bin_x86_64-mingw_20100410_sezero.zip
  native compiler toolchain for running on x64-windows
  host and creating x64-windows binaries.

- mingw-w64-bin_i686-mingw_20100410_sezero.zip
  cross compiler toolchain for running on x86-windows
  host but creating x64-windows binaries.

- mingw-w64-bin_i686-linux_20100410_sezero.tar.gz
  cross compiler toolchain for running on a i686-linux
  host and creating x64-windows binaries.

- mingw-w64-bin_x86_64-linux_20100410_sezero.tar.gz
  cross compiler toolchain for running on a x86_64-linux
  host and creating x64-windows binaries.


* Targetting Win32:

- mingw-w32-bin_i686-mingw_20100410_sezero.zip
  native compiler toolchain for running on x86-windows
  host and creating x86-windows binaries.

- mingw-w32-bin_i686-linux_20100410_sezero.tar.gz
  cross compiler toolchain for running on a i686-linux
  host and creating x86-windows binaries.

- mingw-w32-bin_x86_64-linux_20100410_sezero.tar.gz
  cross compiler toolchain for running on a x86_64-linux
  host and creating x86-windows binaries.

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] trouble building gmp 4.3.2 in cygwin

[Ozkan Sezer]

On Tue, Apr 13, 2010 at 11:15 PM, Martin Rubey
 wrote:
> Hi all (especially Ozkan),
>

Hi,

> I tried to cross-compile gmp 4.3.2 in cygwin, but failed, the log is here:
>
> http://sprunge.us/hSOY
>
> I believe the relevant bit is near the end, copied below.
>
> Invocation was:
>
> /home/Mari/ecl-10.3.1-x64/src/gmp/configure --disable-shared
> --prefix=/home/Mari/ecl-10.3.1-x64/build
> --infodir=/home/Mari/ecl-10.3.1-x64/build/doc
> --includedir=/home/Mari/ecl-10.3.1-x64/build/ecl --with-pic
> --libdir=/home/Mari/ecl-10.3.1-x64/build --build=i686-pc-cygwin
> --host=x86_64-w64-mingw32 CFLAGS=-g -O2   LDFLAGS=  CPPFLAGS=
> CC=x86_64-w64-mingw32-gcc  ABI=64
[...]
> configure:33118: error: Oops, mp_limb_t is 32 bits, but the assembler
> code
> in this configuration expects 64 bits.

Unlike gmp-5.0.x which is w64-ready out of the box,
gmp-4.3.2 needs a win64 patch for it to compile and
function correctly. The patch is here:
http://sourceforge.net/projects/mingw-w64/files/mingw-w64/Toolchain%20patches/gmp-4.3.2-w64.patch/download

Hope this helps.

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] trouble building gmp 4.3.2 in cygwin

[Ozkan Sezer]

On Wed, Apr 14, 2010 at 10:37 AM, Martin Rubey
 wrote:
> Ozkan Sezer  writes:
>
> many thanks for the patch.  The gmp configures fine now.  Unfortunately,
> I'm still having trouble configuring ecl.
>
> The config.log is at
>
> http://sprunge.us/SWHX
>
> the relevant bit is the very end, I think:
>
> configure:8035: checking size of long long
> configure:8085: error: in `/home/Mari/ecl-10.3.1-x64/build':
> configure:8088: error: cannot run test program while cross compiling
> See `config.log' for more details.
>

I am not familiar with ecl, nor with its configury,
although the problem seems to be with its configury
itself. Checking for a size with knowledge that it
cannot while cross-compiling should be an oversight
in that software's configuration system. Updating it
to use newer autoconf would help, I guess, but
other developers here may have more to say on
that.

> The relevant bit of ecl's configure is (hopefully) below...
>
> Thanks again,
>
> Martin
>
>
> { $as_echo "$as_me:$LINENO: checking size of long long" >&5
> $as_echo_n "checking size of long long... " >&6; }
> if test "$GCC" = yes; then
>  ac_cv_c_long_long=yes
> else
>  cat >conftest.$ac_ext <<_ACEOF
> /* confdefs.h.  */
> _ACEOF
> cat confdefs.h >>conftest.$ac_ext
> cat >>conftest.$ac_ext <<_ACEOF
> /* end confdefs.h.  */
>
> int
> main ()
> {
> long long int i;
>  ;
>  return 0;
> }
> _ACEOF
> rm -f conftest.$ac_objext
> if { (ac_try="$ac_compile"
> case "(($ac_try" in
>  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
>  *) ac_try_echo=$ac_try;;
> esac
> eval ac_try_echo="\"\$as_me:$LINENO: $ac_try_echo\""
> $as_echo "$ac_try_echo") >&5
>  (eval "$ac_compile") 2>conftest.er1
>  ac_status=$?
>  grep -v '^ *+' conftest.er1 >conftest.err
>  rm -f conftest.er1
>  cat conftest.err >&5
>  $as_echo "$as_me:$LINENO: \$? = $ac_status" >&5
>  (exit $ac_status); } && {
>         test -z "$ac_c_werror_flag" ||
>         test ! -s conftest.err
>       } && test -s conftest.$ac_objext; then
>  ac_cv_c_long_long=yes
> else
>  $as_echo "$as_me: failed program was:" >&5
> sed 's/^/| /' conftest.$ac_ext >&5
>
>        ac_cv_c_long_long=no
> fi
>
> rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> fi
> if test $ac_cv_c_long_long = yes; then
>  if test "$cross_compiling" = yes; then
>  { { $as_echo "$as_me:$LINENO: error: in \`$ac_pwd':" >&5
> $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
> { { $as_echo "$as_me:$LINENO: error: cannot run test program while cross
> compili
> ng
> See \`config.log' for more details." >&5
> $as_echo "$as_me: error: cannot run test program while cross compiling
> See \`config.log' for more details." >&2;}
>   { (exit 1); exit 1; }; }; }
> else
>

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.4 (2010-04-10)

[Ozkan Sezer]

On Sat, Apr 17, 2010 at 11:01 PM, John Marriott
 wrote:
> Thanks Ozkan.
>
> I have been using your native builds on top of the autobuilds (eg
> mingw-64-1.0-bin_i686-mingw_20100405.zip...ie the 4.4 builds) with great
> success.
>

Thanks, glad to hear that it is useful for you.

> A question though: can I use them with the 4.6 autobuilds? I suspect not but
> I thought that I would ask anyway.
>

If I understood your question correctly, the answer is no: Different
toolchain builds should not be mixed with each other, not for two
from the same line (eg. two different autobuilds or two diffrent
personal builds), neither for different lines (eg. autobuilds + personal
builds.)

> Thanks again
> Cheers
> John

You're welcome.

--
Ozkan


>
> On 11-Apr-2010 08:05, Ozkan Sezer wrote:
>>
>> To anyone who might be interested: I updated my custom w32/w64 native
>> and cross-compiler build with gcc-4.4 with several backports and fixes
>> from mainstream and put them under the mingw-w64 sf.net file release
>> system under the subdirectories:
>> -  Toolchain sources ->  Personal Builds,
>> -  Toolchains targetting Win32 ->  Personal Builds  and
>> -  Toolchains targetting Win64 ->  Personal Builds
>> [as of this writing, uploading still in progress.]
>>
>> Changes since the previous 2010-03-27 build:
>> - The mingw-w64 crt and headers updated to r2159.
>> - Gcc updated to the 4.4.4 prerelease version, svn rev. 158146.
>> - All other software has been updated to the latest available versions
>>   as of 2010-04-10, 13:00 GMT.
>> - New in this build is that I enabled OpenMP (libgomp) and providing
>>   pthreads-win32 because libgomp requires it. As a safeguard, pthreads
>>   is not "installed" by default (several reasons), but it is provided as
>>   a zip or a tar.gz archive in the binary packages. If you need pthreads
>>   or OpenMP (libgomp), then just extract the pthreads-win32 package into
>>   your toolchain installation.
>>
>> - Note: the/include path "problem" of the native builds is
>>   not looked into, yet. Maybe in the future builds.
>>
>>
>> Versions:
>> -
>>
>> Common in both cross- and native-toolchains:
>>
>> gcc : svn rev. 158146 (4.4.4 prerelease with many patches)
>> binutils : 2.20.51 (cvs, 2010-03-10 12:55 GMT)
>> mingw-w64-crt : svn revision 2159 (2010-04-08)
>> mingw-w64-headers : svn revision 2157 (2010-04-08), with a
>>  couple of patches.
>> glext headers: 2010-03-11 (from the Khronos Group)
>> pthreads-win32: 2.9.0 (cvs, 2010-02-28 20:00 GMT)
>>  with w64 patch applied.
>>
>> In native-toolchains only:
>>
>> gmp : 4.3.2 (with w64 patch applied)
>> mpfr: 2.4.2-p3
>> mpc : 0.8.1
>> gdb : 7.1.50 (cvs, 2010-04-10 12:55 GMT, with
>>  minor w64 patches applied.)
>> make: 3.81.90 (cvs, 2010-02-02 15:20 GMT, with
>>  w64 patches applied according to savannah bug
>>  items 27809 and 27825, and patched further to
>>  kill a horde of compiler warnings)
>> gendef, libmangle: from mingw-w64 svn/trunk
>>
>>
>> File names:
>> ---
>>
>> * Source:
>>
>> - mingw-w64-src_20100410_sezero.tar.gz
>>
>>
>> * Targetting Win64:
>>
>> - mingw-w64-bin_x86_64-mingw_20100410_sezero.zip
>>   native compiler toolchain for running on x64-windows
>>   host and creating x64-windows binaries.
>>
>> - mingw-w64-bin_i686-mingw_20100410_sezero.zip
>>   cross compiler toolchain for running on x86-windows
>>   host but creating x64-windows binaries.
>>
>> - mingw-w64-bin_i686-linux_20100410_sezero.tar.gz
>>   cross compiler toolchain for running on a i686-linux
>>   host and creating x64-windows binaries.
>>
>> - mingw-w64-bin_x86_64-linux_20100410_sezero.tar.gz
>>   cross compiler toolchain for running on a x86_64-linux
>>   host and creating x64-windows binaries.
>>
>>
>> * Targetting Win32:
>>
>> - mingw-w32-bin_i686-mingw_20100410_sezero.zip
>>   native compiler toolchain for running on x86-windows
>>   host and creating x86-windows binaries.
>>
>> - mingw-w32-bin_i686-linux_20100410_sezero.tar.gz
>>   cross compiler toolchain for running on a i686-linux
>>   host and creating x86-windows binaries.
>>
>> - mingw-w32-bin_x86_64-linux_20100410_sezero.tar.gz
>>   cross compiler toolchain for running on a x86_64-linux
>>   host and creating x86-windows binaries.
>>
>> --
>> Ozkan
>>
>>
>> 

Re: [Mingw-w64-public] exceptions are not being caught on W7 platform (64 bit)

[Ozkan Sezer]

On Tue, Apr 20, 2010 at 11:45 AM, leon zadorin  wrote:
> On 4/20/10, leon zadorin  wrote:
>
>> there is anyone out there who is using mingw64 to build native W7
>> (pro) 64 bit simple (e.g. single-threaded) C++ applications which
>> throw exceptions and have them unwind using dwarf2 (i.e.
>> --disable-sjlj-exceptions)? Has it been done?
>
> Minor update -- I have just verified (on 4.4.3) that using
> slower/less-efficient (at least w.r.t. non-thrown exceptions)
> prologue/epilogue exception handling (i.e. omitting the
> --disable-sjlj-exceptions) fixes the issue -- the app catches the
> exception.
>
> I would like to know if there is any way to use dwarf2 eh though... my
> understanding is that they are more efficient/faster for cases when
> exceptions are not throw (which, by the very definition of an
> exception, should occur the vast majority of times)...

AFAIK, dwarf2 for w64 is verboten at the moment, not
yet implemented properly. (Kai may have more to say on
the matter.)  It is a bug in the 4.4.x configury that
it actually allows such a thing for x86_64-*-mingw32.

>
> kind regards
> Leon.
>

--
Ozkan


>> The C++ code which fails to catch is as follows:
>>
>> #include 
>> #include 
>>
>> int
>> main()
>> {
>>   try {
>>     ::std::cout << "about to throw\n";
>>     throw ::std::runtime_error("boo");
>>   } catch (::std::exception const & e) {
>>       ::std::cout << "wam\n";
>>   } catch (...) {
>>       ::std::cout << "bam\n";
>>   }
>>
>>   return 0;
>> }
>>
>> the above is compiled as:
>> c++ -static  main.cc
>>
>> the gcc was configured as:
>>
>> Target: x86_64-w64-mingw32
>> configure options:
>> --disable-threads --enable-languages=c++ --disable-sjlj-exceptions
>> --disable-libgomp --disable-nls --with-system-zlib --disable-libgcj
>> --target=x86_64-w64-mingw32 --disable-multilib
>>
>> Thread model: single
>> gcc version 4.4.3 (GCC) (but was also reproduced with 4.4.2)
>>
>> the collect/linking order is as follows:
>> collect2 -Bstatic crt2.o crtbegin.o /var/tmp//ccDhsQqG.o -lstdc++
>> -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt -luser32
>> -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_eh -lgcc -lmoldname
>> -lmingwex -lmsvcrt crtend.o
>>
>>
>> The W7 reports that app has asked the runtime environment to terminate
>> it in the unusual way (I presume it to be the usual thing it spits out
>> when terminate/abort/etc is done by the app).
>>
>> Any thoughts would be appreciated.
>>
>> Kind regards
>> Leon.
>>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] issue with gettimeofday()

[Ozkan Sezer]

On Tue, Apr 20, 2010 at 7:37 AM, Kai Tietz  wrote:
> Hi Patrick,
>
> 2010/4/20 Patrick Galbraith :
>> Hi all,
>>
>> I've stumbled across an issue with gettimeofday() returning an incorrect
>> value with mingw-w64. A simple code sample:
>>
>> #include 
>> #include 
>>
>> int main (void)
>> {
>>  struct timeval timer;
>>  int retval;
>>  retval= gettimeofday(&timer,NULL);
>>  fprintf(stderr, "retval: %d\n", retval);
>>  fprintf(stderr, "now: %ld\n", time(0));
>>  fprintf(stderr, "now: %ld\n", timer.tv_sec);
>>  return(0);
>>
>> }
>>
>> When compiled using -
>>
>> regular mingw (correct output)
>>
>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>> $ gcc -o mtime mtime.c
>>
>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>> $ ./mtime.exe
>> retval: 0
>> now: 1271722468
>> now: 1271722468
>>
>> mingw-w64:
>>
>>
>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>> $ /c/mingw/bin/x86_64-w64-mingw32-gcc -o mtime mtime.c
>>
>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>> $ ./mtime.exe
>> retval: 0
>> now: 1271722480
>> now: 31293027
>>
>> Are there any known issues with gettimeofday() with mingw-w64?
>>
>> Thanks!
>>
>> Patrick
>>
>> --
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
> what you are seeing here is that time_t type has changed for x64. x64
> doesn't use any longer a 32-bit time_t type. I use 64-bit wide scalar
> instead.
> If you want to have 32-bit time_t the use please the 32
> function set and use instead tim32_t type.
>
> Regards,
> Kai

I can't see the use of a time_t type anywhere in the report?
Is there a misunderstanding somewhere?

The problem may be due to strict aliasing violations.
A warning doesn't appear with default CFLAGS, but
after adding -Wstrict-aliasing=2, you get

gettimeofday.c: In function 'getntptimeofday':
gettimeofday.c:42: warning: dereferencing type-punned pointer will
break strict-aliasing rules

The mingw.org version of gettimeofday.c doesn't exhibit
such an issue. Proper use of a union as it the mingw.org
version might be a solution.

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] issue with gettimeofday()

[Ozkan Sezer]

On Tue, Apr 20, 2010 at 12:41 PM, Ozkan Sezer  wrote:
> On Tue, Apr 20, 2010 at 7:37 AM, Kai Tietz  wrote:
>> Hi Patrick,
>>
>> 2010/4/20 Patrick Galbraith :
>>> Hi all,
>>>
>>> I've stumbled across an issue with gettimeofday() returning an incorrect
>>> value with mingw-w64. A simple code sample:
>>>
>>> #include 
>>> #include 
>>>
>>> int main (void)
>>> {
>>>  struct timeval timer;
>>>  int retval;
>>>  retval= gettimeofday(&timer,NULL);
>>>  fprintf(stderr, "retval: %d\n", retval);
>>>  fprintf(stderr, "now: %ld\n", time(0));
>>>  fprintf(stderr, "now: %ld\n", timer.tv_sec);
>>>  return(0);
>>>
>>> }
>>>
>>> When compiled using -
>>>
>>> regular mingw (correct output)
>>>
>>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>>> $ gcc -o mtime mtime.c
>>>
>>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>>> $ ./mtime.exe
>>> retval: 0
>>> now: 1271722468
>>> now: 1271722468
>>>
>>> mingw-w64:
>>>
>>>
>>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>>> $ /c/mingw/bin/x86_64-w64-mingw32-gcc -o mtime mtime.c
>>>
>>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>>> $ ./mtime.exe
>>> retval: 0
>>> now: 1271722480
>>> now: 31293027
>>>
>>> Are there any known issues with gettimeofday() with mingw-w64?
>>>
>>> Thanks!
>>>
>>> Patrick
>>
>> what you are seeing here is that time_t type has changed for x64. x64
>> doesn't use any longer a 32-bit time_t type. I use 64-bit wide scalar
>> instead.
>> If you want to have 32-bit time_t the use please the 32
>> function set and use instead tim32_t type.
>>
>> Regards,
>> Kai
>
> I can't see the use of a time_t type anywhere in the report?
> Is there a misunderstanding somewhere?
>
> The problem may be due to strict aliasing violations.
> A warning doesn't appear with default CFLAGS, but
> after adding -Wstrict-aliasing=2, you get
>
> gettimeofday.c: In function 'getntptimeofday':
> gettimeofday.c:42: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
>
> The mingw.org version of gettimeofday.c doesn't exhibit
> such an issue. Proper use of a union as it the mingw.org
> version might be a solution.
>
> --
> Ozkan
>

Hmm, changing the FILETIME_1970 macro from 11644473600ull
to 1164447360ULL in gettimeofday.c as in the mingw.org
version seems to make the testcase output the same value.

Kai, is this correct? (see attached g3.diff.) Please verify.

--
Ozkan


g3.diff
Description: Binary data
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] issue with gettimeofday()

[Ozkan Sezer]

On Tue, Apr 20, 2010 at 2:03 PM, Kai Tietz  wrote:
> 2010/4/20 Ozkan Sezer :
>> On Tue, Apr 20, 2010 at 12:41 PM, Ozkan Sezer  wrote:
>>> On Tue, Apr 20, 2010 at 7:37 AM, Kai Tietz  wrote:
>>>> Hi Patrick,
>>>>
>>>> 2010/4/20 Patrick Galbraith :
>>>>> Hi all,
>>>>>
>>>>> I've stumbled across an issue with gettimeofday() returning an incorrect
>>>>> value with mingw-w64. A simple code sample:
>>>>>
>>>>> #include 
>>>>> #include 
>>>>>
>>>>> int main (void)
>>>>> {
>>>>>  struct timeval timer;
>>>>>  int retval;
>>>>>  retval= gettimeofday(&timer,NULL);
>>>>>  fprintf(stderr, "retval: %d\n", retval);
>>>>>  fprintf(stderr, "now: %ld\n", time(0));
>>>>>  fprintf(stderr, "now: %ld\n", timer.tv_sec);
>>>>>  return(0);
>>>>>
>>>>> }
>>>>>
>>>>> When compiled using -
>>>>>
>>>>> regular mingw (correct output)
>>>>>
>>>>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>>>>> $ gcc -o mtime mtime.c
>>>>>
>>>>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>>>>> $ ./mtime.exe
>>>>> retval: 0
>>>>> now: 1271722468
>>>>> now: 1271722468
>>>>>
>>>>> mingw-w64:
>>>>>
>>>>>
>>>>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>>>>> $ /c/mingw/bin/x86_64-w64-mingw32-gcc -o mtime mtime.c
>>>>>
>>>>> Patrick galbra...@win-7a3e68a2d98 ~/dev/stuff
>>>>> $ ./mtime.exe
>>>>> retval: 0
>>>>> now: 1271722480
>>>>> now: 31293027
>>>>>
>>>>> Are there any known issues with gettimeofday() with mingw-w64?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Patrick
>>>>
>>>> what you are seeing here is that time_t type has changed for x64. x64
>>>> doesn't use any longer a 32-bit time_t type. I use 64-bit wide scalar
>>>> instead.
>>>> If you want to have 32-bit time_t the use please the 32
>>>> function set and use instead tim32_t type.
>>>>
>>>> Regards,
>>>> Kai
>>>
>>> I can't see the use of a time_t type anywhere in the report?
>>> Is there a misunderstanding somewhere?
>>>
>>> The problem may be due to strict aliasing violations.
>>> A warning doesn't appear with default CFLAGS, but
>>> after adding -Wstrict-aliasing=2, you get
>>>
>>> gettimeofday.c: In function 'getntptimeofday':
>>> gettimeofday.c:42: warning: dereferencing type-punned pointer will
>>> break strict-aliasing rules
>>>
>>> The mingw.org version of gettimeofday.c doesn't exhibit
>>> such an issue. Proper use of a union as it the mingw.org
>>> version might be a solution.
>>>
>>> --
>>> Ozkan
>>>
>>
>> Hmm, changing the FILETIME_1970 macro from 11644473600ull
>> to 1164447360ULL in gettimeofday.c as in the mingw.org
>> version seems to make the testcase output the same value.
>>
>> Kai, is this correct? (see attached g3.diff.) Please verify.
>>
>> --
>> Ozkan
>>
>
> yeah, it is ok for apply and looks right.
>
> Thanks,
> Kai

Applied to trunk as rev. 2259, and to the v1.0 branch as rev. 2260.
Patrick, please verify that all your uses work as expected.

--
Ozkan

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] In file windef.h

[Ozkan Sezer]

On Wed, Apr 21, 2010 at 11:49 AM, 罗勇刚(Yonggang Luo)
 wrote:
> Once I compiling cmake, the 101 line of windef.h stop me to continuing.
> so recommend.
> replace #define BOOL WINBOOL
> with typedef WINBOOL BOOL;
> for make BOOL to free using in C++ namespace.
>

Please try using a newer toolchain. This issue has
recently been dealt with in our headers.

>
> --
> 此致
> 礼
> 罗勇刚
> Yours
>sincerely,
> Yonggang Luo
>

--
Ozkan

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] msvcr90 doesn't containing.

[Ozkan Sezer]

On Wed, Apr 21, 2010 at 11:38 AM, 罗勇刚(Yonggang Luo)
 wrote:
> E:/CI/Tools//phoenix/mingw32/bin\gcc.exe -mno-cygwin -shared -s
> build\temp.win32-2.6\Release\dulwich\_objects.o
> build\temp.win32-2.6\Release\dulwich\_objects.def
> -LE:\CI\tools\Python\libs -LE:\CI\tool
> s\Python\PCbuild -lpython26 -lmsvcr90 -o
> build\lib.win32-2.6\dulwich\_objects.pyd
> e:/ci/tools/phoenix/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.5.0/../../../../i686-w64-mingw32/bin/ld.exe:
> cannot find -lmsvcr90
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
>
>
> Once I using python setuptools build dulwich with
> http://code.google.com/p/mingw-w64-dgn/
> 32bit version gcc compiler.
> But it's report that error. So did mingw-w64 accompany with msvcr90 or
> dgn-mingw-w64 lost it?

At present, mingw-w64 doesn't have a libmsvcr90.a
link library. If you need/want that feature, please open an
entry in our "Feature requests" tracker.

> --
> 此致
> 礼
> 罗勇刚
> Yours
>sincerely,
> Yonggang Luo

--
Ozkan

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Custom toolchain build with gcc-4.4.4 (2010-04-28)

[Ozkan Sezer]

To anyone who might be interested: I updated my custom w32/w64 native
and cross-compiler build with gcc-4.4 with several backports and fixes
from mainstream and put them under the mingw-w64 sf.net file release
system under the subdirectories:
-  Toolchain sources -> Personal Builds,
-  Toolchains targetting Win32 -> Personal Builds  and
-  Toolchains targetting Win64 -> Personal Builds

Changes since the previous 2010-04-10/2010-04-27 build:
- The mingw-w64 crt and headers updated to r2266 which contains an x64
  compatibility fix among other things.
- Gcc updated to the 4.4.4 prerelease version, svn rev. 158621. (After
  just about an hour I uploaded the files, the same gcc snapshot was
  marked as 4.4.4-release at rev. 158895 ;)
- All other software has been updated to the latest available versions
  as of 2010-04-28, 17:10 GMT.

- Compatibility Notice:  ** No leading underscore **

Unlike the other builds from mingw-w64 up to 2010-04-27, these new win64
targetting toolchains do *not* prepend an undersocore to the symbols and
follows the MSVC x64 convention.  Therefore, any of the link libraries
from previous toolchains are incompatible with the ones created by these
new builds.

- Note: the /include path "problem" of the native builds is
  not looked into, yet. Maybe in the future builds.


Versions:
-

Common in both cross- and native-toolchains:

gcc : svn rev. 158621 (4.4.4 prerelease with many patches)
binutils : 2.20.51 (cvs, 2010-04-28 17:10 GMT)
mingw-w64-crt : svn revision 2263 (2010-04-21)
mingw-w64-headers : svn revision 2266 (2010-04-28), with a
 couple of patches.
glext headers: 2010-03-17 (from the Khronos Group)
pthreads-win32: 2.9.0 (cvs, 2010-02-28 20:00 GMT)
 with w64 patch applied.

In native-toolchains only:

gmp : 4.3.2 (with w64 patch applied)
mpfr: 2.4.2-p3
mpc : 0.8.1
gdb : 7.1.50 (cvs, 2010-04-28 17:10 GMT, with
 minor w64 patches applied.)
make: 3.81.90 (cvs, 2010-02-02 15:20 GMT, with
 w64 patches applied according to savannah bug
 items 27809 and 27825, and patched further to
 kill a horde of compiler warnings)
gendef, libmangle: from mingw-w64 svn/trunk


File names:
---

* Source:

- mingw-w64-src_20100428_sezero.tar.gz


* Targetting Win64:

- mingw-w64-bin_x86_64-mingw_20100428_sezero.zip
  native compiler toolchain for running on x64-windows
  host and creating x64-windows binaries.

- mingw-w64-bin_i686-mingw_20100428_sezero.zip
  cross compiler toolchain for running on x86-windows
  host but creating x64-windows binaries.

- mingw-w64-bin_i686-linux_20100428_sezero.tar.gz
  cross compiler toolchain for running on a i686-linux
  host and creating x64-windows binaries.

- mingw-w64-bin_x86_64-linux_20100428_sezero.tar.gz
  cross compiler toolchain for running on a x86_64-linux
  host and creating x64-windows binaries.


* Targetting Win32:

- mingw-w32-bin_i686-mingw_20100428_sezero.zip
  native compiler toolchain for running on x86-windows
  host and creating x86-windows binaries.

- mingw-w32-bin_i686-linux_20100428_sezero.tar.gz
  cross compiler toolchain for running on a i686-linux
  host and creating x86-windows binaries.

- mingw-w32-bin_x86_64-linux_20100428_sezero.tar.gz
  cross compiler toolchain for running on a x86_64-linux
  host and creating x86-windows binaries.

--
Ozkan

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.4 (2010-04-28)

[Ozkan Sezer]

On Thu, Apr 29, 2010 at 1:49 PM, John Marriott
 wrote:
> Hi Ozkan,
>
> Thanks for the update.
>
> A question if I may: do you have any plans for moving to the gcc 4.5
> release?
>

Probably, although I think it would be best to wait for 4.5.1 release
to have the 4.5-series fairly stabilized.  (Don't know when it will be
out, though, around june? july?)

--
Ozkan


> On 29-Apr-2010 20:24, Ozkan Sezer wrote:
>>
>> To anyone who might be interested: I updated my custom w32/w64 native
>> and cross-compiler build with gcc-4.4 with several backports and fixes
>> from mainstream and put them under the mingw-w64 sf.net file release
>> system under the subdirectories:
>> -  Toolchain sources ->  Personal Builds,
>> -  Toolchains targetting Win32 ->  Personal Builds  and
>> -  Toolchains targetting Win64 ->  Personal Builds
>>
>> Changes since the previous 2010-04-10/2010-04-27 build:
>> - The mingw-w64 crt and headers updated to r2266 which contains an x64
>>   compatibility fix among other things.
>> - Gcc updated to the 4.4.4 prerelease version, svn rev. 158621. (After
>>   just about an hour I uploaded the files, the same gcc snapshot was
>>   marked as 4.4.4-release at rev. 158895 ;)
>> - All other software has been updated to the latest available versions
>>   as of 2010-04-28, 17:10 GMT.
>>
>> - Compatibility Notice:  ** No leading underscore **
>> 
>> Unlike the other builds from mingw-w64 up to 2010-04-27, these new win64
>> targetting toolchains do *not* prepend an undersocore to the symbols and
>> follows the MSVC x64 convention.  Therefore, any of the link libraries
>> from previous toolchains are incompatible with the ones created by these
>> new builds.
>>
>> - Note: the/include path "problem" of the native builds is
>>   not looked into, yet. Maybe in the future builds.
>>
>>
>> Versions:
>> -
>>
>> Common in both cross- and native-toolchains:
>>
>> gcc : svn rev. 158621 (4.4.4 prerelease with many patches)
>> binutils : 2.20.51 (cvs, 2010-04-28 17:10 GMT)
>> mingw-w64-crt : svn revision 2263 (2010-04-21)
>> mingw-w64-headers : svn revision 2266 (2010-04-28), with a
>>  couple of patches.
>> glext headers: 2010-03-17 (from the Khronos Group)
>> pthreads-win32: 2.9.0 (cvs, 2010-02-28 20:00 GMT)
>>  with w64 patch applied.
>>
>> In native-toolchains only:
>>
>> gmp : 4.3.2 (with w64 patch applied)
>> mpfr: 2.4.2-p3
>> mpc : 0.8.1
>> gdb : 7.1.50 (cvs, 2010-04-28 17:10 GMT, with
>>  minor w64 patches applied.)
>> make: 3.81.90 (cvs, 2010-02-02 15:20 GMT, with
>>  w64 patches applied according to savannah bug
>>  items 27809 and 27825, and patched further to
>>  kill a horde of compiler warnings)
>> gendef, libmangle: from mingw-w64 svn/trunk
>>
>>
>> File names:
>> ---
>>
>> * Source:
>>
>> - mingw-w64-src_20100428_sezero.tar.gz
>>
>>
>> * Targetting Win64:
>>
>> - mingw-w64-bin_x86_64-mingw_20100428_sezero.zip
>>   native compiler toolchain for running on x64-windows
>>   host and creating x64-windows binaries.
>>
>> - mingw-w64-bin_i686-mingw_20100428_sezero.zip
>>   cross compiler toolchain for running on x86-windows
>>   host but creating x64-windows binaries.
>>
>> - mingw-w64-bin_i686-linux_20100428_sezero.tar.gz
>>   cross compiler toolchain for running on a i686-linux
>>   host and creating x64-windows binaries.
>>
>> - mingw-w64-bin_x86_64-linux_20100428_sezero.tar.gz
>>   cross compiler toolchain for running on a x86_64-linux
>>   host and creating x64-windows binaries.
>>
>>
>> * Targetting Win32:
>>
>> - mingw-w32-bin_i686-mingw_20100428_sezero.zip
>>   native compiler toolchain for running on x86-windows
>>   host and creating x86-windows binaries.
>>
>> - mingw-w32-bin_i686-linux_20100428_sezero.tar.gz
>>   cross compiler toolchain for running on a i686-linux
>>   host and creating x86-windows binaries.
>>
>> - mingw-w32-bin_x86_64-linux_20100428_sezero.tar.gz
>>   cross compiler toolchain for running on a x86_64-linux
>>   host and creating x86-windows binaries.
>>
>> --
>> Ozkan
>>
>>
>> --
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Sezeros gdb builds - python support

[Ozkan Sezer]

On Fri, Apr 30, 2010 at 11:12 PM, NightStrike  wrote:
> On Mon, Feb 15, 2010 at 9:57 PM, Jarrod Chesney
>  wrote:
>> Hi All
>>        When using the gdb provided with sezeros mingw builds gdb does not 
>> seem to support python.
>> I would like it to so that i can "pretty print" stl containers.
>>
>> I tested it like this
>> run gdb
>> execute the three lines
>>
>> python
>> print "hello"
>> end
>>
>> Python scripting is not supported in this copy of GDB.
>>
>> It would be great if this was supported.
>
> Is this still the case?  If so, we have a guy here that builds gdb for us.

Well, it should still be, because I still don't build gdb with python support ;)
(Python may be a pain to gather its all dependencies, so I leave it out it my
toolchain builds.)

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinGW-w64 and DDK headers

[Ozkan Sezer]

On Mon, May 3, 2010 at 12:11 PM, Kyle Stewart  wrote:
> I would like to use MinGW-w64 as my one stop shopping toolchain for
> targeting the Windows platform including driver development, but I have run
> into a snag. I have downloaded the latest personal builds for both x86 and
> x64 targets. I am running a x64 Windows 7 host and I have successfully used
> the 32 bit target toolchain to build Qt 4.6. My next step was to get a
> simple hello world driver working. All the driver does is provide a
> DriverEntry and DriverUnload function with some debug statements to let me
> know things are working. I have been able to build the driver using the
> default MinGW bundle since they package the DDK along with the regular
> install with some tips found here:
>
> http://strdup.livejournal.com/34596.html
>
> So I know the code is okay. I have checked out the current mingw-w64 code
> out of the SVN and found the DDK headers. I copied the DDK folder over to
> where my local MinGW-w64 installations. It seems as thought things are
> incomplete, however. After placing the appropriate search paths for the new
> headers in the gcc compile command I get a large screenful of errors. Here
> is the first few lines:
>
> In file included from
> M:\Development\mingw\mingw32_win64\i686-w64-mingw32\include\ddk/ntddk.h:40,
>  from driver.c:1:
> M:\Development\mingw\mingw32_win64\i686-w64-mingw32\include\ddk/wdm.h:39:19:
> error: ntdef.h: No such file or directory
> M:\Development\mingw\mingw32_win64\i686-w64-mingw32\include\ddk/wdm.h:41:22:
> error: ntiologc.h: No such file or directory
> M:\Development\mingw\mingw32_win64\i686-w64-mingw32\include\ddk/wdm.h:62:22:
> error: dpfilter.h: No such file or directory
>
> So it can find ntddk.h but not the some of the header dependencies of
> ntddk.h. The headers mentioned in the error messages don't seem to be
> anywhere to be found in the MinGW-w64 SVN checkout, but they do exist in the
> MinGW headers. Am I missing something? Is it safe to simply copy the DDK
> folder from the MinGW bundle over to MinGW-w64 folder? Any help would be
> appreciated.
>
> Regards,
>
> Kyle

The DDK headers were not installed by default in the toolchain (I
will remember to install them bydefault in future builds.) In the
interim, just download the ddk headers from svn, here:
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/branches/releases/v1.0/mingw-w64-headers/ddk/

--
Ozkan

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] pthreads

[Ozkan Sezer]

On Tue, May 4, 2010 at 9:44 AM, Dmitrijs Ledkovs
 wrote:
> the patch link from documentation doesn't apply from me.
>
> neither against tarball nor against cvs please help.

Is the patch from here?
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/patches/pthreads_win32/

That one applies to the CVS version of pthreads perfectly.
Otherwise, if you are running on windows, you might have
hit some dos line endigns issue??

>
> shared binutils built successfully

--
Ozkan

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] pthreads

[Ozkan Sezer]

On Tue, May 4, 2010 at 10:53 AM, Dmitrijs Ledkovs
 wrote:
> On 4 May 2010 07:51, Ozkan Sezer  wrote:
>> On Tue, May 4, 2010 at 9:44 AM, Dmitrijs Ledkovs
>>  wrote:
>>> the patch link from documentation doesn't apply from me.
>>>
>>> neither against tarball nor against cvs please help.
>>
>> Is the patch from here?
>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/patches/pthreads_win32/
>>
>> That one applies to the CVS version of pthreads perfectly.
>> Otherwise, if you are running on windows, you might have
>> hit some dos line endigns issue??
>>
>
> Ok =) let me state what I need better =)
>
> I want two more patches ontop of that one:
>
> how it looks after the sed magic has been applied to make it's
> GNUMakefile ready for building i686 and second one for x86_64
>
> So when I'm building for i686 i would apply that one from the link &
> i686_prep.patch;
> When building for x86_64 patch from the link above and & x86_64_prep.patch
>
> I'm having troubles with running the makebuildroot-test.mk to create
> those for me.
>

I don't have experience with that buildbot makefile, however I can
not find any reference to a i686_prep.patch or x86_64_prep.patch in
it, either.  If your problem is that a second sed magic (such as for
prep'ing it for x86_64) not working on the GNUmakefile once a first
one (such as for prep'ing for i686) is applied, you should always
work on a backup copy of the original GNUmakefile the one resulting
from the applying of w64sup.patch.

My own scripts has something like:

cvs -z9 -d:pserver:anon...@sourceware.org:/cvs/pthreads-win32 co pthreads
cd pthreads
patch -p1 < ../pthreads-w64sup.patch
cp -p config.h pthreads_win32_config.h
cp -p pthread.h pthread.h.bak
sed -e 's/HAVE_CONFIG_H/1/' \
-e 's/config.h/pthreads_win32_config.h/' \
< pthread.h.bak >pthread.h
cp -p GNUmakefile GNUmakefile.bak

The resulting source tree at this point is my reference.

Then, for x86_64-w64-mingw32 I do:

sed -e 's/dlltool$/& -m i386:x86-64/' \
-e 's/gcc$/& -m64/' \
-e 's/g++$/& -m64/' \
-e 's/windres$/& -F pe-x86-64/' \
-e 's/pthreadGC\$(DLL_VER)/&-w64/g' \
-e 's/pthreadGCE\$(DLL_VER)/&-w64/g' \
< GNUmakefile.bak > GNUmakefile
make CROSS="x86_64-w64-mingw32-" clean GC

... and then for i686-w64-mingw32, I do:

sed -e 's/dlltool$/& -m i386/' \
-e 's/gcc$/& -m32/' \
-e 's/g++$/& -m32/' \
-e 's/windres$/& -F pe-i386/' \
-e 's/pthreadGC\$(DLL_VER)/&-w32/g' \
-e 's/pthreadGCE\$(DLL_VER)/&-w32/g' \
< GNUmakefile.bak > GNUmakefile
make CROSS="i686-w64-mingw32-" clean GC

As you see, I always do the sed magic on the backup GNUmakefile.bak
and output a new GNUmakefile for every new target.

Hope these help.

--
Ozkan

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Build problem using a cross compiler to build a w64 native library

[Ozkan Sezer]

On Tue, May 4, 2010 at 4:00 PM, t66...@gmail.com  wrote:
> Hello:
> Currently I am using the mingw-w64 SVN to build recently released GCC
> 4.5 4.4 series.
> Anyone have have problem with gcc-4.4.4 and 4.5.0 cross compiler with
> mingw-w64 trunk CRT and W32API running on Linux ?
>
> I use these cross compiler, but it fails at configure mpfr 2.4.2
> --host=x86_64-w64-mingw32...
>
> Initially I thought it was 4.5.0-release then I retried again with
> 4.4.4-release cross compilers ... still no go.
> And then I thought it could be problem with binutils CVS... so retried
> again by only rebuild binutils to binutils-2.20.1 release and install it
> to the cross compiler.
> Still no go...
>
> mpfr-2.4.2':
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
>
> I looked in to the config.log and saw lots of undefined references...
> lib/gcc/x86_64-w64-mingw32/4.4.4/../../../../x86_64-w64-mingw32/lib/../lib64/crt2.o:crtexe.c:(.text+0x49):
> undefined reference to `___getmainargs'
> ...
> ...
> ...
> lib/gcc/x86_64-w64-mingw32/4.4.4/../../../../x86_64-w64-mingw32/lib/../lib64/libmingw32.a(lib64_libmingw32_a-pesect.o):pesect.c:(.text+0x291):
> undefined reference to `_strncmp'
> collect2: ld returned 1 exit status
> configure:4193: $? = 1
> configure:4230: result:
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "MPFR"
> | #define PACKAGE_TARNAME "mpfr"
> | #define PACKAGE_VERSION "2.4.2"
> | #define PACKAGE_STRING "MPFR 2.4.2"
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | /* end confdefs.h.  */
> | #include 
> | int
> | main ()
> | {
> | FILE *f = fopen ("conftest.out", "w");
> |  return ferror (f) || fclose (f) != 0;
> |
> |   ;
> |   return 0;
> | }
>
> t66...

You built a cross-binutils-2.20.1 but kept the rest as the same
yes? I think that's why it fails. Binutils-cvs has the undrerscoring
changes but release versions of gcc-4.4.4 and gcc-4.5.0 do
not. You should rebuild your toolchain from the start, I guess.

--
Ozkan

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] pthreads

[Ozkan Sezer]

> By why does this not fail when building native linux compiler? I'm
> using same patched source as used by the distribution in that field.
> By inspected the said function I fail to see what's wrong with it. Can
> you explain what's wrong with:
>
>   static char name [UNLEN + 1];
>   DWORD namelen = sizeof (name);

use DWORD_PTR here. (DWORD is strictly 32 bits, DWORD_PTR
is pointer sized.)

>   GetUserName (name, &namelen);
>
> http://repo.or.cz/w/official-gcc.git/blob/gcc-4_4-branch:/libgfortran/intrinsics/getlog.c
>
> Does this code implies that sizeof(char) is the pointer size? if yes I
> guess I should file a bug in launchpad.

--
Ozkan

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] pthreads

[Ozkan Sezer]

On Tue, May 4, 2010 at 4:27 PM, Ozkan Sezer  wrote:
>> By why does this not fail when building native linux compiler? I'm
>> using same patched source as used by the distribution in that field.
>> By inspected the said function I fail to see what's wrong with it. Can
>> you explain what's wrong with:
>>
>>   static char name [UNLEN + 1];
>>   DWORD namelen = sizeof (name);
>
> use DWORD_PTR here. (DWORD is strictly 32 bits, DWORD_PTR
> is pointer sized.)
>
>>   GetUserName (name, &namelen);

OK, sorry, ignore what I said (wasn't thinking carefully., GetUserName()
does get a DWORD* second arg,)

--
Ozkan

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public