[Mingw-w64-public] About pthread-w32 patch

[Dongsheng Song]

Hi,

Due to recent update of pthread-w32, the patch:



can not apply cleanly, have some conflicts now, is there have any update
patch ?

Regards,
Dongsheng
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] About pthread-w32 patch

[Dongsheng Song]

On Thu, Jul 8, 2010 at 23:04, Dongsheng Song wrote:

> Hi,
>
> Due to recent update of pthread-w32, the patch:
>
> <http://sourceware.org/ml/pthreads-win32/2009/msg00030/w64sup.patch>
>
> can not apply cleanly, have some conflicts now, is there have any update
> patch ?
>
> Regards,
> Dongsheng
>
>
Without patch, x86_64-w64-mingw32-gcc build pthreads got lots of warning:

$ make clean GC CROSS=x86_64-w64-mingw32-
rm -f *~
rm -f *.i
rm -f *.o
rm -f *.obj
rm -f *.exe
rm -f pthread.def
make CLEANUP=-D__CLEANUP_C XC_FLAGS=" " OBJ="attr.o barrier.o cancel.o
cleanup.o condvar.o create.o dll.o errno.o exit.o fork.o global.o misc.o
mutex.o nonportable.o private.o rwlock.o sched.o semaphore.o signal.o spin.o
sync.o tsd.o version.o" pthreadGC2.dll
make[1]: Entering directory `/home/oracle/vcs/cvs/pthreads-win32'
x86_64-w64-mingw32-gcc -c -o attr.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  attr.c
x86_64-w64-mingw32-gcc -c -o barrier.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  barrier.c
x86_64-w64-mingw32-gcc -c -o cancel.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  cancel.c
In file included from cancel.c:44:0:
pthread_cancel.c: In function 'pthread_cancel':
pthread_cancel.c:160:8: warning: passing argument 1 of
'ptw32_register_cancelation' from incompatible pointer type
pthread_cancel.c:160:8: note: expected 'PAPCFUNC' but argument is of type
'void (*)(DWORD)'
x86_64-w64-mingw32-gcc -c -o cleanup.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  cleanup.c
x86_64-w64-mingw32-gcc -c -o condvar.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  condvar.c
x86_64-w64-mingw32-gcc -c -o create.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  create.c
x86_64-w64-mingw32-gcc -c -o dll.o -D__CLEANUP_C -O3 -finline-functions  -I.
-DHAVE_CONFIG_H -Wall  dll.c
x86_64-w64-mingw32-gcc -c -o errno.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  errno.c
x86_64-w64-mingw32-gcc -c -o exit.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  exit.c
In file included from exit.c:44:0:
pthread_exit.c: In function 'pthread_exit':
pthread_exit.c:92:21: warning: cast from pointer to integer of different
size
x86_64-w64-mingw32-gcc -c -o fork.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  fork.c
x86_64-w64-mingw32-gcc -c -o global.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  global.c
x86_64-w64-mingw32-gcc -c -o misc.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  misc.c
x86_64-w64-mingw32-gcc -c -o mutex.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  mutex.c
x86_64-w64-mingw32-gcc -c -o nonportable.o -D__CLEANUP_C -O3
-finline-functions  -I. -DHAVE_CONFIG_H -Wall  nonportable.c
In file included from nonportable.c:46:0:
pthread_timechange_handler_np.c: In function
'pthread_timechange_handler_np':
pthread_timechange_handler_np.c:106:10: warning: cast to pointer from
integer of different size
x86_64-w64-mingw32-gcc -c -o private.o -D__CLEANUP_C -O3 -finline-functions
-I. -DHAVE_CONFIG_H -Wall  private.c
In file included from private.c:44:0:
ptw32_MCS_lock.c: In function 'ptw32_mcs_flag_set':
ptw32_MCS_lock.c:104:14: warning: cast to pointer from integer of different
size
ptw32_MCS_lock.c: In function 'ptw32_mcs_flag_wait':
ptw32_MCS_lock.c:132:22: warning: cast from pointer to integer of different
size
ptw32_MCS_lock.c: In function 'ptw32_mcs_lock_acquire':
ptw32_MCS_lock.c:163:21: warning: cast from pointer to integer of different
size
ptw32_MCS_lock.c:162:10: warning: cast to pointer from integer of different
size
ptw32_MCS_lock.c: In function 'ptw32_mcs_lock_release':
ptw32_MCS_lock.c:186:34: warning: cast to pointer from integer of different
size
ptw32_MCS_lock.c:197:11: warning: cast from pointer to integer of different
size
ptw32_MCS_lock.c:194:19: warning: cast to pointer from integer of different
size
ptw32_MCS_lock.c:205:14: warning: cast to pointer from integer of different
size
ptw32_MCS_lock.c: In function 'ptw32_mcs_lock_try_acquire':
ptw32_MCS_lock.c:226:39: warning: cast from pointer to integer of different
size
ptw32_MCS_lock.c:224:11: warning: cast to pointer from integer of different
size
ptw32_MCS_lock.c: In function 'ptw32_mcs_node_substitute':
ptw32_MCS_lock.c:251:68: warning: cast from pointer to integer of different
size
ptw32_MCS_lock.c:252:68: warning: cast from pointer to integer of different
size
ptw32_MCS_lock.c:250:7: warning: cast to pointer from integer of different
size
In file included from private.c:48:0:
ptw32_threadStart.c: In function 'ptw32_threadStart':
ptw32_threadStart.c:347:17: warning: cast from pointer to integer of
different size
ptw32_threadStart.c:357:10: warning: cast from pointer to

[Mingw-w64-public] Why decimal floating point not supported for this target ?

[Dongsheng Song]

Hi,

When I compile the following simple C program:

int main()
{
  _Decimal32 d1;
  _Decimal64 d2;
  _Decimal128 d3;

  return 0;
}

gcc 4.4 linux target is OK, but mingw32 or mingw64 target failed:

C:\var\tmp\mingw32\bin>gcc testDecimal.c
testDecimal.c: In function 'main':
testDecimal.c:3: error: decimal floating point not supported for this target
testDecimal.c:4: error: decimal floating point not supported for this target
testDecimal.c:5: error: decimal floating point not supported for this target

C:\var\tmp\mingw64\bin>x86_64-w64-mingw32-gcc testDecimal.c
testDecimal.c: In function 'main':
testDecimal.c:3: error: decimal floating point not supported for this target
testDecimal.c:4: error: decimal floating point not supported for this target
testDecimal.c:5: error: decimal floating point not supported for this target

But I can found libdecnumber is compiled when build gcc !

gcc/libdecnumber/decimal128.o
gcc/libdecnumber/decimal32.o
gcc/libdecnumber/decimal64.o

sezero's gcc build give same errors too.

Thanks for some help,
Dongsheng Song
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Why decimal floating point not supported for this target ?

[Dongsheng Song]

On Fri, Jul 16, 2010 at 13:17, Kai Tietz  wrote:

> The feature of decimal-floating-point isn't enabled in gcc for
> cygwin/mingw targets. Question for those targets are, which
> decimal-floating-point variant should be used, is there any support by
> runtime, which ISO-Spec it the Decimal128 type in #c following? etc.
> As long as those points aren't clarified I don't want to enable this
> feature for win32.
>
> Regards,
> Kai
>

Thanks.

>From gcc\gcc\configure.ac, I see decimal float only enabled on
targets: powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux*

Can I enable decimal float support by simple add

i?86*-*-mingw* | x86_64*-*-mingw*

to the targets list ?

I found gcc implement decimal64 and decimal128 by decNumber, not
by decDouble and decQuad. But in the decNumber performance page:

http://speleotrove.com/decimal/dnperf.html

I see decDouble and decQuad much fast than decNumber, is there any
realization of consideration ?

Regards,
Dongsheng
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Kai Tietz break build on r2962 due to missing commit pow.def.h

[Dongsheng Song]

Here is the commit information:

2010-07-25  Kai Tietz  

* math/pow.c: Replaced by new implementation.
* math/powl.c: Likewise.
* math/pow.def.h: New pow implementation as template.



---
M : /trunk/mingw-w64-crt/ChangeLog
M : /trunk/mingw-w64-crt/math/pow.c
M : /trunk/mingw-w64-crt/math/powl.c
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Jonathan break build on r2963 due to typo in Makefile.am

[Dongsheng Song]

Hi Jonathan,

Here is the patch:

Index: Makefile.in
===
--- Makefile.in(revision 2968)
+++ Makefile.in(working copy)
@@ -3697,7 +3697,7 @@
 @LIB64_TRUE@  lib64/libks.a lib64/librpcdiag.a
lib64/librpchttp.a lib64/libresutil.a lib64/libslwga.a \
 @LIB64_TRUE@  lib64/libslc.alib64/libslcext.a
lib64/libvsstrace.alib64/libmsctfmonitor.a lib64/libtbs.a  \
 @LIB64_TRUE@  lib64/libtdh.alib64/libtxfw32.a
lib64/libwlanui.a  lib64/libwlanapi.a lib64/libwlanutil.a  \
-...@lib64_true@  lib64/libwer.alib64/libndis.a
lib64/libd2d1.alib64/libwdscsl.deflib64/libpcwum.def   \
+...@lib64_true@  lib64/libwer.alib64/libndis.a
lib64/libd2d1.alib64/libwdscsl.a  lib64/libpcwum.a \
 @LIB64_TRUE@  lib64/libwdscore.alib64/libcryptsp.a
lib64/libwdsclient.a   lib64/libwdsupgcompl.a lib64/libwdsclientapi.a  \
 @LIB64_TRUE@  lib64/libwdsutil.alib64/libmsvcr90.a
lib64/libmsvcr100.alib64/libmsvcr90d.alib64/libwdsimage.a

Index: Makefile.am
===
--- Makefile.am(revision 2968)
+++ Makefile.am(working copy)
@@ -969,7 +969,7 @@
   lib64/libks.a lib64/librpcdiag.alib64/librpchttp.a
lib64/libresutil.a lib64/libslwga.a \
   lib64/libslc.alib64/libslcext.a lib64/libvsstrace.a
lib64/libmsctfmonitor.a lib64/libtbs.a  \
   lib64/libtdh.alib64/libtxfw32.a lib64/libwlanui.a
lib64/libwlanapi.a lib64/libwlanutil.a  \
-  lib64/libwer.alib64/libndis.a   lib64/libd2d1.a
lib64/libwdscsl.deflib64/libpcwum.def   \
+  lib64/libwer.alib64/libndis.a   lib64/libd2d1.a
lib64/libwdscsl.a  lib64/libpcwum.a \
   lib64/libwdscore.alib64/libcryptsp.alib64/libwdsclient.a
lib64/libwdsupgcompl.a lib64/libwdsclientapi.a  \
   lib64/libwdsutil.alib64/libmsvcr90.alib64/libmsvcr100.a
lib64/libmsvcr90d.alib64/libwdsimage.a
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

[Dongsheng Song]

Hi Kai,

When we cross build gcc 4.5 for windows, I found we can build windows gcc 
binary one
week ago, but now the build failed.

After I do a binary search, I found the issue caused by r2945.

r2950 | 2010-07-24 05:50:28 | FAILED
r2945 | 2010-07-24 02:44:15 | FAILED
r2944 | 2010-07-24 02:38:30 | SUCCESS
r2939 | 2010-07-23 17:55:30 | SUCCESS
r2928 | 2010-07-23 05:21:20 | SUCCESS
r2924 | 2010-07-22 18:32:25 | SUCCESS

r2945 remove some *IMPORTANT* macros from /trunk/mingw-w64-headers/crt/float.h,
e.g. FLT/DBL/LDBL_MANT_DIG, FLT_EVAL_METHOD, *ALL* decimal macros 
(DEC32/64/128_*, ...)

When I add FLT/DBL/LDBL_MANT_DIG and FLT_EVAL_METHOD back to 
/trunk/mingw-w64-headers/crt/float.h,
then the gcc cross build success again.

So I recommend you apply the attached patch at least.

btw, I know FLT_EVAL_METHOD added by C99, but libgfortran/m4/nearest.m4 use it,
is it mean we should use ISO C99 compiler to build gcc 4.5 or later, not ISO 
C90 as
http://gcc.gnu.org/install/prerequisites.html ?

Regards,
Dongsheng
Index: mingw-w64-headers/crt/float.h
===
--- mingw-w64-headers/crt/float.h   (revision 2984)
+++ mingw-w64-headers/crt/float.h   (working copy)
@@ -31,6 +31,33 @@
 #define_MCW_RC 0x0300  /* Rounding */
 #define_MCW_PC 0x0003  /* Precision */
 
+/* Number of base-FLT_RADIX digits in the significand, p.  */
+#undef FLT_MANT_DIG
+#undef DBL_MANT_DIG
+#undef LDBL_MANT_DIG
+#define FLT_MANT_DIG   __FLT_MANT_DIG__
+#define DBL_MANT_DIG   __DBL_MANT_DIG__
+#define LDBL_MANT_DIG  __LDBL_MANT_DIG__
+
+#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
+/* The floating-point expression evaluation method.
+-1  indeterminate
+ 0  evaluate all operations and constants just to the range and
+precision of the type
+ 1  evaluate operations and constants of type float and double
+to the range and precision of the double type, evaluate
+long double operations and constants to the range and
+precision of the long double type
+ 2  evaluate all operations and constants to the range and
+precision of the long double type
+
+   ??? This ought to change with the setting of the fp control word;
+   the value provided by the compiler assumes the widest setting.  */
+#undef FLT_EVAL_METHOD
+#define FLT_EVAL_METHOD__FLT_EVAL_METHOD__
+
+#endif /* C99 */
+
 /* Control word values for unNew (use with related unMask above) */
 #define_DN_SAVE0x
 #define_DN_FLUSH   0x0100


signature.asc
Description: OpenPGP digital signature
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

[Dongsheng Song]

于 2010-7-28 15:43, Kai Tietz 写道:
> 2010/7/28 Dongsheng Song :
>> Hi Kai,
>>
>> When we cross build gcc 4.5 for windows, I found we can build windows gcc 
>> binary one
>> week ago, but now the build failed.
>>
>> After I do a binary search, I found the issue caused by r2945.
>>
>>r2950 | 2010-07-24 05:50:28 | FAILED
>>r2945 | 2010-07-24 02:44:15 | FAILED
>>r2944 | 2010-07-24 02:38:30 | SUCCESS
>>r2939 | 2010-07-23 17:55:30 | SUCCESS
>>r2928 | 2010-07-23 05:21:20 | SUCCESS
>>r2924 | 2010-07-22 18:32:25 | SUCCESS
>>
>> r2945 remove some *IMPORTANT* macros from 
>> /trunk/mingw-w64-headers/crt/float.h,
>> e.g. FLT/DBL/LDBL_MANT_DIG, FLT_EVAL_METHOD, *ALL* decimal macros 
>> (DEC32/64/128_*, ...)
>>
>> When I add FLT/DBL/LDBL_MANT_DIG and FLT_EVAL_METHOD back to 
>> /trunk/mingw-w64-headers/crt/float.h,
>> then the gcc cross build success again.
>>
>> So I recommend you apply the attached patch at least.
>>
>> btw, I know FLT_EVAL_METHOD added by C99, but libgfortran/m4/nearest.m4 use 
>> it,
>> is it mean we should use ISO C99 compiler to build gcc 4.5 or later, not ISO 
>> C90 as
>> http://gcc.gnu.org/install/prerequisites.html ?
>>
>> Regards,
>> Dongsheng
> 
> Hello Dongsheng,
> 
> the recent change to float.h was necessary to support the new
> include_next patch of 4.6. So how are you exactly installing headers?
> As usual you should just see gcc's internal float.h for older gcc's
> then 4.6. So I am a bit puzzled. Are you removing gcc's float.h here?
> 
> Regards,
> Kai
> 

Hi Kai,

I use Debian 6.0 i686 with latest update, gcc 4.4.4 build a gcc 4.5 cross 
compiler for windows,
then use the cross compiler to build a native gcc 4.5 compiler for windows.

Without the patch, both i686-windows and x64-windows failed during build native
compiler.

It's strange since I can build cross compiler, it maybe a gcc bug.

The related packages is:
gcc 4.5 branch, mingw64 trunk, binutils trunk, gmp 5.0 branch, mpfr 3.0 branch,
mpc 0.8.2, ppl 0.10.2, cloog-ppl 0.15.9.

Regards,
Dongsheng



signature.asc
Description: OpenPGP digital signature
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

[Dongsheng Song]

于 2010-7-28 16:02, Kai Tietz 写道:
> 2010/7/28 Dongsheng Song :
>> 于 2010-7-28 15:43, Kai Tietz 写道:
>>> 2010/7/28 Dongsheng Song :
>>>> Hi Kai,
>>>>
>>>> When we cross build gcc 4.5 for windows, I found we can build windows gcc 
>>>> binary one
>>>> week ago, but now the build failed.
>>>>
>>>> After I do a binary search, I found the issue caused by r2945.
>>>>
>>>>r2950 | 2010-07-24 05:50:28 | FAILED
>>>>r2945 | 2010-07-24 02:44:15 | FAILED
>>>>r2944 | 2010-07-24 02:38:30 | SUCCESS
>>>>r2939 | 2010-07-23 17:55:30 | SUCCESS
>>>>r2928 | 2010-07-23 05:21:20 | SUCCESS
>>>>r2924 | 2010-07-22 18:32:25 | SUCCESS
>>>>
>>>> r2945 remove some *IMPORTANT* macros from 
>>>> /trunk/mingw-w64-headers/crt/float.h,
>>>> e.g. FLT/DBL/LDBL_MANT_DIG, FLT_EVAL_METHOD, *ALL* decimal macros 
>>>> (DEC32/64/128_*, ...)
>>>>
>>>> When I add FLT/DBL/LDBL_MANT_DIG and FLT_EVAL_METHOD back to 
>>>> /trunk/mingw-w64-headers/crt/float.h,
>>>> then the gcc cross build success again.
>>>>
>>>> So I recommend you apply the attached patch at least.
>>>>
>>>> btw, I know FLT_EVAL_METHOD added by C99, but libgfortran/m4/nearest.m4 
>>>> use it,
>>>> is it mean we should use ISO C99 compiler to build gcc 4.5 or later, not 
>>>> ISO C90 as
>>>> http://gcc.gnu.org/install/prerequisites.html ?
>>>>
>>>> Regards,
>>>> Dongsheng
>>>
>>> Hello Dongsheng,
>>>
>>> the recent change to float.h was necessary to support the new
>>> include_next patch of 4.6. So how are you exactly installing headers?
>>> As usual you should just see gcc's internal float.h for older gcc's
>>> then 4.6. So I am a bit puzzled. Are you removing gcc's float.h here?
>>>
>>> Regards,
>>> Kai
>>>
>>
>> Hi Kai,
>>
>> I use Debian 6.0 i686 with latest update, gcc 4.4.4 build a gcc 4.5 cross 
>> compiler for windows,
>> then use the cross compiler to build a native gcc 4.5 compiler for windows.
>>
>> Without the patch, both i686-windows and x64-windows failed during build 
>> native
>> compiler.
>>
>> It's strange since I can build cross compiler, it maybe a gcc bug.
>>
>> The related packages is:
>> gcc 4.5 branch, mingw64 trunk, binutils trunk, gmp 5.0 branch, mpfr 3.0 
>> branch,
>> mpc 0.8.2, ppl 0.10.2, cloog-ppl 0.15.9.
>>
>> Regards,
>> Dongsheng
>>
>>
> 
> Well, yes it is a gcc bug in respect to native/cross toolchains. I
> assume that your search path installs headers (and libraries) in
> standard_include for native. This cause that the system-headers get
> included before fixed-include and gcc-include.
> For this I can provide a patch. See revision 2986. But indeed this
> include-order of gcc is a conceptional flaw.
> 
> Cheers,
> Kai
> 

This build error fixed now, thank your excellent work !

Thank you very much !

But new error occurred when I use cross compiler to build native compiler:

...
i686-w64-mingw32-gcc  -O2 -pipe -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual 
-Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -s -o f951.exe \
fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o 
fortran/cpp.o fortran/data.o fortran/decl.o fortran/dump-parse-tree.o
fortran/error.o fortran/expr.o fortran/interface.o fortran/intrinsic.o 
fortran/io.o fortran/iresolve.o fortran/match.o fortran/matchexp.o
fortran/misc.o fortran/module.o fortran/openmp.o fortran/options.o 
fortran/parse.o fortran/primary.o fortran/resolve.o fortran/scanner.o
fortran/simplify.o fortran/st.o fortran/symbol.o fortran/target-memory.o  
fortran/convert.o fortran/dependency.o fortran/f95-lang.o
fortran/trans.o fortran/trans-array.o fortran/trans-common.o 
fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o
fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o 
fortran/trans-stmt.o fortran/trans-types.o main.o  libbackend.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  attribs.o
-L/home/oracle/gcc-4.5-w32_i686-linux/lib -lcloog 
-L/home/oracle/gcc-4.5-w32_i686-linux/lib -lppl_c -lppl -lgmpxx 
-L/home/oracle/gcc-4.5-w32/lib
-L/home/oracle/gcc-4.5-w32/lib -L/home/oracle/gcc-4.5-w32/lib -lmpc -lmpfr 
-lgmp   -L../z

[Mingw-w64-public] sigset_t and w32pth

[Dongsheng Song]

Hi,

When I compile GnuPG 2, I found w32pth[1] use data type sigset_t which
mingw-w64 not supported,
Is there any plan to support sigset_t in sys/types.h ?

#ifndef _SIGSET_T_
#define _SIGSET_T_
typedef int _sigset_t;

#ifndef _NO_OLDNAMES
typedef _sigset_t   sigset_t;
#endif
#endif  /* Not _SIGSET_T_ */

[1] svn://cvs.gnupg.org/w32pth

Regards,
Dongsheng

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] sigset_t and w32pth

[Dongsheng Song]

Thanks, when I build libassuan, I found ENOFILE not defined yet (within errno.h)

#define ENOFILE 2   /* No such file or directory */
#define ENOENT  2

When I add ENOFILE definition, I can build GnuPG 2 success.

I don't know whether ENOFILE should defined.

On Thu, Jul 29, 2010 at 21:52, Kai Tietz  wrote:
> 2010/7/29 Dongsheng Song :
>> Hi,
>>
>> When I compile GnuPG 2, I found w32pth[1] use data type sigset_t which
>> mingw-w64 not supported,
>> Is there any plan to support sigset_t in sys/types.h ?
>>
>> #ifndef _SIGSET_T_
>> #define _SIGSET_T_
>> typedef int     _sigset_t;
>>
>> #ifndef _NO_OLDNAMES
>> typedef _sigset_t       sigset_t;
>> #endif
>> #endif  /* Not _SIGSET_T_ */
>>
>> [1] svn://cvs.gnupg.org/w32pth
>>
>> Regards,
>> Dongsheng
>
> Thanks for the point. Committed at revision 3020 to trunk.
>
> Regards,
> Kai
>
> --
> |  (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] sigset_t and w32pth

[Dongsheng Song]

It seems that Borland C++ defined ENOFILE, and MinGW add the alias of ENOENT.

On Thu, Jul 29, 2010 at 23:43, Ozkan Sezer  wrote:
> On Thu, Jul 29, 2010 at 6:28 PM, Kai Tietz  wrote:
>> 2010/7/29 Dongsheng Song :
>>> Thanks, when I build libassuan, I found ENOFILE not defined yet (within 
>>> errno.h)
>>>
>>> #define ENOFILE         2       /* No such file or directory */
>>> #define ENOENT          2
>>>
>>> When I add ENOFILE definition, I can build GnuPG 2 success.
>>>
>>> I don't know whether ENOFILE should defined.
>>>
>>> On Thu, Jul 29, 2010 at 21:52, Kai Tietz  wrote:
>>>> 2010/7/29 Dongsheng Song :
>>>>> Hi,
>>>>>
>>>>> When I compile GnuPG 2, I found w32pth[1] use data type sigset_t which
>>>>> mingw-w64 not supported,
>>>>> Is there any plan to support sigset_t in sys/types.h ?
>>>>>
>>>>> #ifndef _SIGSET_T_
>>>>> #define _SIGSET_T_
>>>>> typedef int     _sigset_t;
>>>>>
>>>>> #ifndef _NO_OLDNAMES
>>>>> typedef _sigset_t       sigset_t;
>>>>> #endif
>>>>> #endif  /* Not _SIGSET_T_ */
>>>>>
>>>>> [1] svn://cvs.gnupg.org/w32pth
>>>>>
>>>>> Regards,
>>>>> Dongsheng
>>>>
>>>> Thanks for the point. Committed at revision 3020 to trunk.
>>>>
>>>> Regards,
>>>> Kai
>>>>
>>>> --
>>>> |  (\_/) This is Bunny. Copy and paste
>>>> | (='.'=) Bunny into your signature to help
>>>> | (")_(") him gain world domination
>>>>
>>>
>>
>> Well, this is one of those questions. As it is more an alias of ENOENT
>> we can add it.
>> Maybe someone else wants to comment on this addition?
>>
>> Cheers,
>> Kai
>
> The man page for errno(3) on my linux doesn't list ENOFILE.
> Is it a deprecated errno? (I have no objections for its addition, BTW.)
>
> --
> Ozkan
>

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Kai Tietz break cross build gcc on r2945 due to delete FLT/DBL/LDBL_MANT_DIG macros

[Dongsheng Song]

On Wed, Jul 28, 2010 at 21:42, JonY  wrote:
> On 7/28/2010 20:32, Dongsheng Song wrote:
>>
>> 于 2010-7-28 16:02, Kai Tietz 写道:
>>>
>>> 2010/7/28 Dongsheng Song:
>>>>
>>>> 于 2010-7-28 15:43, Kai Tietz 写道:
>>>>>
>>>>> 2010/7/28 Dongsheng Song:
>>>>>>
>>>>>> Hi Kai,
>>>>>>
>>>>>> When we cross build gcc 4.5 for windows, I found we can build windows
>>>>>> gcc binary one
>>>>>> week ago, but now the build failed.
>>>>>>
>>>>>> After I do a binary search, I found the issue caused by r2945.
>>>>>>
>>>>>>    r2950 | 2010-07-24 05:50:28 | FAILED
>>>>>>    r2945 | 2010-07-24 02:44:15 | FAILED
>>>>>>    r2944 | 2010-07-24 02:38:30 | SUCCESS
>>>>>>    r2939 | 2010-07-23 17:55:30 | SUCCESS
>>>>>>    r2928 | 2010-07-23 05:21:20 | SUCCESS
>>>>>>    r2924 | 2010-07-22 18:32:25 | SUCCESS
>>>>>>
>>>>>> r2945 remove some *IMPORTANT* macros from
>>>>>> /trunk/mingw-w64-headers/crt/float.h,
>>>>>> e.g. FLT/DBL/LDBL_MANT_DIG, FLT_EVAL_METHOD, *ALL* decimal macros
>>>>>> (DEC32/64/128_*, ...)
>>>>>>
>>>>>> When I add FLT/DBL/LDBL_MANT_DIG and FLT_EVAL_METHOD back to
>>>>>> /trunk/mingw-w64-headers/crt/float.h,
>>>>>> then the gcc cross build success again.
>>>>>>
>>>>>> So I recommend you apply the attached patch at least.
>>>>>>
>>>>>> btw, I know FLT_EVAL_METHOD added by C99, but
>>>>>> libgfortran/m4/nearest.m4 use it,
>>>>>> is it mean we should use ISO C99 compiler to build gcc 4.5 or later,
>>>>>> not ISO C90 as
>>>>>> http://gcc.gnu.org/install/prerequisites.html ?
>>>>>>
>>>>>> Regards,
>>>>>> Dongsheng
>>>>>
>>>>> Hello Dongsheng,
>>>>>
>>>>> the recent change to float.h was necessary to support the new
>>>>> include_next patch of 4.6. So how are you exactly installing headers?
>>>>> As usual you should just see gcc's internal float.h for older gcc's
>>>>> then 4.6. So I am a bit puzzled. Are you removing gcc's float.h here?
>>>>>
>>>>> Regards,
>>>>> Kai
>>>>>
>>>>
>>>> Hi Kai,
>>>>
>>>> I use Debian 6.0 i686 with latest update, gcc 4.4.4 build a gcc 4.5
>>>> cross compiler for windows,
>>>> then use the cross compiler to build a native gcc 4.5 compiler for
>>>> windows.
>>>>
>>>> Without the patch, both i686-windows and x64-windows failed during build
>>>> native
>>>> compiler.
>>>>
>>>> It's strange since I can build cross compiler, it maybe a gcc bug.
>>>>
>>>> The related packages is:
>>>> gcc 4.5 branch, mingw64 trunk, binutils trunk, gmp 5.0 branch, mpfr 3.0
>>>> branch,
>>>> mpc 0.8.2, ppl 0.10.2, cloog-ppl 0.15.9.
>>>>
>>>> Regards,
>>>> Dongsheng
>>>>
>>>>
>>>
>>> Well, yes it is a gcc bug in respect to native/cross toolchains. I
>>> assume that your search path installs headers (and libraries) in
>>> standard_include for native. This cause that the system-headers get
>>> included before fixed-include and gcc-include.
>>> For this I can provide a patch. See revision 2986. But indeed this
>>> include-order of gcc is a conceptional flaw.
>>>
>>> Cheers,
>>> Kai
>>>
>>
>> This build error fixed now, thank your excellent work !
>>
>> Thank you very much !
>>
>> But new error occurred when I use cross compiler to build native compiler:
>>
>> ...
>> i686-w64-mingw32-gcc  -O2 -pipe -DIN_GCC   -W -Wall -Wwrite-strings
>> -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
>> -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
>> -Wno-overlength-strings -Wold-style-definition -Wc++-compat
>> -DHAVE_CONFIG_H -s -o f951.exe \
>>                fortran/arith.o fortran/array.o fortran/bbt.o
>> fortran/check.o fortran/cpp.o fortran/data.o fortran/decl.o
>> fortran/dump-parse-tree.o
>> fortran/error.o fortran/expr.o fortran/interface.o fortran/in

Re: [Mingw-w64-public] libusb-win32 usb.h and MinGW-w64 usb.h conflict

[Dongsheng Song]

On Sun, Sep 19, 2010 at 07:50, Ozkan Sezer  wrote:

>
> AFAIK, usb.h is out of ddk because it is part of ms platform sdk,
> therefore, it _needs_ to be out of a ddk subdirectory for proper
> compatibility.
>

No, usb.h is in MS WDK 7.1 now:

C:\opt\WinDDK\7.1\inc\api>dir *usb*
 驱动器 C 中的卷没有标签。
 卷的序列号是 10EC-F758

 C:\opt\WinDDK\7.1\inc\api 的目录

2010-02-08  19:19 1,798 dmusbuff.h
2010-02-08  19:19   835 GdiPlusBase.h
2010-02-08  19:1925,346 GdiplusBitmap.h
2010-02-08  19:1927,456 GdiplusBrush.h
2010-02-08  19:1934,169 usb.h
2010-02-08  19:19 8,090 usb100.h
2010-02-08  19:19 3,058 usb200.h
2010-02-08  19:1918,396 usbcamdi.h
2010-02-08  19:19 1,860 usbdi.h
2010-02-08  19:1948,141 usbioctl.h
2010-02-08  19:19 6,924 usbiodef.h
2010-02-08  19:19 1,860 usbrpmif.h
2010-02-08  19:1917,705 usbuser.h
  13 个文件195,638 字节
   0 个目录  9,217,138,688 可用字节

--
Dongsheng
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] multiple definition of _encode_pointer/_decode_pointer

[Dongsheng Song]

Hi all,

When I compile cx_Oracle, I got the warn/error:

O:\gcc-4.5-w32\bin\gcc.exe -mno-cygwin -shared -s
build\temp.win32-2.6-11g\Release\cx_oracle.o
build\temp.win32-2.6-11g\Release\cx_Oracle.def
-LC:\opt\oracle\product\11.2\master\bin -LC:\opt\oracle\product\11.2\master
-LC:\opt\oracle\product\11.2\master\oci\lib\msvc
-LC:\opt\oracle\product\11.2\master\sdk\lib\msvc -LC:
\opt\python-2.6\libs -LC:\opt\python-2.6\PCbuild -loci -lpython26 -lmsvcr90
-o build\lib.win32-2.6-11g\cx_Oracle.pyd
o:/gcc-4.5-w32/bin/../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/lib/libmingw32.a(lib32_libmingw32_a-mingw_helpers.o):mingw_helpers.c:(.text+0x0):
multiple definition of `_decode_pointer'
o:/gcc-4.5-w32/bin/../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/lib/libmsvcr90.a(dcims00352.o):(.text+0x0):
first defined here
o:/gcc-4.5-w32/bin/../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/lib/libmingw32.a(lib32_libmingw32_a-mingw_helpers.o):mingw_helpers.c:(.text+0x10):
multiple definition of `_encode_pointer'
o:/gcc-4.5-w32/bin/../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/lib/libmsvcr90.a(dcims00362.o):(.text+0x0):
first defined here
collect2: ld returned 1 exit status

Can I safely ignore the message ?

Regards,
Dongsheng
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] multiple definition of _encode_pointer/_decode_pointer

[Dongsheng Song]

On Mon, Sep 20, 2010 at 18:50, Ozkan Sezer  wrote:

> On Mon, Sep 20, 2010 at 12:32 PM, Dongsheng Song
>  wrote:
> > Hi all,
> >
> > When I compile cx_Oracle, I got the warn/error:
> >
> > O:\gcc-4.5-w32\bin\gcc.exe -mno-cygwin -shared -s
> > build\temp.win32-2.6-11g\Release\cx_oracle.o
> > build\temp.win32-2.6-11g\Release\cx_Oracle.def
> > -LC:\opt\oracle\product\11.2\master\bin
> -LC:\opt\oracle\product\11.2\master
> > -LC:\opt\oracle\product\11.2\master\oci\lib\msvc
> > -LC:\opt\oracle\product\11.2\master\sdk\lib\msvc -LC:
> > \opt\python-2.6\libs -LC:\opt\python-2.6\PCbuild -loci -lpython26
> -lmsvcr90
> > -o build\lib.win32-2.6-11g\cx_Oracle.pyd
> >
> o:/gcc-4.5-w32/bin/../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/lib/libmingw32.a(lib32_libmingw32_a-mingw_helpers.o):mingw_helpers.c:(.text+0x0):
> > multiple definition of `_decode_pointer'
> >
> o:/gcc-4.5-w32/bin/../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/lib/libmsvcr90.a(dcims00352.o):(.text+0x0):
> > first defined here
> >
> o:/gcc-4.5-w32/bin/../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/lib/libmingw32.a(lib32_libmingw32_a-mingw_helpers.o):mingw_helpers.c:(.text+0x10):
> > multiple definition of `_encode_pointer'
> >
> o:/gcc-4.5-w32/bin/../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/lib/libmsvcr90.a(dcims00362.o):(.text+0x0):
> > first defined here
> > collect2: ld returned 1 exit status
>
> I guess the fix should be commenting out those exports from msvcr90.def
> and msvcr90d.def.
>
> >
> > Can I safely ignore the message ?
> >
> > Regards,
> > Dongsheng
>
> Ignore an error???
>
> My mean is use:
   --allow-multiple-definition
   -z muldefs
   Normally when a symbol is defined multiple times, the linker will
   report a fatal error. These options allow multiple definitions
and
   the first definition will be used.

--
Dongsheng
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Did anyone got TBB 2.2 to build with mingw64 before?

[Dongsheng Song]

 On 2010-9-21 10:11, Hradec wrote:
> I got tbb.dll to build properly, but its failling when building tbbmalloc:
>
>
> ../../src/tbbmalloc/MemoryAllocator.cpp:42:0: warning: "_WIN32_WINNT" 
> redefined
> /media/MyBook2TB_2/Mirror/cortex4all/trunk/compilers/linux.mingw32.4.6.0_20100411/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/include/_mingw.h:171:0:
> note: this is the location of the previous definition
> ../../src/tbbmalloc/MemoryAllocator.cpp: In function 'uintptr_t 
> rml::internal::cleanupCacheIfNeed()':
> ../../src/tbbmalloc/MemoryAllocator.cpp:1384:70: error: invalid 
> initialization of reference of type 'volatile uintptr_t&' from expression of
> type 'size_t'
> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
> ../../src/tbbmalloc/MemoryAllocator.cpp:1385:68: error: invalid 
> initialization of reference of type 'volatile uintptr_t&' from expression of
> type 'size_t'
> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
> ../../src/tbbmalloc/MemoryAllocator.cpp: In function 'void* 
> rml::internal::allocateCachedLargeObject(size_t)':
> ../../src/tbbmalloc/MemoryAllocator.cpp:1402:51: error: invalid 
> initialization of reference of type 'volatile uintptr_t&' from expression of
> type 'size_t'
> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
> ../../src/tbbmalloc/MemoryAllocator.cpp: In function 'void* 
> rml::internal::mallocLargeObject(size_t, size_t)':
> ../../src/tbbmalloc/MemoryAllocator.cpp:1419:54: error: invalid 
> initialization of reference of type 'volatile uintptr_t&' from expression of
> type 'size_t'
> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
> ../../src/tbbmalloc/MemoryAllocator.cpp: In function 'bool 
> rml::internal::freeLargeObjectToCache(rml::internal::LargeObjectHeader*)':
> ../../src/tbbmalloc/MemoryAllocator.cpp:1450:50: error: invalid 
> initialization of reference of type 'volatile uintptr_t&' from expression of
> type 'size_t'
> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
> ../../src/tbbmalloc/MemoryAllocator.cpp:1456:51: error: invalid 
> initialization of reference of type 'volatile uintptr_t&' from expression of
> type 'size_t'
> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
> ../../src/tbbmalloc/MemoryAllocator.cpp: In function 'void 
> rml::internal::freeLargeObject(void*)':
> ../../src/tbbmalloc/MemoryAllocator.cpp:1468:62: error: invalid 
> initialization of reference of type 'volatile uintptr_t&' from expression of
> type 'size_t'
> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
> make[2]: *** [MemoryAllocator.o] Error 1
> make[2]: Leaving directory
> `/media/MyBook2TB_2/Mirror/cortex4all/trunk/OIIO/externals/build/mingw/obj/tbb22_004oss/build/windows_ia32_gcc_mingw_debug'
> make[1]: *** [tbbmalloc] Error 2
> make[1]: Leaving directory 
> `/media/MyBook2TB_2/Mirror/cortex4all/trunk/OIIO/externals/build/mingw/obj/tbb22_004oss'
>
>
> I'm using the automated build:
>
> i686-w64-mingw32-gcc (GCC) 4.6.0 20100411 (experimental)
>
> should I try with a newer one?
>
> -- 
> Hradec
>

No, This is TBB bug, the following code in MemoryAllocator.cpp:

#if USE_PTHREAD
// Some pthreads documentation says that  must be first header.
#include 
#define TlsSetValue_func pthread_setspecific
#define TlsGetValue_func pthread_getspecific
typedef pthread_key_t tls_key_t;
#include 
inline void do_yield() {sched_yield();}

#elif USE_WINTHREAD
#define _WIN32_WINNT 0x0400
#include 
#define TlsSetValue_func TlsSetValue
#define TlsGetValue_func TlsGetValue
typedef DWORD tls_key_t;
inline void do_yield() {SwitchToThread();}

#else
#error Must define USE_PTHREAD or USE_WINTHREAD

#endif

Should be changed to:

#if USE_PTHREAD
// Some pthreads documentation says that  must be first header.
#include 
#define TlsSetValue_func pthread_setspecific
#define TlsGetValue_func pthread_getspecific
typedef pthread_key_t tls_key_t;
#include 
inline void do_yield() {sched_yield();}

#elif USE_WINTHREAD
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0400
#endif

#include 
#define TlsSetValue_func TlsSetValue
#define TlsGetValue_func TlsGetValue
typedef DWORD tls_key_t;
inline void do_yield() {SwitchToThread();}

#else
#error Must define USE_PTHREAD or USE_WINTHREAD

#endif

--
Dongsheng



signature.asc
Description: OpenPGP digital signature

Re: [Mingw-w64-public] Did anyone got TBB 2.2 to build with mingw64 before?

[Dongsheng Song]

 On 2010-9-21 10:26, Dongsheng Song wrote:
>  On 2010-9-21 10:11, Hradec wrote:
>> I got tbb.dll to build properly, but its failling when building tbbmalloc:
>>
>>
>> ../../src/tbbmalloc/MemoryAllocator.cpp:42:0: warning: "_WIN32_WINNT" 
>> redefined
>> /media/MyBook2TB_2/Mirror/cortex4all/trunk/compilers/linux.mingw32.4.6.0_20100411/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/include/_mingw.h:171:0:
>> note: this is the location of the previous definition
>> ../../src/tbbmalloc/MemoryAllocator.cpp: In function 'uintptr_t 
>> rml::internal::cleanupCacheIfNeed()':
>> ../../src/tbbmalloc/MemoryAllocator.cpp:1384:70: error: invalid 
>> initialization of reference of type 'volatile uintptr_t&' from expression of
>> type 'size_t'
>> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
>> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
>> ../../src/tbbmalloc/MemoryAllocator.cpp:1385:68: error: invalid 
>> initialization of reference of type 'volatile uintptr_t&' from expression of
>> type 'size_t'
>> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
>> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
>> ../../src/tbbmalloc/MemoryAllocator.cpp: In function 'void* 
>> rml::internal::allocateCachedLargeObject(size_t)':
>> ../../src/tbbmalloc/MemoryAllocator.cpp:1402:51: error: invalid 
>> initialization of reference of type 'volatile uintptr_t&' from expression of
>> type 'size_t'
>> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
>> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
>> ../../src/tbbmalloc/MemoryAllocator.cpp: In function 'void* 
>> rml::internal::mallocLargeObject(size_t, size_t)':
>> ../../src/tbbmalloc/MemoryAllocator.cpp:1419:54: error: invalid 
>> initialization of reference of type 'volatile uintptr_t&' from expression of
>> type 'size_t'
>> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
>> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
>> ../../src/tbbmalloc/MemoryAllocator.cpp: In function 'bool 
>> rml::internal::freeLargeObjectToCache(rml::internal::LargeObjectHeader*)':
>> ../../src/tbbmalloc/MemoryAllocator.cpp:1450:50: error: invalid 
>> initialization of reference of type 'volatile uintptr_t&' from expression of
>> type 'size_t'
>> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
>> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
>> ../../src/tbbmalloc/MemoryAllocator.cpp:1456:51: error: invalid 
>> initialization of reference of type 'volatile uintptr_t&' from expression of
>> type 'size_t'
>> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
>> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
>> ../../src/tbbmalloc/MemoryAllocator.cpp: In function 'void 
>> rml::internal::freeLargeObject(void*)':
>> ../../src/tbbmalloc/MemoryAllocator.cpp:1468:62: error: invalid 
>> initialization of reference of type 'volatile uintptr_t&' from expression of
>> type 'size_t'
>> ../../src/tbbmalloc/Customize.h:97:18: error: in passing argument 1 of 
>> 'uintptr_t AtomicAdd(volatile uintptr_t&, uintptr_t)'
>> make[2]: *** [MemoryAllocator.o] Error 1
>> make[2]: Leaving directory
>> `/media/MyBook2TB_2/Mirror/cortex4all/trunk/OIIO/externals/build/mingw/obj/tbb22_004oss/build/windows_ia32_gcc_mingw_debug'
>> make[1]: *** [tbbmalloc] Error 2
>> make[1]: Leaving directory 
>> `/media/MyBook2TB_2/Mirror/cortex4all/trunk/OIIO/externals/build/mingw/obj/tbb22_004oss'
>>
>>
>> I'm using the automated build:
>>
>> i686-w64-mingw32-gcc (GCC) 4.6.0 20100411 (experimental)
>>
>> should I try with a newer one?
>>
>> -- 
>> Hradec
>>
> No, This is TBB bug, the following code in MemoryAllocator.cpp:
>
> #if USE_PTHREAD
> // Some pthreads documentation says that  must be first 
> header.
> #include 
> #define TlsSetValue_func pthread_setspecific
> #define TlsGetValue_func pthread_getspecific
> typedef pthread_key_t tls_key_t;
> #include 
> inline void do_yield() {sched_yield();}
>
> #elif USE_WINTHREAD
> #define _WIN32_WINNT 0x0400
> #include 
> #define TlsSetValue_func TlsSetValue
>   

[Mingw-w64-public] Please get rid of symbols from mingw-w64-crt\lib32\msvcrt.def which belong to msvcr70.dll and msvcr80.dll

[Dongsheng Song]

 When I build libiconv NLS version, I can not run iconv.exe, which reference
a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol
after the following comments line:

; msvcr80.dll and later

If we want to support Windows XP (SP3 or later), we should not include
symbols which not belong to msvcrt.dll:

File Version:7.0.2600.5512 (xpsp.080413-2111)
Product Version: 6.1.8638.5512

Regards,
Dongsheng



signature.asc
Description: OpenPGP digital signature
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Please get rid of symbols from mingw-w64-crt\lib32\msvcrt.def which belong to msvcr70.dll and msvcr80.dll

[Dongsheng Song]

On Wed, Sep 29, 2010 at 17:56, JonY  wrote:
> On 9/29/2010 16:34, Dongsheng Song wrote:
> >  When I build libiconv NLS version, I can not run iconv.exe, which reference
> > a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol
> > after the following comments line:
> >
> > ; msvcr80.dll and later
> >
> > If we want to support Windows XP (SP3 or later), we should not include
> > symbols which not belong to msvcrt.dll:
> >
> > File Version:    7.0.2600.5512 (xpsp.080413-2111)
> > Product Version: 6.1.8638.5512
>
> As far as I know, this is not a bug. That comment means that it is
> available with Windows 7.
>
> Until its reimplemented in libmingwex, the proper fix would be not to
> call it if you expect your program to run on earlier versions of windows.

But we can not ensure third party software DO NOT call those functions,
so we must drop them or defined in guard blocks like this:

/* Windows 7 */
#if _WIN32_WINNT >= 0x0601
#endif

/* Windows Vista or Server 2008 */
#if _WIN32_WINNT >= 0x0600
#endif

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Please get rid of symbols from mingw-w64-crt\lib32\msvcrt.def which belong to msvcr70.dll and msvcr80.dll

[Dongsheng Song]

On Wed, Sep 29, 2010 at 21:56, Xiaofan Chen  wrote:
> On Wed, Sep 29, 2010 at 5:56 PM, JonY  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 9/29/2010 16:34, Dongsheng Song wrote:
>>>  When I build libiconv NLS version, I can not run iconv.exe, which reference
>>> a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol
>>> after the following comments line:
>>>
>>> ; msvcr80.dll and later
>>>
>>> If we want to support Windows XP (SP3 or later), we should not include
>>> symbols which not belong to msvcrt.dll:
>>>
>>> File Version:    7.0.2600.5512 (xpsp.080413-2111)
>>> Product Version: 6.1.8638.5512
>>>
>> As far as I know, this is not a bug. That comment means that it is
>> available with Windows 7.
>
> Is this correct?
> http://msdn.microsoft.com/en-us/library/z50ty2zh%28VS.80%29.aspx
>
> So it can be available for many versions of Windows.
>
> --
> Xiaofan
>

No, the page is incorrect. I confirmed both XP and 2003 R2 no wcsnlen defined.

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Please get rid of symbols from mingw-w64-crt\lib32\msvcrt.def which belong to msvcr70.dll and msvcr80.dll

[Dongsheng Song]

On 2010-9-29 22:33, Kai Tietz wrote:
 On Wed, Sep 29, 2010 at 5:56 PM, JonY  wrote:
> As far as I know, this is not a bug. That comment means that it is
> available with Windows 7.
>
> Until its reimplemented in libmingwex, the proper fix would be not to
> call it if you expect your program to run on earlier versions of windows.


No, this is not possible/acceptable. For example, the following code is very 
general:

# if HAVE_WCSNLEN
#  define local_wcsnlen wcsnlen
# else
static size_t
local_wcsnlen (const wchar_t *s, size_t maxlen)
{
  const wchar_t *ptr;

  for (ptr = s; maxlen > 0 && *ptr != (wchar_t) 0; ptr++, maxlen--)
;
  return ptr - s;
}
# endif

But since wcsnlen in both headers and libmsvrt.a, the autotools always
report 'yes, your target platform have wcsnlen' !!!

If we do not want to drop these symbols not in windows XP, we should declare:

mingw-64 maybe generate invalid dll/exe files on target platform older than 
windows 7.
Because these files maybe reference symbols only valid on windows 7, please 
check your
dll/exe files carefully after build.

> The only general solution for this would be that someone contributes
> an implementation for this function. So we don't dependent here. The
> only issue I see here is that this wcstrnlen possibly depends on
> internal undocumented stuff. I'll do some research for this.

Maybe there have another solution:

S1: the intersection of XP and 2k3 symbols in msvcrt.dll
S2: the intersection of VISTA and 2k8 symbols in msvcrt.dll
S3: the Windows 7 symbols in msvcrt.dll

libmsvcrt: S1
libvista:  (S2 - S1)
libwin7: (S3 - S1) or (S3 - S2)

If user want to use symbols in VISTA/2K8, they should put libvista in 
additional library list.
Then the generated files only valid on vista/2k8 or later is acceptable for 
these users.

If user want to use symbols in Windows 7, they should put libwin7 in additional 
library list.
Then the generated files only valid on Windows 7 or later is acceptable for 
these users.

Regards,
Dongsheng



signature.asc
Description: OpenPGP digital signature
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] LLVM and CLang 2.8 with mingw-w64

[Dongsheng Song]

Hi all,

Can I use mingw-w64 compile LLVM and CLang 2.8 ?

C:\var\tmp\obj>cmake.exe -v -G  "MinGW Makefiles" ..\llvm-2.8
C:\var\tmp\obj>gmake
Scanning dependencies of target LLVMSystem
[  0%] Building CXX object lib/System/CMakeFiles/LLVMSystem.dir/Alarm.cpp.obj
[  0%] Building CXX object lib/System/CMakeFiles/LLVMSystem.dir/Atomic.cpp.obj
[  0%] Building CXX object
lib/System/CMakeFiles/LLVMSystem.dir/Disassembler.cpp.obj
[  1%] Building CXX object
lib/System/CMakeFiles/LLVMSystem.dir/DynamicLibrary.cpp.obj
In file included from
C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc:14:0,
 from C:\var\tmp\llvm-2.8\lib\System\DynamicLibrary.cpp:49:
C:\var\tmp\llvm-2.8\lib\System\/Win32/Win32.h:20:0: warning:
"_WIN32_WINNT" redefined
c:\gcc-4.5-w32\bin\../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/include/_mingw.h:235:0:
note: this is the location of the previous definition
In file included from C:\var\tmp\llvm-2.8\lib\System\DynamicLibrary.cpp:49:0:
C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc: In static
member function 'static bool
llvm::sys::DynamicLibrary::LoadLibraryPermanently(const char*,
std::string*)':
C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc:103:64:
error: invalid conversion from 'BOOL (*)(CHAR*, llvm::ModuleBaseType,
ULONG, void*)' to 'WINBOOL (*)(const CHAR*, ULONG, ULONG, void*)'
C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc: In static
member function 'static void*
llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(const char*)':
C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc:158:23:
warning: ISO C++ forbids casting between pointer-to-function and
pointer-to-object
gmake[2]: *** [lib/System/CMakeFiles/LLVMSystem.dir/DynamicLibrary.cpp.obj]
Error 1
gmake[1]: *** [lib/System/CMakeFiles/LLVMSystem.dir/all] Error 2
gmake: *** [all] Error 2

--
Dongsheng

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] LLVM and CLang 2.8 with mingw-w64

[Dongsheng Song]

On Sat, Oct 9, 2010 at 11:28, Jon <10wa...@gmail.com> wrote:
> On 10/7/10, Dongsheng Song  wrote:
>> c:\gcc-4.5-w32\bin\../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/include/_mingw.h:235:0:
>> note: this is the location of the previous definition
>> In file included from
>> C:\var\tmp\llvm-2.8\lib\System\DynamicLibrary.cpp:49:0:
>> C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc: In static
>> member function 'static bool
>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(const char*,
>> std::string*)':
>> C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc:103:64:
>> error: invalid conversion from 'BOOL (*)(CHAR*, llvm::ModuleBaseType,
>> ULONG, void*)' to 'WINBOOL (*)(const CHAR*, ULONG, ULONG, void*)'
>> C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc: In static
>> member function 'static void*
>> llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(const char*)':
>> C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc:158:23:
>> warning: ISO C++ forbids casting between pointer-to-function and
>> pointer-to-object
>> gmake[2]: *** [lib/System/CMakeFiles/LLVMSystem.dir/DynamicLibrary.cpp.obj]
>> Error 1
>> gmake[1]: *** [lib/System/CMakeFiles/LLVMSystem.dir/all] Error 2
>> gmake: *** [all] Error 2
>>
> You should ask the llvm and clang developers for help.
>

No, this is a mingw-w64 issue, because I can compile LLVM and CLang
2.8 by mingw32
compiler smoothly.

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] LLVM and CLang 2.8 with mingw-w64

[Dongsheng Song]

On 2010-10-9 16:41, Ozkan Sezer wrote:
> On Sat, Oct 9, 2010 at 11:20 AM, İsmail Dönmez  wrote:
>> Hi;
>>
>> On Sat, Oct 9, 2010 at 10:35 AM, Ozkan Sezer  wrote:
>>>
>>> On Sat, Oct 9, 2010 at 8:41 AM, Dongsheng Song 
>>> wrote:
>>>> On Sat, Oct 9, 2010 at 11:28, Jon <10wa...@gmail.com> wrote:
>>>>> On 10/7/10, Dongsheng Song  wrote:
>>>>>>
>>>>>> c:\gcc-4.5-w32\bin\../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/include/_mingw.h:235:0:
>>>>>> note: this is the location of the previous definition
>>>>>> In file included from
>>>>>> C:\var\tmp\llvm-2.8\lib\System\DynamicLibrary.cpp:49:0:
>>>>>> C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc: In static
>>>>>> member function 'static bool
>>>>>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(const char*,
>>>>>> std::string*)':
>>>>>> C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc:103:64:
>>>>>> error: invalid conversion from 'BOOL (*)(CHAR*, llvm::ModuleBaseType,
>>>>>> ULONG, void*)' to 'WINBOOL (*)(const CHAR*, ULONG, ULONG, void*)'
>>>>>> C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc: In static
>>>>>> member function 'static void*
>>>>>> llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(const char*)':
>>>>>> C:\var\tmp\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc:158:23:
>>>>>> warning: ISO C++ forbids casting between pointer-to-function and
>>>>>> pointer-to-object
>>>>>> gmake[2]: ***
>>>>>> [lib/System/CMakeFiles/LLVMSystem.dir/DynamicLibrary.cpp.obj]
>>>>>> Error 1
>>>>>> gmake[1]: *** [lib/System/CMakeFiles/LLVMSystem.dir/all] Error 2
>>>>>> gmake: *** [all] Error 2
>>>>>>
>>>>> You should ask the llvm and clang developers for help.
>>>>>
>>>>
>>>> No, this is a mingw-w64 issue, because I can compile LLVM and CLang
>>>> 2.8 by mingw32
>>>> compiler smoothly.
>>>>
>>>
>>> No, this is not a mingw-w64 problem, because LLVM assumes that for
>>> non-MSVC compilers EnumerateLoadedModules() has a non-const first
>>> argument which is not correct for us: It should check against the
>>> value of the API_VERSION_NUMBER macro from imagehlp.h or dbghelp.h
>>> which is 11 which indicates the new api with many functions have
>>> constified arguments.  (PS:  They also assume that mingw does not
>>> have a dbghelp.h header: mingw.org does not, but mingw-w64 has it.)
>>
>> If you can cook up a simple testcase I'll report an LLVM bug.
>> Regards,
>> ismail
>>
> 
> There you go:
> 
> $ cat foo.cc
> #ifdef _WIN64
> #error test for x86-windows only
> #endif
> #ifndef __MINGW32__
> #error test for mingw only
> #endif
> 
> #define WIN32_LEAN_AND_MEAN
> #include 
> #include 
> 
> extern "C" WINBOOL WINAPI foo9 (PSTR, ULONG,PVOID);
> extern "C" WINBOOL WINAPI foo11(PCSTR,ULONG,PVOID);
> 
> #if 1 /* this is wrong */
> PSYM_ENUMMODULES_CALLBACK p1 = foo9;
> 
> #else /* the following is right */
> 
> #if API_VERSION_NUMBER < 11
> PSYM_ENUMMODULES_CALLBACK p1 = foo9;
> #else
> PSYM_ENUMMODULES_CALLBACK p1 = foo11;
> #endif
> 
> #endif
> 
> 
> For mingw.org, this will compile fine because they are at
> version 7 api (at least their imagehlp.h claims that way.)
> For mingw-w64 this will fail unless you change the #if 1 to
> an #if 0
> 
> --
> Ozkan

Thanks, with the attach patches, I can build LLVM and CLang with
mingw-w64.

Moreover, I think SearchForAddressOfSymbol should change the signature,
return function pointer instead of data pointer.

In file included from C:\var\pool\llvm-2.8\lib\System\DynamicLibrary.cpp:49:0:
C:\var\pool\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc: In static member 
function 'static void*
llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(const char*)':
C:\var\pool\llvm-2.8\lib\System\/Win32/DynamicLibrary.inc:160:23: warning: ISO 
C++ forbids casting between pointer-to-function and pointer-to-object

--
Dongsheng
--- llvm-2.8.orig\lib\System\Win32\DynamicLibrary.inc   2010-01-15 04:19:52 
+0800
+++ llvm-2.8\lib\System\Win32\DynamicLibrary.inc2010-10-09 16:53:08 
+0800
@@ -49,13 +49,15 @@
 
 extern "C" {
 // Use old callback if:
-//  - Not using Visual Studio
 //  - Visual Studio 2005 or earl

[Mingw-w64-public] Is there are ways to distinguish mingw32 and mingw-w64 (32bit) compiler?

[Dongsheng Song]

Hi all,

Since mingw-w64 (32bit) have many new features than mingw32, I must
distinguish
these two compilers at compile time, how can I do it ?

--
Dongsheng
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Is there are ways to distinguish mingw32 and mingw-w64 (32bit) compiler?

[Dongsheng Song]

On Sun, Oct 10, 2010 at 14:19, Kai Tietz  wrote:

> Hello Dongsheng.
>
> 2010/10/10 Dongsheng Song :
> > Hi all,
> >
> > Since mingw-w64 (32bit) have many new features than mingw32, I must
> > distinguish
> > these two compilers at compile time, how can I do it ?
>
> If you want to distinguish while compile time you can use the defined
> macros __MINGW64_VERSION_MAJOR & __MINGW64_VERSION_MINOR. Those are
> defined only by mingw-w64 headers. You get those defines by including
> any standard header or by including _mingw.h directly.
>
> To see if it is a mingw-w64 runtime on link-time, you can check for
> the existance of the function  '__mingw_get_crt_info'. See here for
> prototype the _mingw.h header.
>
> Well, also you can be sure that a target triplet using the -w64-
> vendor key, is mingw-w64 driven.
>
> I hope I could help you.
>
> Regards,
> Kai
>
> Thanks, __MINGW64_VERSION is I need.

Just for curiosity, how can I use target triplet ? In autotools and config.h
?
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Problems of build multilibs

[Dongsheng Song]

Hi all,

1. .dll files install error

When I build multilibs under i686-linux, all .dll files go to ${PREFIX}/bin,
I have to copy 32 bit .dll files to ${PREFIX}/bin, and 64 bit .dll files to 
${PREFIX}/bin/64 manually.

Is this a known issues ?

2. lib, lib32 and lib64
Why we must use all 3 names ?

I found lib in the tail of LIBRARY_PATH (gcc -v) of both 32 bit target and 64 
bit target,
IMHO, this absolutely wrong.

Can we use lib32 and lib64 only ?

Or for 32 bit default target, can we use lib and lib64 only ?
And for 64 bit default target, can we use lib and lib32 only ?

3. symlinks
Even for single target, we must set symlinks. Can we disable the mess multilibs 
support in this occasion ?

Regards,
Dongsheng



signature.asc
Description: OpenPGP digital signature
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems of build multilibs

[Dongsheng Song]

On Thu, Oct 14, 2010 at 22:35, NightStrike  wrote:
> On Wed, Oct 13, 2010 at 5:06 AM, Dongsheng Song
>  wrote:
>> 3. symlinks
>> Even for single target, we must set symlinks. Can we disable the mess 
>> multilibs support in this occasion ?
>
> Which symlink, the lib > libXX, or the mingw > $target?  And, can you
> rephrase your actual question?  I do not understand what exactly you
> are asking.
>

For i686-w64-mingw32 target, I do not expected lib32 existed:

~/gcc-4.5-xp$ du -hs *
17M bin
8.3Minclude
11M lib
19M lib32
64M libexec
11M share
65M i686-w64-mingw32


For x86_64-w64-mingw32 target, I do not expected lib64 existed:
~/gcc-4.5-x64$ du -hs *
21M bin
8.3Minclude
13M lib
24M lib64
69M libexec
11M share
127Mx86_64-w64-mingw32

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] symbols conflict between lib64/libmingwex.a and lib64/libmsvcrt.a

[Dongsheng Song]

 Hi,

Here is the list:
_assert lib64_libmingwex_a-wassert.o
_fpresetlib64_libmingw32_a-CRT_fp10.o
_rotl64 lib64_libmingwex_a-_rotl64.o
_rotr64 lib64_libmingwex_a-_rotr64.o
cos lib64_libmingwex_a-cos.o
difftimelib64_libmingwex_a-difftime.o
exp lib64_libmingwex_a-exp.o
fmodlib64_libmingwex_a-fmod.o
log lib64_libmingwex_a-log.o
modflib64_libmingwex_a-modf.o
sin lib64_libmingwex_a-sin.o
sqrtlib64_libmingwex_a-sqrt.o

--
Dongsheng Song



signature.asc
Description: OpenPGP digital signature
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] symbols conflict between lib32/libmingwex.a and lib32/libmsvcrt.a

[Dongsheng Song]

 Hi,

Here is the list:
__assertlib32_libmingwex_a-wassert.o
_coslib32_libmingwex_a-cos.o
_difftime   lib32_libmingwex_a-difftime.o
_explib32_libmingwex_a-exp.o
_fabs   lib32_libmingwex_a-fabs.o
_fmod   lib32_libmingwex_a-fmod.o
_loglib32_libmingwex_a-log.o
_longjmplib32_libmingwex_a-mingw_getsp.o
_modf   lib32_libmingwex_a-modf.o
_sinlib32_libmingwex_a-sin.o
_sqrt   lib32_libmingwex_a-sqrt.o

--
Dongsheng Song




signature.asc
Description: OpenPGP digital signature
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-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] symbols conflict between lib64/libmingwex.a and lib64/libmsvcrt.a

[Dongsheng Song]

On 2010-10-19 13:43, Ozkan Sezer wrote:
> 2010/10/19 Dongsheng Song :
>>  Hi,
>>
>> Here is the list:
>> _assert lib64_libmingwex_a-wassert.o
>> _fpresetlib64_libmingw32_a-CRT_fp10.o
>> _rotl64 lib64_libmingwex_a-_rotl64.o
>> _rotr64 lib64_libmingwex_a-_rotr64.o
>> cos lib64_libmingwex_a-cos.o
>> difftimelib64_libmingwex_a-difftime.o
>> exp lib64_libmingwex_a-exp.o
>> fmodlib64_libmingwex_a-fmod.o
>> log lib64_libmingwex_a-log.o
>> modflib64_libmingwex_a-modf.o
>> sin lib64_libmingwex_a-sin.o
>> sqrtlib64_libmingwex_a-sqrt.o
>>
>> --
>> Dongsheng Song
>>
> 
> Is this with trunk only or is it the same for the release
> branch too?
> 
> --
> O.S.

I just checked the trunk.




signature.asc
Description: OpenPGP digital signature
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-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] symbols conflict between lib32/libmingwex.a and lib32/libmsvcrt.a

[Dongsheng Song]

On 2010-10-19 13:43, Ozkan Sezer wrote:
> On Tue, Oct 19, 2010 at 6:30 AM, Dongsheng Song
>  wrote:
>>  Hi,
>>
>> Here is the list:
>> __assertlib32_libmingwex_a-wassert.o
>> _coslib32_libmingwex_a-cos.o
>> _difftime   lib32_libmingwex_a-difftime.o
>> _explib32_libmingwex_a-exp.o
>> _fabs   lib32_libmingwex_a-fabs.o
>> _fmod   lib32_libmingwex_a-fmod.o
>> _loglib32_libmingwex_a-log.o
>> _longjmplib32_libmingwex_a-mingw_getsp.o
>> _modf   lib32_libmingwex_a-modf.o
>> _sin    lib32_libmingwex_a-sin.o
>> _sqrt   lib32_libmingwex_a-sqrt.o
>>
>> --
>> Dongsheng Song
>>
> 
> Is this with trunk only or is it the same for the release
> branch too?
> 
> --
> O.S.

I just checked the trunk.




signature.asc
Description: OpenPGP digital signature
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-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] symbols conflict between lib64/libmingwex.a and lib64/libmsvcrt.a

[Dongsheng Song]

On 2010-10-19 14:13, Kai Tietz wrote:
> Well, all those symbols in msvcrt.def need to be marked by DATA.
> 
> Thanks for the list.
> 
> Cheers,
> Kai
> 

What's the difference between comment out and marked by DATA ?

Regards,
Dongsheng



signature.asc
Description: OpenPGP digital signature
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-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] [Mingw-users] Is WSARecvMsg available in mingw?

[Dongsheng Song]

On Fri, Nov 19, 2010 at 16:56, Jeroen Asselman  wrote:
> Hello,
>
> Currently I am porting an existing Linux program to windows which is
> heavily network oriented.
> Almost all code is ported, however I also need a replacement for the
> recvmsg method in linux. Searching the MSDN docs I found WSARecvMsg,
> allthough it is included in mingws mswsock.h I can't succesfully compile
> it because the reference to the method is missing:
>
> undefined reference to `wsarecv...@20'
>
> The libraries linked are:
>  -lwsock32 -lregex -lz -liconv -lws2_32 -lmswsock
>
> Is it at all possible to use WSARecvMsg? Or am I forgetting another
> library I should link against.
>
> - Jeroen
>

According MSDN page:
  http://msdn.microsoft.com/en-us/library/ms741687%28VS.85%29.aspx

WSARecvMsg in mswsock since Windows Server 2003,
but It's very strange both mingw32 and mingw-w64 not include it.

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Problems of build multilibs

[Dongsheng Song]

On Mon, Nov 29, 2010 at 02:05, NightStrike  wrote:
> On Fri, Oct 15, 2010 at 11:42 PM, Dongsheng Song
>  wrote:
>> On Thu, Oct 14, 2010 at 22:35, NightStrike  wrote:
>>> On Wed, Oct 13, 2010 at 5:06 AM, Dongsheng Song
>>>  wrote:
>>>> 3. symlinks
>>>> Even for single target, we must set symlinks. Can we disable the mess 
>>>> multilibs support in this occasion ?
>>>
>>> Which symlink, the lib > libXX, or the mingw > $target?  And, can you
>>> rephrase your actual question?  I do not understand what exactly you
>>> are asking.
>>>
>>
>> For i686-w64-mingw32 target, I do not expected lib32 existed:
>>
>> ~/gcc-4.5-xp$ du -hs *
>> 17M     bin
>> 8.3M    include
>> 11M     lib
>> 19M     lib32
>> 64M     libexec
>> 11M     share
>> 65M     i686-w64-mingw32
>>
>>
>> For x86_64-w64-mingw32 target, I do not expected lib64 existed:
>> ~/gcc-4.5-x64$ du -hs *
>> 21M     bin
>> 8.3M    include
>> 13M     lib
>> 24M     lib64
>> 69M     libexec
>> 11M     share
>> 127M    x86_64-w64-mingw32
>>
>
> Yes, this does seem backwards.  Are the directory names wrong, or the
> contents wrong?
>

If I do the symbol link, nothing wrong. But why i686-w64-mingw32 only
target require lib32 exist ?
And why x86_64-w64-mingw32 only target require lib64 exist ?

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-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.6 build

[Dongsheng Song]

On Tue, Dec 21, 2010 at 23:39, Kai Tietz  wrote:
> This is a LTO issue. There are still patches coming by Dave for 4.6 on
> LTO support. Do you use here recent binutils version and maybe update
> gcc's tree here, too.
>

Hi Kai,

I see the trunk have CLooG BACKENDS isl, ppl and ppl-legacy:

  --enable-ltoenable link time optimization support
  --disable-ppl-version-checkdisable check for PPL version
  --enable-cloog-backend[=BACKEND]
  set the CLooG BACKEND used to either isl, ppl or
  ppl-legacy (default)
  --disable-cloog-version-check
  disable check for CLooG version
  --with-ppl=PATH Specify prefix directory for the installed PPL package
  --with-cloog=PATH   Specify prefix directory for the installed CLooG-PPL
  package.

But no version spcified, does it mean I can use CLooG-0.16 with isl-0.05 ?
If I use CLooG with isl, then I can throw away ppl, right ?

What's the latest ppl, cloog version preferred ?

--
Dongsheng

--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] winscard.h required by windows.h (only in mingw-w64, not mingw.org)

[Dongsheng Song]

Hi Luis,

Please try the following patch (include VC6 trick):

 include/sqlfront.h   |5 +
 include/tds_sysdep_private.h |2 +-
 win32/config.h   |7 ---
 3 files changed, 10 insertions(+), 4 deletions(-)

--- a/include/sqlfront.h
+++ b/include/sqlfront.h
@@ -29,11 +29,16 @@ typedef DBPROCESS * PDBPROCESS;
 typedef LOGINREC  * PLOGINREC;
 typedef DBCURSOR  * PDBCURSOR;

+#ifndef _WIN32
+/*
+ Some Windows Data Types (
http://msdn.microsoft.com/en-us/library/aa383751%28VS.85%29.aspx)
+ */
 typedef   int  *   LPINT;
 typedef   char *   LPSTR;
 typedef   BYTE *   LPBYTE;
 typedef   void *   LPVOID;
 typedef const char *   LPCSTR;
+#endif

 typedef const LPINT  LPCINT;
 typedef const LPBYTE LPCBYTE ;
--- a/include/tds_sysdep_private.h
+++ b/include/tds_sysdep_private.h
@@ -107,7 +107,7 @@ typedef DWORD pid_t;
 #define TDS_SDIR_SEPARATOR "\\"

 /* use macros to use new style names */
-#if defined(__MSVCRT__) || defined(_MSC_VER)
+#if _MSC_VER > 1200
 #define getpid()   _getpid()
 #define strdup(s)  _strdup(s)
 #undef fileno
--- a/win32/config.h
+++ b/win32/config.h
@@ -89,7 +89,7 @@
 #define HAVE_INT64 1

 /* Define to 1 if you have the  header file. */
-#define HAVE_INTTYPES_H 1
+/* #undef HAVE_INTTYPES_H */

 /* Define to 1 if you have the  header file. */
 #define HAVE_LIMITS_H 1
@@ -281,7 +281,8 @@
 #endif

 #include 
-#include 
+#include 

+#ifndef _SSIZE_T_DEFINED
 typedef SSIZE_T ssize_t;
-
+#endif

--
Dongsheng

On Tue, Jan 25, 2011 at 21:49, Luis Lavena  wrote:

> On Tue, Jan 25, 2011 at 1:21 AM, JonY  wrote:
> >
> > Hi,
> >
> > afaik, mingw.org doesn't have winscard.h, so its not affected.
> > Redefining something that MS has established isn't a good idea at all.
> >
> > I don't think sqlfront.h should be messing with LPCBYTE when its already
> > used by windows headers, even when LEAN_AND_MEAN is in use.
> >
>
> Thank you JonY, already discussed with FreeTDS developers and will
> provide patches to avoid these issues.
>
> Regards,
> --
> Luis Lavena
> AREA 17
> -
> Perfection in design is achieved not when there is nothing more to add,
> but rather when there is nothing more to take away.
> Antoine de Saint-Exupéry
>
>
> --
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Improving evr.h from Windows SDK

[Dongsheng Song]

Hi JonY,

In r4001, you add 'misc/mbwc.c' to mingw-w64-crt/Makefile.am, but I can not
find mbwc.c, only
found misc/mingw_mbwc_convert.c.
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Parma Polyhedra Library 0.11.1

[Dongsheng Song]

On Mon, Feb 21, 2011 at 01:32, Prof. Roberto Bagnara
 wrote:
>
> We announce the availability of PPL 0.11.1, a new release of the Parma
> Polyhedra Library.  This release includes several important bug fixes
> and performance improvements.
>
> The precise list of user-visible changes is available at
>
>    http://www.cs.unipr.it/ppl/Download/ftp/releases/0.11.1/NEWS
>
> For more information, please come and visit the PPL web site at
>
>    http://www.cs.unipr.it/ppl/
>
> On behalf of all the past and present developers listed at
> http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS,
>
> Abramo Bagnara  Roberto Bagnara  Patricia M. Hill  Enea Zaffanella
>
> --
> Prof. Roberto Bagnara                     CEO & CTO
> Applied Formal Methods Laboratory         BUGSENG srl
> Department of Mathematics                 Parco Area delle Scienze 53/A
> University of Parma, Italy                I-43124 Parma, Italy
> http://www.cs.unipr.it/~bagnara/          http://bugseng.com/
> mailto:bagn...@cs.unipr.it                mailto:roberto.bagn...@bugseng.com
>

When I build on i686-w64-mingw32 target:

libtool: compile:  i686-w64-mingw32-g++ -DHAVE_CONFIG_H -I.
-I/home/oracle/src/ppl-0.11.1/src -I.. -I..
-I/home/oracle/src/ppl-0.11.1/src
-I/home/oracle/tmp/gcc-4.5-windows-obj/misc//include -g -O2
-frounding-math -march=x86-64 -O2 -flto -pipe -D_WIN32 -W -Wall -MT
fpu-ia32.lo -MD -MP -MF .deps/fpu-ia32.Tpo -c
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc  -DDLL_EXPORT -DPIC -o
.libs/fpu-ia32.o
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc: In function 'void
Parma_Polyhedra_Library::detect_sse_unit()':
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc:52:7: error: 'NULL' was
not declared in this scope
make[3]: *** [fpu-ia32.lo] Error 1
make[3]: Leaving directory `/tmp/x/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/x/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/x'
make: *** [all] Error 2

Here is my patch:

$ git diff src/fpu-ia32.cc
diff --git a/src/fpu-ia32.cc b/src/fpu-ia32.cc
index d361411..8a2a6a2 100644
--- a/src/fpu-ia32.cc
+++ b/src/fpu-ia32.cc
@@ -30,6 +30,7 @@ site: http://www.cs.unipr.it/ppl/ . */
 #include "fpu.defs.hh"
 #include 
 #include 
+#include 

 namespace {


And I'm doubt the assumption GMP does not support exception when cross
compiling:

$ git diff m4/ac_check_gmp.m4
diff --git a/m4/ac_check_gmp.m4 b/m4/ac_check_gmp.m4
index c5dd1c9..8c2af74 100644
--- a/m4/ac_check_gmp.m4
+++ b/m4/ac_check_gmp.m4
@@ -181,8 +181,8 @@ int main() {
   ac_cv_gmp_supports_exceptions=yes,
   AC_MSG_RESULT(no)
   ac_cv_gmp_supports_exceptions=no,
-  AC_MSG_RESULT([assuming not])
-  ac_cv_gmp_supports_exceptions=no)
+  AC_MSG_RESULT([assuming yes])
+  ac_cv_gmp_supports_exceptions=yes)

 gmp_supports_exceptions=${ac_cv_gmp_supports_exceptions}
 if test x"$gmp_supports_exceptions" = xyes

--
Dongsheng

--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-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] Parma Polyhedra Library 0.11.1

[Dongsheng Song]

On Tue, Feb 22, 2011 at 17:05, Roberto Bagnara  wrote:
>> And I'm doubt the assumption GMP does not support exception when cross
>> compiling:
>>
>> $ git diff m4/ac_check_gmp.m4
>> diff --git a/m4/ac_check_gmp.m4 b/m4/ac_check_gmp.m4
>> index c5dd1c9..8c2af74 100644
>> --- a/m4/ac_check_gmp.m4
>> +++ b/m4/ac_check_gmp.m4
>> @@ -181,8 +181,8 @@ int main() {
>>    ac_cv_gmp_supports_exceptions=yes,
>>    AC_MSG_RESULT(no)
>>    ac_cv_gmp_supports_exceptions=no,
>> -  AC_MSG_RESULT([assuming not])
>> -  ac_cv_gmp_supports_exceptions=no)
>> +  AC_MSG_RESULT([assuming yes])
>> +  ac_cv_gmp_supports_exceptions=yes)
>>
>>  gmp_supports_exceptions=${ac_cv_gmp_supports_exceptions}
>>  if test x"$gmp_supports_exceptions" = xyes
>
> How does this affect you?  I mean, that setting only affects
> the PPL testsuite and if you are cross-compiling you are
> not using it.

But after the configure script done, I got the following warning:

...
config.status: executing libtool commands
configure: WARNING: CANNOT PROPAGATE EXCEPTIONS BACK FROM GMP:
*** MEMORY EXHAUSTION MAY RESULT IN ABRUPT TERMINATION.
*** This is OK, if you do not plan to use the bounded memory capabilities
*** offered by the PPL.  Otherwise, if you are using GCC or the Intel C/C++
*** compiler, please make sure you use a version of GMP compiled with the
*** `-fexceptions' compiler option.
*** To build such a version, you can configure GMP as follows:
*** CPPFLAGS=-fexceptions ./configure --enable-cxx --prefix=/usr/local

Since the most gcc distro already support exceptions at default, so I think
we had better assume gmp support exceptions at default.

--
Dongsheng

--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-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] Parma Polyhedra Library 0.11.1

[Dongsheng Song]

On Tue, Feb 22, 2011 at 17:05, Roberto Bagnara  wrote:
> On 02/22/2011 06:04 AM, Dongsheng Song wrote:
>>
>> When I build on i686-w64-mingw32 target:
>>
>> libtool: compile:  i686-w64-mingw32-g++ -DHAVE_CONFIG_H -I.
>> -I/home/oracle/src/ppl-0.11.1/src -I.. -I..
>> -I/home/oracle/src/ppl-0.11.1/src
>> -I/home/oracle/tmp/gcc-4.5-windows-obj/misc//include -g -O2
>> -frounding-math -march=x86-64 -O2 -flto -pipe -D_WIN32 -W -Wall -MT
>> fpu-ia32.lo -MD -MP -MF .deps/fpu-ia32.Tpo -c
>> /home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc  -DDLL_EXPORT -DPIC -o
>> .libs/fpu-ia32.o
>> /home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc: In function 'void
>> Parma_Polyhedra_Library::detect_sse_unit()':
>> /home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc:52:7: error: 'NULL' was
>> not declared in this scope
>> make[3]: *** [fpu-ia32.lo] Error 1
>> make[3]: Leaving directory `/tmp/x/src'
>> make[2]: *** [all] Error 2
>> make[2]: Leaving directory `/tmp/x/src'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/tmp/x'
>> make: *** [all] Error 2
>>
>> Here is my patch:
>>
>> $ git diff src/fpu-ia32.cc
>> diff --git a/src/fpu-ia32.cc b/src/fpu-ia32.cc
>> index d361411..8a2a6a2 100644
>> --- a/src/fpu-ia32.cc
>> +++ b/src/fpu-ia32.cc
>> @@ -30,6 +30,7 @@ site: http://www.cs.unipr.it/ppl/ . */
>>  #include "fpu.defs.hh"
>>  #include
>>  #include
>> +#include
>>
>>  namespace {
>>
>
> Hi Dongsheng,
>
> I don't see any occurrences of NULL in fpu-ia32.cc.
> Perhaps this is a bug in the  or related header file
> in your system?
>

When I use gcc 4.5 (version 4.5.3 20110221) with mingw-w64 trunk,
after preprocessing, setjmp(env) extend to _setjmp3((env), NULL) .

When I use gcc 4.6 (version 4.6.0 20110221) with mingw-w64 trunk,
after preprocessing, setjmp(env) extend to _setjmp3((env), __null) .

So gcc 4.5 run into trouble, but gcc 4.6 OK.
I don't know why and how to fix in GCC or mingw-w64, but just add
one line '#include' in the source is the simplest way.

--
Dongsheng

--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk 
Collect, index and harness all the fast moving IT data generated by your 
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Bugs in setjmp.h

[Dongsheng Song]

Hi,

Here is the bugs exposed by Parma Polyhedra Library. In setjmp manual, the
only required head
file is setjmp.h, but mingw-w64 is not the case, here is a example:


$ cat have_sse.c
#include 
#include 

jmp_buf env;
int have_sse_unit = 1;

void illegal_instruction_catcher(int ignore) {
  signal(SIGILL, SIG_DFL);
  longjmp(env, 1);
}

inline unsigned int sse_get_control() {
  unsigned int cw;
  __asm__ __volatile__ ("stmxcsr %0" : "=m" (*&cw) : : "memory");
  return cw;
}

void detect_sse_unit() {
  if (setjmp(env)) {
have_sse_unit = 0;
goto restore_sigill_handler;
  }

  signal(SIGILL, illegal_instruction_catcher);
  (void) sse_get_control();
  have_sse_unit = 1;

  restore_sigill_handler:

  signal(SIGILL, SIG_DFL);
}

int main(int argc, char *argv[]) {
  detect_sse_unit();
  return have_sse_unit;
}

This C source file can be compiled by Linux gcc 4.4.5,
MS VC2008, MS VC2010, but can not be compiled by
mingw-w64 target gcc 4.5 and 4.6:

oracle@vc:~$ ./gcc-4.6-windows_i686-linux/bin/i686-w64-mingw32-gcc
have_sse.c
have_sse.c: In function 'detect_sse_unit':
have_sse.c:25:7: error: 'NULL' undeclared (first use in this function)
have_sse.c:25:7: note: each undeclared identifier is reported only once for
each function it appears in

oracle@vc:~$ ./gcc-4.5-windows_i686-linux/bin/i686-w64-mingw32-gcc
have_sse.c
have_sse.c: In function 'detect_sse_unit':
have_sse.c:25:7: error: 'NULL' undeclared (first use in this function)
have_sse.c:25:7: note: each undeclared identifier is reported only once for
each function it appears in

--
Dongsheng
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-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] Bugs in setjmp.h

[Dongsheng Song]

Sorry, here is the update source can be compiled by MS VC:

$ cat have_sse.c
#include 
#include 

jmp_buf env;
int have_sse_unit = 1;

void illegal_instruction_catcher(int ignore) {
  signal(SIGILL, SIG_DFL);
  longjmp(env, 1);
}

unsigned int sse_get_control() {
  unsigned int cw;
#ifdef _MSC_VER
  __asm {
stmxcsr cw
  }
#else
  __asm__ __volatile__ ("stmxcsr %0" : "=m" (*&cw) : : "memory");
#endif
  return cw;
}

void detect_sse_unit() {
  if (setjmp(env)) {
have_sse_unit = 0;
goto restore_sigill_handler;
  }

  signal(SIGILL, illegal_instruction_catcher);
  (void) sse_get_control();
  have_sse_unit = 1;

  restore_sigill_handler:

  signal(SIGILL, SIG_DFL);
}

int main(int argc, char *argv[]) {
  detect_sse_unit();
  return have_sse_unit;
}

On Wed, Feb 23, 2011 at 11:17, Dongsheng Song wrote:

> Hi,
>
> Here is the bugs exposed by Parma Polyhedra Library. In setjmp manual, the
> only required head
> file is setjmp.h, but mingw-w64 is not the case, here is a example:
>
>
> $ cat have_sse.c
> #include 
> #include 
>
> jmp_buf env;
> int have_sse_unit = 1;
>
> void illegal_instruction_catcher(int ignore) {
>   signal(SIGILL, SIG_DFL);
>   longjmp(env, 1);
> }
>
> inline unsigned int sse_get_control() {
>   unsigned int cw;
>   __asm__ __volatile__ ("stmxcsr %0" : "=m" (*&cw) : : "memory");
>   return cw;
> }
>
> void detect_sse_unit() {
>   if (setjmp(env)) {
> have_sse_unit = 0;
> goto restore_sigill_handler;
>   }
>
>   signal(SIGILL, illegal_instruction_catcher);
>   (void) sse_get_control();
>   have_sse_unit = 1;
>
>   restore_sigill_handler:
>
>   signal(SIGILL, SIG_DFL);
> }
>
> int main(int argc, char *argv[]) {
>   detect_sse_unit();
>   return have_sse_unit;
> }
>
> This C source file can be compiled by Linux gcc 4.4.5,
> MS VC2008, MS VC2010, but can not be compiled by
> mingw-w64 target gcc 4.5 and 4.6:
>
> oracle@vc:~$ ./gcc-4.6-windows_i686-linux/bin/i686-w64-mingw32-gcc
> have_sse.c
> have_sse.c: In function 'detect_sse_unit':
> have_sse.c:25:7: error: 'NULL' undeclared (first use in this function)
> have_sse.c:25:7: note: each undeclared identifier is reported only once for
> each function it appears in
>
> oracle@vc:~$ ./gcc-4.5-windows_i686-linux/bin/i686-w64-mingw32-gcc
> have_sse.c
> have_sse.c: In function 'detect_sse_unit':
> have_sse.c:25:7: error: 'NULL' undeclared (first use in this function)
> have_sse.c:25:7: note: each undeclared identifier is reported only once for
> each function it appears in
>
> --
> Dongsheng
>
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-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] Bugs in setjmp.h

[Dongsheng Song]

On Wed, Feb 23, 2011 at 16:20, Kai Tietz  wrote:

> 2011/2/23 Dongsheng Song :
> > Sorry, here is the update source can be compiled by MS VC:
> >
> > $ cat have_sse.c
> > #include 
> > #include 
> >
> > jmp_buf env;
> > int have_sse_unit = 1;
> >
> > void illegal_instruction_catcher(int ignore) {
> >   signal(SIGILL, SIG_DFL);
> >   longjmp(env, 1);
> > }
> >
> > unsigned int sse_get_control() {
> >   unsigned int cw;
> > #ifdef _MSC_VER
> >   __asm {
> > stmxcsr cw
> >   }
> > #else
> >   __asm__ __volatile__ ("stmxcsr %0" : "=m" (*&cw) : : "memory");
> > #endif
> >   return cw;
> > }
> >
> > void detect_sse_unit() {
> >   if (setjmp(env)) {
> > have_sse_unit = 0;
> > goto restore_sigill_handler;
> >   }
> >
> >   signal(SIGILL, illegal_instruction_catcher);
> >   (void) sse_get_control();
> >   have_sse_unit = 1;
> >
> >   restore_sigill_handler:
> >
> >   signal(SIGILL, SIG_DFL);
> > }
> >
> > int main(int argc, char *argv[]) {
> >   detect_sse_unit();
> >   return have_sse_unit;
> > }
> >
> > On Wed, Feb 23, 2011 at 11:17, Dongsheng Song 
> > wrote:
> >>
> >> Hi,
> >>
> >> Here is the bugs exposed by Parma Polyhedra Library. In setjmp manual,
> the
> >> only required head
> >> file is setjmp.h, but mingw-w64 is not the case, here is a example:
> >>
> >>
> >> $ cat have_sse.c
> >> #include 
> >> #include 
> >>
> >> jmp_buf env;
> >> int have_sse_unit = 1;
> >>
> >> void illegal_instruction_catcher(int ignore) {
> >>   signal(SIGILL, SIG_DFL);
> >>   longjmp(env, 1);
> >> }
> >>
> >> inline unsigned int sse_get_control() {
> >>   unsigned int cw;
> >>   __asm__ __volatile__ ("stmxcsr %0" : "=m" (*&cw) : : "memory");
> >>   return cw;
> >> }
> >>
> >> void detect_sse_unit() {
> >>   if (setjmp(env)) {
> >> have_sse_unit = 0;
> >> goto restore_sigill_handler;
> >>   }
> >>
> >>   signal(SIGILL, illegal_instruction_catcher);
> >>   (void) sse_get_control();
> >>   have_sse_unit = 1;
> >>
> >>   restore_sigill_handler:
> >>
> >>   signal(SIGILL, SIG_DFL);
> >> }
> >>
> >> int main(int argc, char *argv[]) {
> >>   detect_sse_unit();
> >>   return have_sse_unit;
> >> }
> >>
> >> This C source file can be compiled by Linux gcc 4.4.5,
> >> MS VC2008, MS VC2010, but can not be compiled by
> >> mingw-w64 target gcc 4.5 and 4.6:
> >>
> >> oracle@vc:~$ ./gcc-4.6-windows_i686-linux/bin/i686-w64-mingw32-gcc
> >> have_sse.c
> >> have_sse.c: In function 'detect_sse_unit':
> >> have_sse.c:25:7: error: 'NULL' undeclared (first use in this function)
> >> have_sse.c:25:7: note: each undeclared identifier is reported only once
> >> for each function it appears in
> >>
> >> oracle@vc:~$ ./gcc-4.5-windows_i686-linux/bin/i686-w64-mingw32-gcc
> >> have_sse.c
> >> have_sse.c: In function 'detect_sse_unit':
> >> have_sse.c:25:7: error: 'NULL' undeclared (first use in this function)
> >> have_sse.c:25:7: note: each undeclared identifier is reported only once
> >> for each function it appears in
> >>
> >> --
> >> Dongsheng
>
> Hmm, that NULL isn't defined is the issue. So it looks for me more
> like a missing header include of stddef.h, or stdlib.h.
>

Yes, but since Linux GCC and MS VC no need include the extra header files, I
think
this should consider a bug, and it seems that PPL (Parma Polyhedra Library)
maintainer do not want add extra C++ header cstddef, mingw-w64 should add
the
extra header file in setjmp.h

--
Dongsheng
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-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] Bugs in setjmp.h

[Dongsheng Song]

On Wed, Feb 23, 2011 at 17:20, Kai Tietz  wrote:

>  >> Hmm, that NULL isn't defined is the issue. So it looks for me more
> >> like a missing header include of stddef.h, or stdlib.h.
> >
> > Yes, but since Linux GCC and MS VC no need include the extra header
> files, I
> > think
> > this should consider a bug, and it seems that PPL (Parma Polyhedra
> Library)
> > maintainer do not want add extra C++ header cstddef, mingw-w64 should add
> > the
> > extra header file in setjmp.h
> >
> > --
> > Dongsheng
> >
> >
>
> Hmm, maybe. Could you check if on glibc the setjmp.h header has
> dependencies to stdlib, or stddef.h?
>
>
No, setjmp.h on glibc is:

extern int setjmp (jmp_buf __env) __THROW;

But mingw-w64 is:

#define setjmp(BUF) _setjmp3((BUF), NULL)

So this is mingw-w64 specific issue, glibc no such issue.

--
Dongsheng
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-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] why aren't "secure" _s functions provided?

[Dongsheng Song]

On Wed, Mar 9, 2011 at 03:32, Dock, Dion  wrote:

>
> I'm back to my original question: can I use MinGW64 with source that has
> functions like strnlen_s?
>
> It sounds like the answer is: I can compile code with those functions in a
> DLL with a manifest for msvcr80 (or 90 or 100) or statically link the
> runtime into that DLL.  However, I cannot compile code with those functions
> using MinGW64.
>
> Or to put it another way, how would you get this to compile with MinGW64?
>#include 
>#include 
>
>int main()
>{
>   printf("%d\n", strnlen_s("foo", 2)); /* expect 2 */
>   return 0;
>}
>
> Here's what I get:
> C:\Temp>C:\mingw_32\bin\i686-w64-mingw32-gcc.exe main.c
> C:\Users\dockd\AppData\Local\Temp\ccKqFt47.o:main.c:(.text+0x1e): undefined
> reference to `strnlen_s'
> collect2: ld returned 1 exit status
>
> -Dion
>

It seems that you can compile your program, so you can copy msvcr100.dll to
libmsvcrt.a, it should works fine.
Or link with: gcc test.c -lmsvcr100

But I checked the functions in msvcr100.dll, no strnlen_s, only have the
following string functions:

strcat_s
strcpy_s
_strdate_s
_strerror_s
strerror_s
_strlwr_s
strncat_s
strncpy_s
_strnset_s
_strset_s
_strtime_s
strtok_s
_strupr_s

When I check VC 10, I found it's a inline function:

#if __STDC_WANT_SECURE_LIB__ && !defined (__midl)
_Check_return_ static __inline size_t  __CRTDECL strnlen_s(_In_z_  const
char * _Str, _In_ size_t _MaxCount)
{
return (_Str==0) ? 0 : strnlen(_Str, _MaxCount);
}

_Check_return_ static __inline size_t __CRTDECL wcsnlen_s(_In_z_ const
wchar_t * _Src, _In_ size_t _MaxCount)
{
return (_Src == NULL) ? 0 : wcsnlen(_Src, _MaxCount);
}
#endif

So if you want use "secure" _s functions, you can link with -lmsvcr100, but
please do not use strnlen_s/wcsnlen_s,
or you must define your self.

--
Dongsheng
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] why aren't "secure" _s functions provided?

[Dongsheng Song]

On Thu, Mar 10, 2011 at 09:07, Dock, Dion  wrote:

> How did you do that?  nm isn't displaying those functions in my preferred
> runtime lib, libmsvcr80.a.  For example,
>   C:\Temp>C:\mingw_32\bin\i686-w64-mingw32-nm.exe
> C:\mingw_32\mingw\lib\libmsvcr80.a | find "strcpy_s"
>   C:\Temp>
>

You can use gendef [1, 2] to generate .def file from .dll file.

[1]
https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk/mingw-w64-tools/gendef
[2] http://i18n-zh.googlecode.com/files/gendef-r3706.exe



>
> Thanks!  Adding the "-lmsvcr80" resolved a few of the symbols.  Now I've
> hit the next stumbling block: vsnprintf_s and localtime32_s.
>
> These don't seem to be in libmsvcr80.a, but per the above, I'm not sure how
> to check for their presence.  Neither is a macro, however.
>
>
In  msvcr80.dll, here is thess function names list:

_localtime32_s
_vsnprintf_s
_vsnprintf_s_l
strcpy_s

So you must use vsnprintf_s and localtime32_s with prefix '_', as ms vc
declared:
_CRTIMP errno_t __cdecl _localtime32_s(_Out_ struct tm *_Tm, _In_ const
__time32_t * _Time);
_Check_return_opt_ _CRTIMP_ALTERNATIVE int __cdecl
_vsnprintf_s(_Out_z_cap_(_SizeInBytes) char * _DstBuf, _In_ size_t
_SizeInBytes, _In_ size_t _MaxCount, _In_z_ _Printf_format_string_ const
char * _Format, va_list _ArgList);

But in the w64 repository, no such symbols:

$ grep -E "vsnprintf|localtime" msvcr80.def
_vsnprintf
localtime DATA
;_localtime32 = localtime
_localtime64

So you must add these symbols yourself, then rebuild libmsvcr80.a; or you
can simply copy msvcr80.dll to libmsvcr80.a.

@Kai, could you rebuild msvcr*.def from msvcr*.dll ?

--
Dongsheng
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] why aren't "secure" _s functions provided?

[Dongsheng Song]

On Fri, Mar 11, 2011 at 09:34, Dock, Dion  wrote:
> I'm still flailing around with this.
>
> C:\Temp>more dion.c
> #include 
> #include 
>
> int main()
> {
>   struct tm aTm;
>   int err = 0;
>   __time32_t time;
>
>   _time32(&time);
>   err = _localtime32_s(&aTm, &time);
>
>   return 0;
> }
>
> DION: defaults don't work
> C:\Temp>C:\mingw_32\bin\i686-w64-mingw32-gcc.exe dion.c
> C:\Users\dockd\AppData\Local\Temp\ccoRa8Cv.o:dion.c:(.text+0x3a): undefined 
> reference to `_localtime32_s'
> collect2: ld returned 1 exit status
>
> DION: try the VS 2005 version of the C runtime
> C:\Temp>C:\mingw_32\bin\i686-w64-mingw32-gcc.exe dion.c -lmsvcr80
> C:\Users\dockd\AppData\Local\Temp\cckwwBoL.o:dion.c:(.text+0x3a): undefined 
> reference to `_localtime32_s'
> collect2: ld returned 1 exit status
>
> DION: try creating my own version of the C runtime
> C:\Temp>C:\mingw_32\bin\i686-w64-mingw32-dlltool.exe -D "C:\Program Files 
> (x86)\
> Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT\msvcr80.dll" -d 
> msvcr80.def -l libmsvcr80.a
> C:\mingw_32\bin\i686-w64-mingw32-dlltool.exe: Path components stripped from 
> dllname, 'C:\Program Files (x86)\Microsoft Visual Studio 
> 8\VC\redist\x86\Microsoft.VC80.CRT\msvcm80.dll'.
>
> C:\Temp>C:\mingw_32\bin\i686-w64-mingw32-gcc.exe dion.c libmsvcr80.a
> c:/mingw_32/bin/../lib/gcc/i686-w64-mingw32/4.5.2/../../../../i686-w64-mingw32/lib/libmingw32.a(lib32_libmingw32_a-mingw_helpers.o):
>  In function `encode_pointer':
> c:\bb\vista64-mingw32\mingw-x86-x86\build\build\mingw\obj/../../../build/mingw/mingw-w64-crt/crt/mingw_helpers.c:26:
>  multiple definition of `_encode_pointer'
> libmsvcr80.a(dqmlfs00370.o):(.text+0x0): first defined here
> collect2: ld returned 1 exit status
>

Why not try my suggestion ?
> > So you must add these symbols yourself, then rebuild libmsvcr80.a; or you 
> > can simply copy msvcr80.dll to libmsvcr80.a.

Here is another approach:

C:\var\tmp>more test.c
#include 
#include 

int main()
{
  struct tm aTm;
  int err = 0;
  __time32_t time;

  _time32(&time);
  err = _localtime32_s(&aTm, &time);

  return 0;
}

C:\var\tmp>gcc test.c C:\WINDOWS\system32\msvcr100.dll
C:\var\tmp>a
C:\var\tmp>

--
Dongsheng

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Mark msvcr100 functions which also provide by libmingwex by DATA

[Dongsheng Song]

Hi,

Thers have 70 functions both in libmingwex and 64 bit msvcr100.dll,
51 functions both in libmingwex and 32 bit msvcr100.dll, all of them
should mark by DATA.

PS: I'm using VS 2010 SP1 runtime to generate the .DEF files.

--
Dongsheng
Index: trunk/mingw-w64-crt/lib64/msvcr100.def
===
--- trunk/mingw-w64-crt/lib64/msvcr100.def  (revision 4067)
+++ trunk/mingw-w64-crt/lib64/msvcr100.def  (working copy)
@@ -1,9 +1,9 @@
 ;
-; Definition file of MSVCR100.dll
+; Definition file of msvcr100.dll
 ; Automatic generated by gendef
 ; written by Kai Tietz 2008
 ;
-LIBRARY "MSVCR100.dll"
+LIBRARY "msvcr100.dll"
 EXPORTS
 $I10_OUTPUT
 ; public: __cdecl Concurrency::details::<0x1ULL>::<0x1ULL>(void(__cdecl 
*)(void))__ptr64 
@@ -648,7 +648,7 @@
 __pioinfo DATA
 __pwctype_func
 __pxcptinfoptrs
-__report_gsfailure
+__report_gsfailure DATA
 __set_app_type
 __set_flsgetvalue
 __setlc_active DATA
@@ -686,7 +686,7 @@
 _aligned_realloc
 _aligned_recalloc
 _amsg_exit
-_assert
+_assert DATA
 _atodbl
 _atodbl_l
 _atof_l
@@ -701,9 +701,9 @@
 _beep
 _beginthread
 _beginthreadex
-_byteswap_uint64
-_byteswap_ulong
-_byteswap_ushort
+_byteswap_uint64 DATA
+_byteswap_ulong DATA
+_byteswap_ushort DATA
 _c_exit
 _cabs
 _callnewh
@@ -744,7 +744,7 @@
 _cscanf_l
 _cscanf_s
 _cscanf_s_l
-_ctime32
+_ctime32 DATA
 _ctime32_s
 _ctime64
 _ctime64_s
@@ -760,8 +760,8 @@
 _cwscanf_s
 _cwscanf_s_l
 _daylight DATA
-_difftime32
-_difftime64
+_difftime32 DATA
+_difftime64 DATA
 _dosmaperr
 _dstbias DATA
 _dup
@@ -802,11 +802,11 @@
 _findfirst32
 _findfirst32i64
 _findfirst64
-_findfirst64i32
+_findfirst64i32 DATA
 _findnext32
 _findnext32i64
 _findnext64
-_findnext64i32
+_findnext64i32 DATA
 _finite
 _finitef
 _flsbuf
@@ -815,7 +815,7 @@
 _fpclass
 _fpclassf
 _fpieee_flt
-_fpreset
+_fpreset DATA
 _fprintf_l
 _fprintf_p
 _fprintf_p_l
@@ -832,15 +832,15 @@
 _fscanf_l
 _fscanf_s_l
 _fseek_nolock
-_fseeki64
+_fseeki64 DATA
 _fseeki64_nolock
 _fsopen
 _fstat32
 _fstat32i64
 _fstat64
-_fstat64i32
+_fstat64i32 DATA
 _ftell_nolock
-_ftelli64
+_ftelli64 DATA
 _ftelli64_nolock
 _ftime32
 _ftime32_s
@@ -862,7 +862,7 @@
 _get_daylight
 _get_doserrno
 _get_dstbias
-_get_errno
+_get_errno DATA
 _get_fmode
 _get_heap_handle
 _get_invalid_parameter_handler
@@ -900,7 +900,7 @@
 _getwche_nolock
 _getws
 _getws_s
-_gmtime32
+_gmtime32 DATA
 _gmtime32_s
 _gmtime64
 _gmtime64_s
@@ -1025,7 +1025,7 @@
 _lfind_s
 _loaddll
 _local_unwind
-_localtime32
+_localtime32 DATA
 _localtime32_s
 _localtime64
 _localtime64_s
@@ -1187,11 +1187,11 @@
 _memicmp
 _memicmp_l
 _mkdir
-_mkgmtime32
+_mkgmtime32 DATA
 _mkgmtime64
 _mktemp
 _mktemp_s
-_mktime32
+_mktime32 DATA
 _mktime64
 _msize
 _nextafter
@@ -1226,9 +1226,9 @@
 _rmdir
 _rmtmp
 _rotl
-_rotl64
+_rotl64 DATA
 _rotr
-_rotr64
+_rotr64 DATA
 _scalb
 _scalbf
 _scanf_l
@@ -1246,7 +1246,7 @@
 _set_abort_behavior
 _set_controlfp
 _set_doserrno
-_set_errno
+_set_errno DATA
 _set_error_mode
 _set_fmode
 _set_invalid_parameter_handler
@@ -1301,7 +1301,7 @@
 _stat32
 _stat32i64
 _stat64
-_stat64i32
+_stat64i32 DATA
 _statusfp
 _strcoll_l
 _strdate
@@ -1357,7 +1357,7 @@
 _tell
 _telli64
 _tempnam
-_time32
+_time32 DATA
 _time64
 _timezone DATA
 _tolower
@@ -1451,7 +1451,7 @@
 _waccess_s
 _wasctime
 _wasctime_s
-_wassert
+_wassert DATA
 _wchdir
 _wchmod
 _wcmdln DATA
@@ -1494,7 +1494,7 @@
 _wcsupr_s
 _wcsupr_s_l
 _wcsxfrm_l
-_wctime32
+_wctime32 DATA
 _wctime32_s
 _wctime64
 _wctime64_s
@@ -1515,11 +1515,11 @@
 _wfindfirst32
 _wfindfirst32i64
 _wfindfirst64
-_wfindfirst64i32
+_wfindfirst64i32 DATA
 _wfindnext32
 _wfindnext32i64
 _wfindnext64
-_wfindnext64i32
+_wfindnext64i32 DATA
 _wfopen
 _wfopen_s
 _wfreopen
@@ -1570,7 +1570,7 @@
 _wstat32
 _wstat32i64
 _wstat64
-_wstat64i32
+_wstat64i32 DATA
 _wstrdate
 _wstrdate_s
 _wstrtime
@@ -1596,37 +1596,37 @@
 abort
 abs
 acos
-acosf
+acosf DATA
 asctime
 asctime_s
 asin
-asinf
+asinf DATA
 atan
 atan2
-atan2f
-atanf
-atexit
+atan2f DATA
+atanf DATA
+atexit DATA
 atof
 atoi
 atol
 bsearch
 bsearch_s
-btowc
+btowc DATA
 calloc
 ceil
-ceilf
+ceilf DATA
 clearerr
 clearerr_s
 clock
-cos
-cosf
+cos DATA
+cosf DATA
 cosh
-coshf
+coshf DATA
 div
 exit
-exp
-expf
-fabs
+exp DATA
+expf DATA
+fabs DATA
 fclose
 feof
 ferror
@@ -1637,9 +1637,9 @@
 fgetwc
 fgetws
 floor
-floorf
-fmod
-fmodf
+floorf DATA
+fmod DATA
+fmodf DATA
 fopen
 fopen_s
 fprintf
@@ -1701,19 +1701,19 @@
 labs
 ldexp
 ldiv
-llabs
-lldiv
+llabs DATA
+lldiv DATA
 localeconv
-log
+log DATA
 log10
-log10f
-logf
+log10f DATA
+logf DATA
 longjmp DATA
 malloc
 mblen
-mbrlen
-mbrtowc
-mbsrtowcs
+mbrlen DATA
+mbrtowc DATA
+mbsrtowcs DATA
 mbsrtowcs_s
 mbstowcs
 mbstowcs_s
@@ -1725,11 +1725,11 @@
 memmove
 memmove_s
 memset
-modf
-modff
+modf DATA
+modff DATA
 perror
-pow
-powf
+pow DATA
+powf DATA
 printf
 printf_s
 putc
@@ -1753,14 +1753,14 @@
 setlocale
 setvbuf
 signal
-sin
-sinf
+sin DATA
+sinf DATA
 sinh
-sinhf
+sinhf DATA
 sprintf
 sprintf_s
-sqrt
-sqrtf
+sqrt DATA
+sqr

Re: [Mingw-w64-public] [PATCH] Mark msvcr100 functions which also provide by libmingwex by DATA

[Dongsheng Song]

On Sat, Mar 12, 2011 at 20:29, Kai Tietz  wrote:
> 2011/3/12 Dongsheng Song :
>> Hi,
>>
>> Thers have 70 functions both in libmingwex and 64 bit msvcr100.dll,
>> 51 functions both in libmingwex and 32 bit msvcr100.dll, all of them
>> should mark by DATA.
>>
>> PS: I'm using VS 2010 SP1 runtime to generate the .DEF files.
>>
>> --
>> Dongsheng
>
> Thanks, patch is ok for apply. Could you provide a ChangeLog entry to
> be used for commit?
>
> Regards,
> Kai
>

OK, here it is:

[[[
2010-11-26  Dongsheng Song :
  * lib32/msvcrt.def (__report_gsfailure, _assert, _byteswap_uint64,
_byteswap_ulong, _byteswap_ushort, _ctime32, _difftime32,
_difftime64, _findfirst64i32, _findnext64i32, _fpreset, _fseeki64,
_fstat64i32, _ftelli64, _get_errno, _gmtime32, _localtime32,
_mkgmtime32, _mktime32, _rotl64, _rotr64, _set_errno, _stat64i32,
_time32, _wassert, _wctime32, _wfindfirst64i32, _wfindnext64i32,
_wstat64i32, atexit, btowc, cos, exp, fabs, fmod, llabs, lldiv,
log, longjmp, mbrlen, mbrtowc, mbsrtowcs, modf, pow, sin, sqrt,
strnlen, wcrtomb, wcsnlen, wcsrtombs, wctob): Mark as DATA.

  * lib64/msvcrt.def (__report_gsfailure, _assert, _byteswap_uint64,
_byteswap_ulong, _byteswap_ushort, _ctime32, _difftime32,
_difftime64, _findfirst64i32, _findnext64i32, _fpreset, _fseeki64,
_fstat64i32, _ftelli64, _get_errno, _gmtime32, _localtime32,
_mkgmtime32, _mktime32, _rotl64, _rotr64, _set_errno, _stat64i32,
_time32, _wassert, _wctime32, _wfindfirst64i32, _wfindnext64i32,
_wstat64i32, acosf, asinf, atan2f, atanf, atexit, btowc, ceilf,
cos, cosf, coshf, exp, expf, fabs, floorf, fmod, fmodf, llabs,
lldiv, log, log10f, logf, longjmp, mbrlen, mbrtowc, mbsrtowcs,
modf, modff, pow, powf, sin, sinf, sinhf, sqrt, sqrtf, strnlen,
tanf, tanhf, wcrtomb, wcsnlen, wcsrtombs, wctob): Likewise.
]]]

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
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] Mark msvcr100 functions which also provide by libmingwex by DATA

[Dongsheng Song]

On Sat, Mar 12, 2011 at 22:02, Dongsheng Song  wrote:
> On Sat, Mar 12, 2011 at 20:29, Kai Tietz  wrote:
>> 2011/3/12 Dongsheng Song :
>>> Hi,
>>>
>>> Thers have 70 functions both in libmingwex and 64 bit msvcr100.dll,
>>> 51 functions both in libmingwex and 32 bit msvcr100.dll, all of them
>>> should mark by DATA.
>>>
>>> PS: I'm using VS 2010 SP1 runtime to generate the .DEF files.
>>>
>>> --
>>> Dongsheng
>>
>> Thanks, patch is ok for apply. Could you provide a ChangeLog entry to
>> be used for commit?
>>
>> Regards,
>> Kai
>>
>
> OK, here it is:
>
> [[[
> 2010-11-26  Dongsheng Song :
>  * lib32/msvcrt.def (__report_gsfailure, _assert, _byteswap_uint64,
>    _byteswap_ulong, _byteswap_ushort, _ctime32, _difftime32,
>    _difftime64, _findfirst64i32, _findnext64i32, _fpreset, _fseeki64,
>    _fstat64i32, _ftelli64, _get_errno, _gmtime32, _localtime32,
>    _mkgmtime32, _mktime32, _rotl64, _rotr64, _set_errno, _stat64i32,
>    _time32, _wassert, _wctime32, _wfindfirst64i32, _wfindnext64i32,
>    _wstat64i32, atexit, btowc, cos, exp, fabs, fmod, llabs, lldiv,
>    log, longjmp, mbrlen, mbrtowc, mbsrtowcs, modf, pow, sin, sqrt,
>    strnlen, wcrtomb, wcsnlen, wcsrtombs, wctob): Mark as DATA.
>
>  * lib64/msvcrt.def (__report_gsfailure, _assert, _byteswap_uint64,
>    _byteswap_ulong, _byteswap_ushort, _ctime32, _difftime32,
>    _difftime64, _findfirst64i32, _findnext64i32, _fpreset, _fseeki64,
>    _fstat64i32, _ftelli64, _get_errno, _gmtime32, _localtime32,
>    _mkgmtime32, _mktime32, _rotl64, _rotr64, _set_errno, _stat64i32,
>    _time32, _wassert, _wctime32, _wfindfirst64i32, _wfindnext64i32,
>    _wstat64i32, acosf, asinf, atan2f, atanf, atexit, btowc, ceilf,
>    cos, cosf, coshf, exp, expf, fabs, floorf, fmod, fmodf, llabs,
>    lldiv, log, log10f, logf, longjmp, mbrlen, mbrtowc, mbsrtowcs,
>    modf, modff, pow, powf, sin, sinf, sinhf, sqrt, sqrtf, strnlen,
>    tanf, tanhf, wcrtomb, wcsnlen, wcsrtombs, wctob): Likewise.
> ]]]
>

Sorry for typo, s/msvcrt.def/msvcrt100.def/g

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Rubenvb 4.6.1 (prerelease) x86_64 personal build

[Dongsheng Song]

On Sun, May 8, 2011 at 17:47, Ruben Van Boxem wrote:

> I have released an update to my 4.6.1 prerelease toolchain.
> 1. linking code with lto using the "-flto" switch crashes ld. Trunk
> crashes, 2.21 as well, 2.20 complains about not being compiled with
> "--enable-plugins", but can't be compiled with plugin support on Windows. I
> suppose this was solved in later versions, but lto still crashes ld.exe.
>

Same for me.
http://sourceware.org/bugzilla/show_bug.cgi?id=12693


> 2. Multilib is still broken;
>a) all runtime libs except libstdc++ don't have their dll's installed in
> the architecture specific directory.
>b) When building a x64 hosted toolchain, make install installs the
> 32-bit dll's into the main bin directory after it has installed the 64-bit
> versions, making the install completely useless, as the 64-bit apps can't
> find their shared libraries. This is only a matter of switching the install
> order.
>

Yes, but you can correct it manually.
Here is my multilib build:

http://code.google.com/p/i18n-zh/downloads/list
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Qt-interest] Rubenvb 4.6.1 (prerelease) x86_64 personal build

[Dongsheng Song]

On Tue, May 10, 2011 at 15:25, Kai Tietz  wrote:
> Hmm, is it possible to get a stack-trace for ld's plugin crash? This
> might be pretty helpful to know at what point it crashes.   As I don't
> see this issue I assume it is mingw-.host only related, so a
> stack-trace would be kind.
>
> Regards,
> Kai

The stack trace already in the bug report:
http://sourceware.org/bugzilla/show_bug.cgi?id=12693

But I'm not check later to see if it still exists or the behavior changed.

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Mark msvcr90 functions which also provide in libmingwex by DATA

[Dongsheng Song]

Hi,

There have 69 functions both in libmingwex and 64 bit msvcr90.dll,
50 functions both in libmingwex and 32 bit msvcr90.dll, all of them
should mark by DATA.

PS: I'm using VS 2008 SP1 runtime to generate the .DEF files.

 ChangeLog |   22 
 lib32/msvcr90.def |  122 +++---
 lib64/msvcr90.def |  142 +++---
 3 files changed, 154 insertions(+), 132 deletions(-)

--
Dongsheng
Index: ChangeLog
===
--- ChangeLog   (revision 4169)
+++ ChangeLog   (working copy)
@@ -1,3 +1,25 @@
+2011-05-19  Dongsheng Song  :
+
+   * lib32/msvcr90.def (__report_gsfailure, _assert, _byteswap_uint64,
+   _byteswap_ulong, _byteswap_ushort, _ctime32, _decode_pointer, 
_difftime32,
+   _difftime64, _encode_pointer, _findfirst64i32, _findnext64i32, _fpreset,
+   _fseeki64, _fstat64i32, _ftelli64, _get_errno, _gmtime32, _localtime32,
+   _mkgmtime32, _mktime32, _rotl64, _rotr64, _set_errno, _stat64i32, 
_time32,
+   _wassert, _wctime32, _wfindfirst64i32, _wfindnext64i32, _wstat64i32, 
atexit,
+   btowc, cos, exp, fabs, fmod, log, mbrlen, mbrtowc, mbsrtowcs, modf, 
pow, sin,
+   sqrt, strnlen, wcrtomb, wcsnlen, wcsrtombs, wctob): Mark as DATA.
+
+   * lib64/msvcr90.def (__report_gsfailure, _assert, _byteswap_uint64,
+   _byteswap_ulong, _byteswap_ushort, _ctime32, _decode_pointer, 
_difftime32,
+   _difftime64, _encode_pointer, _findfirst64i32, _findnext64i32, _fpreset,
+   _fseeki64, _fstat64i32, _ftelli64, _get_errno, _gmtime32, _localtime32,
+   _mkgmtime32, _mktime32, _rotl64, _rotr64, _set_errno, _stat64i32, 
_time32,
+   _wassert, _wctime32, _wfindfirst64i32, _wfindnext64i32, _wstat64i32, 
acosf,
+   asinf, atan2f, atanf, atexit, btowc, ceilf, cos, cosf, coshf, exp, expf,
+   fabs, floorf, fmod, fmodf, log, log10f, logf, mbrlen, mbrtowc, 
mbsrtowcs,
+   modf, modff, pow, powf, sin, sinf, sinhf, sqrt, sqrtf, strnlen, tanf, 
tanhf,
+   wcrtomb, wcsnlen, wcsrtombs, wctob): Likewise.
+
 2011-04-30  Ozkan Sezer  
 
* lib32/winscard.def (g_rgSCardRawPci): Remove stdcall suffix and
Index: lib32/msvcr90.def
===
--- lib32/msvcr90.def   (revision 4169)
+++ lib32/msvcr90.def   (working copy)
@@ -1,9 +1,9 @@
 ;
-; Definition file of MSVCR90.dll
+; Definition file of msvcr90.dll
 ; Automatic generated by gendef
 ; written by Kai Tietz 2008
 ;
-LIBRARY "MSVCR90.dll"
+LIBRARY "msvcr90.dll"
 EXPORTS
 ; public: __thiscall std::__non_rtti_object::__non_rtti_object(class 
std::__non_rtti_object const &)
 ??0__non_rtti_object@std@@QAE@ABV01@@Z ; has WINAPI (@4)
@@ -87,7 +87,7 @@
 ?_ValidateWrite@@YAHPAXI@Z
 __uncaught_exception
 ; void __cdecl _inconsistency(void)
-?_inconsistency@@YAXXZ ; Check!!! Couldn't determine function argument count. 
Function doesn't return. 
+?_inconsistency@@YAXXZ
 ; void __cdecl _invalid_parameter(unsigned short const *,unsigned short const 
*,unsigned short const *,unsigned int,unsigned int)
 ?_invalid_parameter@@YAXPBG00II@Z
 ; int __cdecl _is_exception_typeof(class type_info const &,struct 
_EXCEPTION_POINTERS *)
@@ -299,7 +299,7 @@
 __pioinfo DATA
 __pwctype_func
 __pxcptinfoptrs
-__report_gsfailure
+__report_gsfailure DATA
 __set_app_type
 __set_flsgetvalue
 __setlc_active DATA
@@ -308,8 +308,8 @@
 __swprintf_l
 __sys_errlist
 __sys_nerr
-__threadhandle@0
-__threadid@0
+__threadhandle
+__threadid
 __timezone
 __toascii
 __tzname
@@ -333,7 +333,7 @@
 _adj_fdiv_m32@4
 _adj_fdiv_m32i@4
 _adj_fdiv_m64@8
-_adj_fdiv_r ; Check!!! Couldn't determine function argument count. Function 
doesn't return. 
+_adj_fdiv_r
 _adj_fdivr_m16i@4
 _adj_fdivr_m32@4
 _adj_fdivr_m32i@4
@@ -353,7 +353,7 @@
 _aligned_realloc
 _aligned_recalloc
 _amsg_exit
-_assert
+_assert DATA
 _atodbl
 _atodbl_l
 _atof_l
@@ -368,9 +368,9 @@
 _beep
 _beginthread
 _beginthreadex
-_byteswap_uint64
-_byteswap_ulong
-_byteswap_ushort
+_byteswap_uint64 DATA
+_byteswap_ulong DATA
+_byteswap_ushort DATA
 _c_exit
 _cabs
 _callnewh
@@ -411,7 +411,7 @@
 _cscanf_l
 _cscanf_s
 _cscanf_s_l
-_ctime32
+_ctime32 DATA
 _ctime32_s
 _ctime64
 _ctime64_s
@@ -427,9 +427,9 @@
 _cwscanf_s
 _cwscanf_s_l
 _daylight DATA
-_decode_pointer
-_difftime32
-_difftime64
+_decode_pointer DATA
+_difftime32 DATA
+_difftime64 DATA
 _dosmaperr
 _dstbias DATA
 _dup
@@ -437,10 +437,10 @@
 _dupenv_s
 _ecvt
 _ecvt_s
-_encode_pointer
+_encode_pointer DATA
 _encoded_null
-_endthread 
-_endthreadex 
+_endthread
+_endthreadex
 _environ DATA
 _eof
 _errno
@@ -474,18 +474,18 @@
 _findfirst32
 _findfirst32i64
 _findfirst64
-_findfirst64i32
+_findfirst64i32 DATA
 _findnext32
 _findnext32i64
 _findnext64
-_findnext64i32
+_findnext64i32 DATA
 _finite
 _flsbuf
 _flushall
 _fmode DATA
 _fpclass
 _fpieee_flt
-_fpreset
+_fpreset DATA
 _fprintf_l
 _fpr

Re: [Mingw-w64-public] [PATCH] Mark msvcr90 functions which also provide in libmingwex by DATA

[Dongsheng Song]

于 2011-5-19 15:14, Ozkan Sezer 写道:
> On Thu, May 19, 2011 at 9:51 AM, Dongsheng Song
>  wrote:
>> Hi,
>>
>> There have 69 functions both in libmingwex and 64 bit msvcr90.dll,
>> 50 functions both in libmingwex and 32 bit msvcr90.dll, all of them
>> should mark by DATA.
>>
>> PS: I'm using VS 2008 SP1 runtime to generate the .DEF files.
>>
>>  ChangeLog |   22 
>>  lib32/msvcr90.def |  122 +++---
>>  lib64/msvcr90.def |  142 
>> +++---
>>  3 files changed, 154 insertions(+), 132 deletions(-)
>>
>> --
>> Dongsheng
> I can at least confirm that the changes to __threadhandle, __threadid,
> _getdrives, _getpid and _unloaddll in lib32 version are correct because
> all of them are __cdecl and not __stdcall.  As for removing the fixme
> notes for _inconsistency and _adj_fdiv_r, I am not sure that it is wise
> and/or whether the new versions are correct.  Didn't look at exports
> proposed for marking as DATA.
>
> --
> O.S.

These fixme notes removed by gendef with the latest msvcr90.dll automatically.

-?_inconsistency@@YAXXZ ; Check!!! Couldn't determine function argument count. 
Function doesn't return.
+?_inconsistency@@YAXXZ

-_adj_fdiv_r ; Check!!! Couldn't determine function argument count. Function 
doesn't return.
+_adj_fdiv_r

--
Dongsheng




signature.asc
Description: OpenPGP digital signature
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] question on libmangle_decode_ms_name

[Dongsheng Song]

I think this is a debug line, should be removed, right ?

Index: libmangle/src/m_ms.c
===
--- libmangle/src/m_ms.c(revision 4169)
+++ libmangle/src/m_ms.c(working copy)
@@ -110,8 +110,6 @@
   ctx.pZNameList = &ZNameList;
   ctx.pArgList = &ArgList;
   ctx.pTemplateArgList = &TempArgList;
-
-  fprintf(stderr,"decode_ms_name: %s\n", name);

   if (name[0] == '?')
 {

--
Dongsheng




signature.asc
Description: OpenPGP digital signature
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay___
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] Mark msvcr90 functions which also provide in libmingwex by DATA

[Dongsheng Song]

On Thu, May 19, 2011 at 15:28, Dongsheng Song wrote:

> 于 2011-5-19 15:14, Ozkan Sezer 写道:
> > On Thu, May 19, 2011 at 9:51 AM, Dongsheng Song
> >  wrote:
> >> Hi,
> >>
> >> There have 69 functions both in libmingwex and 64 bit msvcr90.dll,
> >> 50 functions both in libmingwex and 32 bit msvcr90.dll, all of them
> >> should mark by DATA.
> >>
> >> PS: I'm using VS 2008 SP1 runtime to generate the .DEF files.
> >>
> >>  ChangeLog |   22 
> >>  lib32/msvcr90.def |  122 +++---
> >>  lib64/msvcr90.def |  142
> +++---
> >>  3 files changed, 154 insertions(+), 132 deletions(-)
> >>
>
>
ping:-)

Without this patch, I can not compile cx-Oracle. Due to the official
python-2.7 distro use msvcr90.dll,
then when I compile cx-Oracle, setup.py will link libmsvcr90.a
automatically, failed on symbols conflict.

With this patch, I can build and test cx-Oracle smoothly.

--
Dongsheng
--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [winpthread] Assertion failed: (sem_init(&sema, 0, 0) == 0), file benchtest5.c, line 134

[Dongsheng Song]

Hi,

With the attached patch, I can building and testing WinPthread, but
benchmark testing 5th failed on XP SP3:

$ cd winpthreads/tests
$ make clean GC
...
ALL TESTS PASSED! Congratulations!

$ make GC-bench
Copying .././outlib/libpthreadGC2-32.dll.a
Copying .././outlib/pthreadGC2-32.dll
make -k TEST=GC CC=-gcc XXCFLAGS="-D__CLEANUP_C" XXLIBS="" all-bench
make[1]: Entering directory
`/o/vcs/svn/mingw-w64/experimental/winpthreads/tests
'
Copying ../include/pthread.h
Copying ../include/semaphore.h
Running benchtest1
./benchtest1
=

Lock plus unlock on an unlocked mutex.
1000 iterations

Test  Total(msec)
average(usec)
-
Dummy call x 2 46
0.005
Dummy call -> Interlocked with cond x 2   344
0.034
InterlockedOp x 2 328
0.033
Simple Critical Section   360
0.036
Old PT Mutex using a Critical Section (WNT)   406
0.041
Old PT Mutex using a Win32 Mutex (W9x)   9969
0.997
.
PTHREAD_MUTEX_DEFAULT (W9x,WNT) 12640
1.264
PTHREAD_MUTEX_NORMAL (W9x,WNT)  12610
1.261
PTHREAD_MUTEX_ERRORCHECK (W9x,WNT)  12656
1.266
PTHREAD_MUTEX_RECURSIVE (W9x,WNT)   12969
1.297
=
Done
Compiling benchtest2.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C benchlib.o -o benchtest2.exe
benchtest2.c
-I./include -L../outlib -lpthreadGC2-32 -lsupc++
Running benchtest2
./benchtest2
=

Lock plus unlock on a locked mutex.
10 iterations, four locks/unlocks per iteration.

Test  Total(msec)
average(usec)
-
Simple Critical Section   375
0.938
Old PT Mutex using a Critical Section (WNT)   437
1.093
Old PT Mutex using a Win32 Mutex (W9x)500
1.250
.
PTHREAD_MUTEX_DEFAULT (W9x,WNT)   640
1.600
PTHREAD_MUTEX_NORMAL (W9x,WNT)609
1.523
PTHREAD_MUTEX_ERRORCHECK (W9x,WNT)656
1.640
PTHREAD_MUTEX_RECURSIVE (W9x,WNT) 594
1.485
=
Done
Compiling benchtest3.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C benchlib.o -o benchtest3.exe
benchtest3.c
-I./include -L../outlib -lpthreadGC2-32 -lsupc++
Running benchtest3
./benchtest3
=

Trylock on a locked mutex.
1000 iterations.

Test  Total(msec)
average(usec)
-
Old PT Mutex using a Critical Section (WNT)   296
0.030
Old PT Mutex using a Win32 Mutex (W9x)   5375
0.537
.
PTHREAD_MUTEX_DEFAULT (W9x,WNT)  1297
0.130
PTHREAD_MUTEX_NORMAL (W9x,WNT)   1297
0.130
PTHREAD_MUTEX_ERRORCHECK (W9x,WNT)   1297
0.130
PTHREAD_MUTEX_RECURSIVE (W9x,WNT)1297
0.130
=
Done
Compiling benchtest4.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C benchlib.o -o benchtest4.exe
benchtest4.c
-I./include -L../outlib -lpthreadGC2-32 -lsupc++
Running benchtest4
./benchtest4
=
Trylock plus unlock on an unlocked mutex.
1000 iterations.

Test  Total(msec)
average(usec)
-
Old PT Mutex using a Critical Section (WNT)   407
0.041
Old PT Mutex using a Win32 Mutex (W9x)  10031
1.003
.
PTHREAD_MUTEX_DEFAULT (W9x,WNT) 12797
1.280
PTHREAD_MUTEX_NORMAL (W9x,WNT)  12828
1.283
PTHREAD_MUTEX_ERRORCHECK (W9x,WNT)  12797
1.280
PTHREAD_MUTEX_RECURSIVE (W9x,WNT)   12937
1.294
=
Done
Compiling benchtest5.exe
-gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C benchlib.o -o benchtest5.exe
bench

Re: [Mingw-w64-public] [winpthread] Assertion failed: (sem_init(&sema, 0, 0) == 0), file benchtest5.c, line 134

[Dongsheng Song]

After I review the source, the failure was caused by sem_init only
support PTHREAD_PROCESS_PRIVATE,
but benchtest.c required PTHREAD_PROCESS_SHARED.

Here is my patch.

On Wed, May 25, 2011 at 22:11, Dongsheng Song  wrote:
>
> Hi,
>
> With the attached patch, I can building and testing WinPthread, but benchmark 
> testing 5th failed on XP SP3:
>
> $ cd winpthreads/tests
> $ make clean GC
> ...
> ALL TESTS PASSED! Congratulations!
>
> $ make GC-bench
> Copying .././outlib/libpthreadGC2-32.dll.a
> Copying .././outlib/pthreadGC2-32.dll
> make -k TEST=GC CC=-gcc XXCFLAGS="-D__CLEANUP_C" XXLIBS="" all-bench
> make[1]: Entering directory 
> `/o/vcs/svn/mingw-w64/experimental/winpthreads/tests
> '
> Copying ../include/pthread.h
> Copying ../include/semaphore.h
> Running benchtest1
> ./benchtest1
> =
>
> Lock plus unlock on an unlocked mutex.
> 1000 iterations
>
> Test  Total(msec)   average(usec)
> -
> Dummy call x 2 46   0.005
> Dummy call -> Interlocked with cond x 2   344   0.034
> InterlockedOp x 2 328   0.033
> Simple Critical Section   360   0.036
> Old PT Mutex using a Critical Section (WNT)   406   0.041
> Old PT Mutex using a Win32 Mutex (W9x)   9969   0.997
> .
> PTHREAD_MUTEX_DEFAULT (W9x,WNT) 12640   1.264
> PTHREAD_MUTEX_NORMAL (W9x,WNT)  12610   1.261
> PTHREAD_MUTEX_ERRORCHECK (W9x,WNT)  12656   1.266
> PTHREAD_MUTEX_RECURSIVE (W9x,WNT)   12969   1.297
> =
> Done
> Compiling benchtest2.exe
> -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C benchlib.o -o benchtest2.exe 
> benchtest2.c
> -I./include -L../outlib -lpthreadGC2-32 -lsupc++
> Running benchtest2
> ./benchtest2
> =
>
> Lock plus unlock on a locked mutex.
> 10 iterations, four locks/unlocks per iteration.
>
> Test  Total(msec)   average(usec)
> -
> Simple Critical Section   375   0.938
> Old PT Mutex using a Critical Section (WNT)   437   1.093
> Old PT Mutex using a Win32 Mutex (W9x)    500   1.250
> .
> PTHREAD_MUTEX_DEFAULT (W9x,WNT)   640   1.600
> PTHREAD_MUTEX_NORMAL (W9x,WNT)    609   1.523
> PTHREAD_MUTEX_ERRORCHECK (W9x,WNT)    656   1.640
> PTHREAD_MUTEX_RECURSIVE (W9x,WNT) 594   1.485
> =
> Done
> Compiling benchtest3.exe
> -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C benchlib.o -o benchtest3.exe 
> benchtest3.c
> -I./include -L../outlib -lpthreadGC2-32 -lsupc++
> Running benchtest3
> ./benchtest3
> =
>
> Trylock on a locked mutex.
> 1000 iterations.
>
> Test  Total(msec)   average(usec)
> -
> Old PT Mutex using a Critical Section (WNT)   296   0.030
> Old PT Mutex using a Win32 Mutex (W9x)   5375   0.537
> .
> PTHREAD_MUTEX_DEFAULT (W9x,WNT)  1297   0.130
> PTHREAD_MUTEX_NORMAL (W9x,WNT)   1297   0.130
> PTHREAD_MUTEX_ERRORCHECK (W9x,WNT)   1297   0.130
> PTHREAD_MUTEX_RECURSIVE (W9x,WNT)    1297   0.130
> =
> Done
> Compiling benchtest4.exe
> -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C benchlib.o -o benchtest4.exe 
> benchtest4.c
> -I./include -L../outlib -lpthreadGC2-32 -lsupc++
> Running benchtest4
> ./benchtest4
> =

[Mingw-w64-public] About IP Address String Conversion Functions in mstcpip.h

[Dongsheng Song]

Hi all,

>From MSDN page:

http://msdn.microsoft.com/en-us/library/aa366071%28v=VS.85%29.aspx

These functions:

RtlIpv6AddressToString
RtlIpv6StringToAddress
RtlIpv4AddressToString
RtlIpv6AddressToString

Only in Windows Vista/Server 2008 or later. But on my Windows XP these
functions exists too:

Ntdll.dll: 5.1.2600.6055 (xpsp_sp3_gdr.101209-1647)

I think for mingw-w64, we should lower _WIN32_WINNT from 0x0600 to 0x0502
(Windows Server 2003 with SP1, Windows XP with SP2), right ?

http://msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx

Regards,
Dongsheng

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] IP address string conversion functions available on Windows 2003/XP too

[Dongsheng Song]

于 2011-5-31 21:49, Dongsheng Song 写道:
> Hi all,
>
> From MSDN page:
>
> http://msdn.microsoft.com/en-us/library/aa366071%28v=VS.85%29.aspx
>
> These functions:
>
> RtlIpv6AddressToString
> RtlIpv6StringToAddress
> RtlIpv4AddressToString
> RtlIpv6AddressToString
>
> Only in Windows Vista/Server 2008 or later. But on my Windows XP these
> functions exists too:
>
> Ntdll.dll: 5.1.2600.6055 (xpsp_sp3_gdr.101209-1647)
>
> I think for mingw-w64, we should lower _WIN32_WINNT from 0x0600 to 0x0502
> (Windows Server 2003 with SP1, Windows XP with SP2), right ?
>
> http://msdn.microsoft.com/en-us/library/aa383745%28v=vs.85%29.aspx
>
> Regards,
> Dongsheng

I can confirm Windows 2003 have these functions too:
Ntdll.dll: 5.2.3790.4789 (srv03_sp2_gdr.101019-0340)

So the attached patch should be applied, OK ?

Regards,
Dongsheng

Index: mingw-w64-headers/ChangeLog
===
--- mingw-w64-headers/ChangeLog (revision 4186)
+++ mingw-w64-headers/ChangeLog (working copy)
@@ -0,0 +1,4 @@
+2011-06-01  Dongsheng Song  :
+
+   * include/mstcpip.h: IP address string conversion functions available
+   on Windows Server 2003 with SP1 or Windows XP with SP2 too.
Index: mingw-w64-headers/include/mstcpip.h
===
--- mingw-w64-headers/include/mstcpip.h (revision 4186)
+++ mingw-w64-headers/include/mstcpip.h (working copy)
@@ -30,7 +30,7 @@
 #define RCVALL_ON 1
 #define RCVALL_SOCKETLEVELONLY 2
 
-#if (_WIN32_WINNT >= 0x0600)
+#if (_WIN32_WINNT >= 0x0502)
 #define SOCKET_SETTINGS_GUARANTEE_ENCRYPTION 0x0001
 #define SOCKET_SETTINGS_ALLOW_INSECURE 0x0002
 
@@ -189,7 +189,7 @@
   PUSHORT Port
 );
 
-#endif /*(_WIN32_WINNT >= 0x0600)*/
+#endif /*(_WIN32_WINNT >= 0x0502)*/
 
 #endif /* _MSTCPIP_ */
 


signature.asc
Description: OpenPGP digital signature
--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [winpthread] How to debug tests\cancel8 failure ?

[Dongsheng Song]

Hi,

tests\cancel8 sometimes running OK on 32bit, sometimes fail, but
always fail on 64bit.

It's very strange that this test running OK on gdb every time, so the
question is:
How to debug tests\cancel8 failure ? Or this test not suitable for winpthread ?

C:\winpthread-64\tests>gdb64 cancel8
GNU gdb (GDB) 7.3.50.20110601-cvs
Copyright (C) 2011 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:
...
Reading symbols from C:\winpthread-64\tests/cancel8.exe...done.
(gdb) r
Starting program: C:\winpthread-64\tests/cancel8.exe
[New Thread 3572.0xe0c]
warning: Can not parse XML library list; XML support was disabled at
compile time
[New Thread 3572.0xe30]
[New Thread 3572.0xe34]
[New Thread 3572.0xe40]
[New Thread 3572.0xe20]
[Inferior 1 (process 3572) exited normally]
(gdb) quit


C:\winpthread-64\tests>cancel8 (failed silently)

C:\winpthread-64\tests>echo %ERRORLEVEL%
-1073741819

C:\winpthread-64\tests>cancel9
Cancel sleeping thread.
Cancel waiting thread.
Cancel blocked thread (blocked on network I/O).

C:\winpthread-64\tests>echo %ERRORLEVEL%
0

Thanks,
Dongsheng

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
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.6.2 (prerelease) rubenvb Personal Build, now with Clang addon!

[Dongsheng Song]

On Wed, Jul 6, 2011 at 21:56, Ruben Van Boxem wrote:

>   - I have updated to the newest mingw-w64 crt and headers, and
> re-enabled wildcard globbing, so that you can call executables like
> this: "x86_64-w64-mingw32-strip *.exe" and have it strip all
> executables in the current directory.
>

Thanks, could you tell me how you enable wildcard globbing ?
Modify the source source, or use a specify option ?

The same issue also in the grep, MSYS package support wildcard globbing,
but when I build myself, no wildcard globing support anymore.

--
Dongsheng
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
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.6.2 (prerelease) rubenvb Personal Build, now with Clang addon!

[Dongsheng Song]

On Thu, Jul 7, 2011 at 21:12, Ruben Van Boxem  wrote:
>
> The mingw-w64 crt has a configure option "--enable-wildcard" which
> enables this functionality.
>

Thanks,  it works fine.
When I use the new crt, grep 2.9 can support wildcard globbing now.

--
Dongsheng

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] PostgreSQL with MinGW-w64

[Dongsheng Song]

Hi,

I see PostgreSQL in the "Projects successfully using MinGW-w64" list, but
when I build
PostgreSQL 9.0.x or 9.1.x with the latest i686-w64-mingw32-gcc (4.6.2
20110705) and crt,
I must tweak the 'accept' function check script in the configure script:

/path/to/postgresql/configure --prefix=/tmp/w32 --host=i686-w64-mingw32

Then the configure script running fine, but make failed with the fllowing
errors:

oracle@vc:/tmp/pg$ make
make -C src all
make[1]: Entering directory `/tmp/pg/src'
make -C port all
make[2]: Entering directory `/tmp/pg/src/port'
i686-w64-mingw32-gcc -O2 -pipe -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
-I../../src/port -DFRONTEND -I../../src/include
-I/home/oracle/vcs/git/postgresql/src/include
-I/home/oracle/vcs/git/postgresql/src/include/port/win32 -DEXEC_BACKEND
 "-I/home/oracle/vcs/git/postgresql/src/include/port/win32"  -c -o crypt.o
/home/oracle/vcs/git/postgresql/src/port/crypt.c
In file included from ../../src/include/pg_config_os.h:37:0,
from /home/oracle/vcs/git/postgresql/src/include/c.h:90,
from /home/oracle/vcs/git/postgresql/src/port/crypt.c:44:
/home/oracle/gcc-4.6-windows-linux/lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/include/winsock2.h:15:2:
warning: #warning Please include winsock2.h before windows.h [-Wcpp]
In file included from /home/oracle/vcs/git/postgresql/src/include/c.h:90:0,
from /home/oracle/vcs/git/postgresql/src/port/crypt.c:44:
../../src/include/pg_config_os.h:228:0: warning: "fseeko" redefined [enabled
by default]
/home/oracle/gcc-4.6-windows-linux/lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/include/stdio.h:192:0:
note: this is the location of the previous definition
../../src/include/pg_config_os.h:229:0: warning: "ftello" redefined [enabled
by default]
/home/oracle/gcc-4.6-windows-linux/lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/include/stdio.h:207:0:
note: this is the location of the previous definition
i686-w64-mingw32-gcc -O2 -pipe -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
-I../../src/port -DFRONTEND -I../../src/include
-I/home/oracle/vcs/git/postgresql/src/include
-I/home/oracle/vcs/git/postgresql/src/include/port/win32 -DEXEC_BACKEND
 "-I/home/oracle/vcs/git/postgresql/src/include/port/win32"  -c -o erand48.o
/home/oracle/vcs/git/postgresql/src/port/erand48.c
In file included from ../../src/include/pg_config_os.h:37:0,
from /home/oracle/vcs/git/postgresql/src/include/c.h:90,
from /home/oracle/vcs/git/postgresql/src/port/erand48.c:28:
/home/oracle/gcc-4.6-windows-linux/lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/include/winsock2.h:15:2:
warning: #warning Please include winsock2.h before windows.h [-Wcpp]
In file included from /home/oracle/vcs/git/postgresql/src/include/c.h:90:0,
from /home/oracle/vcs/git/postgresql/src/port/erand48.c:28:
../../src/include/pg_config_os.h:228:0: warning: "fseeko" redefined [enabled
by default]
/home/oracle/gcc-4.6-windows-linux/lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/include/stdio.h:192:0:
note: this is the location of the previous definition
../../src/include/pg_config_os.h:229:0: warning: "ftello" redefined [enabled
by default]
/home/oracle/gcc-4.6-windows-linux/lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/include/stdio.h:207:0:
note: this is the location of the previous definition
i686-w64-mingw32-gcc -O2 -pipe -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
-I../../src/port -DFRONTEND -I../../src/include
-I/home/oracle/vcs/git/postgresql/src/include
-I/home/oracle/vcs/git/postgresql/src/include/port/win32 -DEXEC_BACKEND
 "-I/home/oracle/vcs/git/postgresql/src/include/port/win32"  -c -o
getrusage.o /home/oracle/vcs/git/postgresql/src/port/getrusage.c
In file included from ../../src/include/pg_config_os.h:37:0,
from /home/oracle/vcs/git/postgresql/src/include/c.h:90,
from
/home/oracle/vcs/git/postgresql/src/port/getrusage.c:16:
/home/oracle/gcc-4.6-windows-linux/lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/include/winsock2.h:15:2:
warning: #warning Please include winsock2.h before windows.h [-Wcpp]
In file included from /home/oracle/vcs/git/postgresql/src/include/c.h:90:0,
from
/home/oracle/vcs/git/postgresql/src/port/getrusage.c:16:
../../src/include/pg_config_os.h:228:0: warning: "fseeko" redefined [enabled
by default]
/home/oracle/gcc-4.6-windows-linux/lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/include/stdio.h:192:0:
note: this is the location of the previous definition
../../src/include/pg_config_os.h:229:0: warning: "ftello" redefined [enabled
by default]
/home/oracle/gcc-4.6-windows-linux/lib/gcc/i686-w64-mingw32/4.6.2/../

Re: [Mingw-w64-public] rubenvb's GCC 4.6.2 (prerelease) Personal build

[Dongsheng Song]

Maybe change import DLL file names ?
e.g. msvcrt.dll to msvcr100.dll (when use those common symbols only).

On Thu, Aug 4, 2011 at 22:59, Kai Tietz  wrote:

> 2011/8/4 NightStrike :
> > On Thu, Aug 4, 2011 at 5:20 AM, PcX  wrote:
> >> 于 2011/8/3 19:57, NightStrike 写道:
> >>
> >> We could, if we could find the time.  I know i for one have started a
> >> new job and have very limited time.
> >>
> >> If you'd like to write it, though, we'd be very happy to add you to
> >> the project and make you maintainer of it.  Join us on IRC at
> >> irc://irc.oftc.net/#mingw-w64
> >>
> >> Well, if I have the PE Programming knowledge, I will try to write one...
> >> I have some spare time now, but very sorry have not the PE structure
> >> technique.
> >> Could you provide some programming knowledge about the large address of
> the
> >> 32bit PE access?
> >
> > That's out of my league.  Maybe Kai can.
>
> So, to get an intial idea about the pe-coff format, you should read
> the pe-coff specification provided by Microsoft.  Additionally you can
> read in msdn about it a bit. This should giive you good starting point
> to learn a bit about it.
> A tool to modify pe-coff flags is pretty trivial and I would like to
> do - before we actually implement it - define a requirement list of
> additional features it might should have.  We should avoid double
> features to objcopy tool, but indeed there are some I see as
> interesting.
> -  Changing pe-coff flags
> - Changing pe-coff stack-reserve/commit values
> - Changing pe-coff heap-size values
> - Discard special sections
> - Compacting pe-coff image
> - Change section flags
> - Modify pe-coff directory-entries
>
> More complex features might be
> - Inserting, delete, modify additional resources
> - Resize sections
> - Merge sections into other sections
>
> So I am open-minded to hear a bit about the wish-list here.  And then
> we might start the implementation of such an new tool.
>
> Regards,
> Kai
>
>
> --
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] std::thread::sleep_for() question

[Dongsheng Song]

On Thu, Sep 1, 2011 at 19:08, niXman  wrote:

> Hi all!
> Any ideas about the nanosleep() function?
> Maybe it shoul be implemented into mingw-w64-crt ?
>
>
Same for me.

My project  clock_* too, I must implement myself:

int nanosleep(const struct timespec *request, struct timespec *remain);

int clock_getres(clockid_t clock_id, struct timespec *res);
int clock_gettime(clockid_t clock_id, struct timespec *tp);
int clock_settime(clockid_t clock_id, const struct timespec *tp);
int clock_nanosleep(clockid_t clock_id, int flags,
   const struct timespec *request,
   struct timespec *remain);

Is these functions should go into mingw-w64-crt, I can send patches is it
acceptable.

--
Dongsheng
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] std::thread::sleep_for() question

[Dongsheng Song]

On Fri, Sep 2, 2011 at 11:56, Dongsheng Song  wrote:
>
> On Thu, Sep 1, 2011 at 19:08, niXman  wrote:
>>
>> Hi all!
>> Any ideas about the nanosleep() function?
>> Maybe it shoul be implemented into mingw-w64-crt ?
>>
>
> Same for me.
> My project  clock_* too, I must implement myself:
> int nanosleep(const struct timespec *request, struct timespec *remain);
> int clock_getres(clockid_t clock_id, struct timespec *res);
> int clock_gettime(clockid_t clock_id, struct timespec *tp);
> int clock_settime(clockid_t clock_id, const struct timespec *tp);
> int clock_nanosleep(clockid_t clock_id, int flags,
>                            const struct timespec *request,
>                            struct timespec *remain);
> Is these functions should go into mingw-w64-crt, I can send patches is it 
> acceptable.

If these functions should go into mingw-w64-crt, I can send patches if
it acceptable.

Sorry for the typo.

--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] std::thread::sleep_for() question

[Dongsheng Song]

On Fri, Sep 2, 2011 at 14:22, JonY  wrote:
> Why not, the more code the merrier :)
>
[
2011-09-02  Dongsheng Song  :
* misc/nanosleep.c: New.
* testcases/t_nanosleep.c: New.
]

New:
mingw-w64-crt/misc/nanosleep.c
mingw-w64-crt/testcases/t_nanosleep.c

Please update mingw-w64-crt/Makefile.am and mingw-w64-headers/crt/time.h
when you want to add these files to mingw-w64-crt.

--
Dongsheng
#include 
#include 

#define POW10_3 1000
#define POW10_6 100

extern int __cdecl getntptimeofday(struct timespec *tp, struct timezone *tz);

__int64 timespec_diff_as_ms(struct timespec *__old, struct timespec *__new)
{
return (__new->tv_sec - __old->tv_sec) * POW10_3
 + (__new->tv_nsec - __old->tv_nsec) / POW10_6;
}

int main(int argc, char *argv[])
{
int rc;
struct timespec tp, tp2, request = { 1, 0 }, remain;

getntptimeofday(&tp, NULL);
rc = nanosleep(&request, &remain);
getntptimeofday(&tp2, NULL);

if (rc != 0) {
printf("remain: %d.%09d\n", (int) remain.tv_sec, (int) remain.tv_nsec);
}

printf("%d.%09d\n", (int) tp.tv_sec, (int) tp.tv_nsec);
printf("%d.%09d\n", (int) tp2.tv_sec, (int) tp2.tv_nsec);
printf("sleep %d ms\n", (int) timespec_diff_as_ms(&tp, &tp2));

return 0;
}
/**
 * This file has no copyright assigned and is placed in the Public Domain.
 * This file is part of the w64 mingw-runtime package.
 * No warranty is given; refer to the file DISCLAIMER.PD within this package.
 */
#include 
#include 
#include 

#define POW10_3 1000
#define POW10_6 100
#define POW10_9 10
#define MAX_SLEEP_IN_MS 4294967294UL

/**
 * Sleep for the specified time.
 * @param  request The desired amount of time to sleep.
 * @param  remain The remain amount of time to sleep.
 * @return If the function succeeds, the return value is 0.
 * If the function fails, the return value is -1,
 * with errno set to indicate the error.
 */
int nanosleep(const struct timespec *request, struct timespec *remain)
{
unsigned long ms, rc = 0;
unsigned __int64 u64;

if (request->tv_sec < 0 || request->tv_nsec < 0 || request->tv_nsec >= POW10_9) {
errno = EINVAL;
return -1;
}

u64 = request->tv_sec * POW10_3 + request->tv_nsec / POW10_6;
while (u64 > 0) {
if (u64 >= MAX_SLEEP_IN_MS) ms = MAX_SLEEP_IN_MS;
else ms = (unsigned long) u64;
u64 -= ms;
rc = SleepEx(ms, TRUE);
}

if (rc != 0) { /* WAIT_IO_COMPLETION */
if (remain != NULL) {
remain->tv_sec = u64 / POW10_3;
remain->tv_nsec = (long) (u64 % POW10_3) * POW10_6;
}
errno = EINTR;
return -1;
}

return 0;
}
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] std::thread::sleep_for() question

[Dongsheng Song]

于 2011-9-2 14:34, Dongsheng Song 写道:
> On Fri, Sep 2, 2011 at 14:22, JonY  wrote:
>> Why not, the more code the merrier :)
>>
> [
> 2011-09-02  Dongsheng Song  :
> * misc/nanosleep.c: New.
> * testcases/t_nanosleep.c: New.
> ]
>
> New:
> mingw-w64-crt/misc/nanosleep.c
> mingw-w64-crt/testcases/t_nanosleep.c
>
> Please update mingw-w64-crt/Makefile.am and mingw-w64-headers/crt/time.h
> when you want to add these files to mingw-w64-crt.
>
> --
> Dongsheng
Sorry, I post the old version of nanosleep.c in the previous mail.

/**
 * This file has no copyright assigned and is placed in the Public Domain.
 * This file is part of the w64 mingw-runtime package.
 * No warranty is given; refer to the file DISCLAIMER.PD within this package.
 */
#include 
#include 
#include 

#define POW10_3 1000
#define POW10_4 1
#define POW10_6 100
#define POW10_9 10
#define MAX_SLEEP_IN_MS 4294967294UL

/**
 * Sleep for the specified time.
 * @param  request The desired amount of time to sleep.
 * @param  remain The remain amount of time to sleep.
 * @return If the function succeeds, the return value is 0.
 * If the function fails, the return value is -1,
 * with errno set to indicate the error.
 */
int nanosleep(const struct timespec *request, struct timespec *remain)
{
unsigned long ms, rc = 0;
unsigned __int64 u64, want, real;

union {
unsigned __int64 ns100;
FILETIME ft;
}  _start, _end;

if (request->tv_sec < 0 || request->tv_nsec < 0 || request->tv_nsec >= 
POW10_9) {
errno = EINVAL;
return -1;
}

if (remain != NULL) GetSystemTimeAsFileTime(&_start.ft);

want = u64 = request->tv_sec * POW10_3 + request->tv_nsec / POW10_6;
while (u64 > 0) {
if (u64 >= MAX_SLEEP_IN_MS) ms = MAX_SLEEP_IN_MS;
else ms = (unsigned long) u64;

u64 -= ms;
rc = SleepEx(ms, TRUE);
}

if (rc != 0) { /* WAIT_IO_COMPLETION */
if (remain != NULL) {
GetSystemTimeAsFileTime(&_end.ft);
real = (_end.ns100 - _start.ns100) / POW10_4;

if (real >= want) u64 = 0;
else u64 = want - real;

remain->tv_sec = u64 / POW10_3;
remain->tv_nsec = (long) (u64 % POW10_3) * POW10_6;
}

errno = EINTR;
return -1;
}

return 0;
}


signature.asc
Description: OpenPGP digital signature
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better 
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Add nanosleep.c and t_nanosleep.c

[Dongsheng Song]

From: Dongsheng Song 

---
 mingw-w64-crt/Makefile.am |2 +
 mingw-w64-crt/misc/nanosleep.c|   67 
 mingw-w64-crt/testcases/t_nanosleep.c |   92 +
 mingw-w64-headers/crt/time.h  |   58 +++-
 4 files changed, 216 insertions(+), 3 deletions(-)
 create mode 100644 mingw-w64-crt/misc/nanosleep.c
 create mode 100644 mingw-w64-crt/testcases/t_nanosleep.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index bc20948..1dd795a 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -222,6 +222,7 @@ src_libmingwex=\
   misc/wctype.c   misc/wdirent.c   misc/winbs_uint64.c   
misc/winbs_ulong.c   misc/winbs_ushort.c\
   misc/wmemchr.c  misc/wmemcmp.c   misc/wmemcpy.c
misc/wmemmove.c  misc/wmemset.c \
   misc/wcstof.c   misc/mingw_wcstod.c  misc/mingw_wcstof.c   
misc/mingw_wcstold.c \
+  misc/nanosleep.c\
   stdio/mingw_pformat.h \
   stdio/atoll.c stdio/_Exit.c stdio/_findfirst64i32.c \
   stdio/_findnext64i32.c stdio/fopen64.c \
@@ -1049,6 +1050,7 @@ testcase_progs = \
   testcases/t_intrinc \
   testcases/t_imagebase \
   testcases/t_matherr \
+  testcases/t_nanosleep \
   testcases/t_nullptrexception \
   testcases/t_readdir \
   testcases/t_setjmp \
diff --git a/mingw-w64-crt/misc/nanosleep.c b/mingw-w64-crt/misc/nanosleep.c
new file mode 100644
index 000..10c6c68
--- /dev/null
+++ b/mingw-w64-crt/misc/nanosleep.c
@@ -0,0 +1,67 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the w64 mingw-runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+#include 
+#include 
+#include 
+
+#define POW10_3 1000
+#define POW10_4 1
+#define POW10_6 100
+#define POW10_9 10
+#define MAX_SLEEP_IN_MS 4294967294UL
+
+/**
+ * Sleep for the specified time.
+ * @param  request The desired amount of time to sleep.
+ * @param  remain The remain amount of time to sleep.
+ * @return If the function succeeds, the return value is 0.
+ * If the function fails, the return value is -1,
+ * with errno set to indicate the error.
+ */
+int nanosleep(const struct timespec *request, struct timespec *remain)
+{
+unsigned long ms, rc = 0;
+unsigned __int64 u64, want, real;
+
+union {
+unsigned __int64 ns100;
+FILETIME ft;
+}  _start, _end;
+
+if (request->tv_sec < 0 || request->tv_nsec < 0 || request->tv_nsec >= 
POW10_9) {
+errno = EINVAL;
+return -1;
+}
+
+if (remain != NULL) GetSystemTimeAsFileTime(&_start.ft);
+
+want = u64 = request->tv_sec * POW10_3 + request->tv_nsec / POW10_6;
+while (u64 > 0 && rc == 0) {
+if (u64 >= MAX_SLEEP_IN_MS) ms = MAX_SLEEP_IN_MS;
+else ms = (unsigned long) u64;
+
+u64 -= ms;
+rc = SleepEx(ms, TRUE);
+}
+
+if (rc != 0) { /* WAIT_IO_COMPLETION (192) */
+if (remain != NULL) {
+GetSystemTimeAsFileTime(&_end.ft);
+real = (_end.ns100 - _start.ns100) / POW10_4;
+
+if (real >= want) u64 = 0;
+else u64 = want - real;
+
+remain->tv_sec = u64 / POW10_3;
+remain->tv_nsec = (long) (u64 % POW10_3) * POW10_6;
+}
+
+errno = EINTR;
+return -1;
+}
+
+return 0;
+}
diff --git a/mingw-w64-crt/testcases/t_nanosleep.c 
b/mingw-w64-crt/testcases/t_nanosleep.c
new file mode 100644
index 000..21c0ceb
--- /dev/null
+++ b/mingw-w64-crt/testcases/t_nanosleep.c
@@ -0,0 +1,92 @@
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define POW10_3 1000
+#define POW10_6 100
+
+extern int __cdecl getntptimeofday(struct timespec *tp, struct timezone *tz);
+
+__int64 timespec_diff_as_ms(struct timespec *__old, struct timespec *__new)
+{
+return (__new->tv_sec - __old->tv_sec) * POW10_3
+ + (__new->tv_nsec - __old->tv_nsec) / POW10_6;
+}
+
+unsigned __stdcall start_address(void *dummy)
+{
+int counter = 0;
+struct timespec request = { 1, 0 }, remain;
+
+while (counter < 5) {
+int rc = nanosleep(&request, &remain);
+if (rc != 0) {
+printf("nanosleep interrupted, remain %d.%09d sec.\n",
+(int) remain.tv_sec, (int) remain.tv_nsec);
+} else {
+printf("nanosleep succeeded.\n");
+}
+
+counter ++;
+}
+
+return 0;
+}
+
+void WINAPI usr_apc(ULONG_PTR dwParam)
+{
+long *index = (long *) dwParam;
+printf("running apc %ld\n", *index);
+}
+
+void test_apc()
+{
+long i, rc, data[5];
+HANDLE thread;
+
+thread 

Re: [Mingw-w64-public] [PATCH] Add nanosleep.c and t_nanosleep.c

[Dongsheng Song]

These clock_* functions have been declared in time.h, will post in the
next few days.

On Sat, Sep 3, 2011 at 14:42, JonY  wrote:
> On 9/3/2011 14:26, Dongsheng Song wrote:
>
> Kai, Ozkan, any objections?
>
>> From: Dongsheng Song 
>>
>> ---
>>  mingw-w64-crt/Makefile.am             |    2 +
>>  mingw-w64-crt/misc/nanosleep.c        |   67 
>>  mingw-w64-crt/testcases/t_nanosleep.c |   92 
>> +
>>  mingw-w64-headers/crt/time.h          |   58 +++-
>>  4 files changed, 216 insertions(+), 3 deletions(-)
>>  create mode 100644 mingw-w64-crt/misc/nanosleep.c
>>  create mode 100644 mingw-w64-crt/testcases/t_nanosleep.c
>>
>> diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
>> index bc20948..1dd795a 100644
>> --- a/mingw-w64-crt/Makefile.am
>> +++ b/mingw-w64-crt/Makefile.am
>> @@ -222,6 +222,7 @@ src_libmingwex=\
>>    misc/wctype.c               misc/wdirent.c       misc/winbs_uint64.c   
>> misc/winbs_ulong.c           misc/winbs_ushort.c    \
>>    misc/wmemchr.c              misc/wmemcmp.c       misc/wmemcpy.c        
>> misc/wmemmove.c              misc/wmemset.c         \
>>    misc/wcstof.c               misc/mingw_wcstod.c  misc/mingw_wcstof.c   
>> misc/mingw_wcstold.c         \
>> +  misc/nanosleep.c            \
>>    stdio/mingw_pformat.h \
>>    stdio/atoll.c stdio/_Exit.c stdio/_findfirst64i32.c \
>>    stdio/_findnext64i32.c stdio/fopen64.c \
>> @@ -1049,6 +1050,7 @@ testcase_progs = \
>>    testcases/t_intrinc \
>>    testcases/t_imagebase \
>>    testcases/t_matherr \
>> +  testcases/t_nanosleep \
>>    testcases/t_nullptrexception \
>>    testcases/t_readdir \
>>    testcases/t_setjmp \
>> diff --git a/mingw-w64-crt/misc/nanosleep.c b/mingw-w64-crt/misc/nanosleep.c
>> new file mode 100644
>> index 000..10c6c68
>> --- /dev/null
>> +++ b/mingw-w64-crt/misc/nanosleep.c
>> @@ -0,0 +1,67 @@
>> +/**
>> + * This file has no copyright assigned and is placed in the Public Domain.
>> + * This file is part of the w64 mingw-runtime package.
>> + * No warranty is given; refer to the file DISCLAIMER.PD within this 
>> package.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define POW10_3                 1000
>> +#define POW10_4                 1
>> +#define POW10_6                 100
>> +#define POW10_9                 10
>> +#define MAX_SLEEP_IN_MS         4294967294UL
>> +
>> +/**
>> + * Sleep for the specified time.
>> + * @param  request The desired amount of time to sleep.
>> + * @param  remain The remain amount of time to sleep.
>> + * @return If the function succeeds, the return value is 0.
>> + *         If the function fails, the return value is -1,
>> + *         with errno set to indicate the error.
>> + */
>> +int nanosleep(const struct timespec *request, struct timespec *remain)
>> +{
>> +    unsigned long ms, rc = 0;
>> +    unsigned __int64 u64, want, real;
>> +
>> +    union {
>> +        unsigned __int64 ns100;
>> +        FILETIME ft;
>> +    }  _start, _end;
>> +
>> +    if (request->tv_sec < 0 || request->tv_nsec < 0 || request->tv_nsec >= 
>> POW10_9) {
>> +        errno = EINVAL;
>> +        return -1;
>> +    }
>> +
>> +    if (remain != NULL) GetSystemTimeAsFileTime(&_start.ft);
>> +
>> +    want = u64 = request->tv_sec * POW10_3 + request->tv_nsec / POW10_6;
>> +    while (u64 > 0 && rc == 0) {
>> +        if (u64 >= MAX_SLEEP_IN_MS) ms = MAX_SLEEP_IN_MS;
>> +        else ms = (unsigned long) u64;
>> +
>> +        u64 -= ms;
>> +        rc = SleepEx(ms, TRUE);
>> +    }
>> +
>> +    if (rc != 0) { /* WAIT_IO_COMPLETION (192) */
>> +        if (remain != NULL) {
>> +            GetSystemTimeAsFileTime(&_end.ft);
>> +            real = (_end.ns100 - _start.ns100) / POW10_4;
>> +
>> +            if (real >= want) u64 = 0;
>> +            else u64 = want - real;
>> +
>> +            remain->tv_sec = u64 / POW10_3;
>> +            remain->tv_nsec = (long) (u64 % POW10_3) * POW10_6;
>> +        }
>> +
>> +        errno = EINTR;
>> +        return -1;
>> +    }
>> +
>> +    return 0;
>> +}
>> diff --git a/mingw-w64-crt/testcases/t_nanosleep.c 
>> b/mingw-w64-crt/testcases/t_nanosleep.c
>> new file mode 100644
>> index 000..21

[Mingw-w64-public] [PATCH 1/2] Add nanosleep.c and t_nanosleep.c

[Dongsheng Song]

---
 mingw-w64-crt/Makefile.am |2 +
 mingw-w64-crt/misc/nanosleep.c|   67 
 mingw-w64-crt/testcases/t_nanosleep.c |   92 +
 mingw-w64-headers/crt/time.h  |   58 +++-
 4 files changed, 216 insertions(+), 3 deletions(-)
 create mode 100644 mingw-w64-crt/misc/nanosleep.c
 create mode 100644 mingw-w64-crt/testcases/t_nanosleep.c

diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index bc20948..1dd795a 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -222,6 +222,7 @@ src_libmingwex=\
   misc/wctype.c   misc/wdirent.c   misc/winbs_uint64.c   
misc/winbs_ulong.c   misc/winbs_ushort.c\
   misc/wmemchr.c  misc/wmemcmp.c   misc/wmemcpy.c
misc/wmemmove.c  misc/wmemset.c \
   misc/wcstof.c   misc/mingw_wcstod.c  misc/mingw_wcstof.c   
misc/mingw_wcstold.c \
+  misc/nanosleep.c\
   stdio/mingw_pformat.h \
   stdio/atoll.c stdio/_Exit.c stdio/_findfirst64i32.c \
   stdio/_findnext64i32.c stdio/fopen64.c \
@@ -1049,6 +1050,7 @@ testcase_progs = \
   testcases/t_intrinc \
   testcases/t_imagebase \
   testcases/t_matherr \
+  testcases/t_nanosleep \
   testcases/t_nullptrexception \
   testcases/t_readdir \
   testcases/t_setjmp \
diff --git a/mingw-w64-crt/misc/nanosleep.c b/mingw-w64-crt/misc/nanosleep.c
new file mode 100644
index 000..10c6c68
--- /dev/null
+++ b/mingw-w64-crt/misc/nanosleep.c
@@ -0,0 +1,67 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the w64 mingw-runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+#include 
+#include 
+#include 
+
+#define POW10_3 1000
+#define POW10_4 1
+#define POW10_6 100
+#define POW10_9 10
+#define MAX_SLEEP_IN_MS 4294967294UL
+
+/**
+ * Sleep for the specified time.
+ * @param  request The desired amount of time to sleep.
+ * @param  remain The remain amount of time to sleep.
+ * @return If the function succeeds, the return value is 0.
+ * If the function fails, the return value is -1,
+ * with errno set to indicate the error.
+ */
+int nanosleep(const struct timespec *request, struct timespec *remain)
+{
+unsigned long ms, rc = 0;
+unsigned __int64 u64, want, real;
+
+union {
+unsigned __int64 ns100;
+FILETIME ft;
+}  _start, _end;
+
+if (request->tv_sec < 0 || request->tv_nsec < 0 || request->tv_nsec >= 
POW10_9) {
+errno = EINVAL;
+return -1;
+}
+
+if (remain != NULL) GetSystemTimeAsFileTime(&_start.ft);
+
+want = u64 = request->tv_sec * POW10_3 + request->tv_nsec / POW10_6;
+while (u64 > 0 && rc == 0) {
+if (u64 >= MAX_SLEEP_IN_MS) ms = MAX_SLEEP_IN_MS;
+else ms = (unsigned long) u64;
+
+u64 -= ms;
+rc = SleepEx(ms, TRUE);
+}
+
+if (rc != 0) { /* WAIT_IO_COMPLETION (192) */
+if (remain != NULL) {
+GetSystemTimeAsFileTime(&_end.ft);
+real = (_end.ns100 - _start.ns100) / POW10_4;
+
+if (real >= want) u64 = 0;
+else u64 = want - real;
+
+remain->tv_sec = u64 / POW10_3;
+remain->tv_nsec = (long) (u64 % POW10_3) * POW10_6;
+}
+
+errno = EINTR;
+return -1;
+}
+
+return 0;
+}
diff --git a/mingw-w64-crt/testcases/t_nanosleep.c 
b/mingw-w64-crt/testcases/t_nanosleep.c
new file mode 100644
index 000..21c0ceb
--- /dev/null
+++ b/mingw-w64-crt/testcases/t_nanosleep.c
@@ -0,0 +1,92 @@
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define POW10_3 1000
+#define POW10_6 100
+
+extern int __cdecl getntptimeofday(struct timespec *tp, struct timezone *tz);
+
+__int64 timespec_diff_as_ms(struct timespec *__old, struct timespec *__new)
+{
+return (__new->tv_sec - __old->tv_sec) * POW10_3
+ + (__new->tv_nsec - __old->tv_nsec) / POW10_6;
+}
+
+unsigned __stdcall start_address(void *dummy)
+{
+int counter = 0;
+struct timespec request = { 1, 0 }, remain;
+
+while (counter < 5) {
+int rc = nanosleep(&request, &remain);
+if (rc != 0) {
+printf("nanosleep interrupted, remain %d.%09d sec.\n",
+(int) remain.tv_sec, (int) remain.tv_nsec);
+} else {
+printf("nanosleep succeeded.\n");
+}
+
+counter ++;
+}
+
+return 0;
+}
+
+void WINAPI usr_apc(ULONG_PTR dwParam)
+{
+long *index = (long *) dwParam;
+printf("running apc %ld\n", *index);
+}
+
+void test_apc()
+{
+long i, rc, data[5];
+HANDLE thread;
+
+thread = (HANDLE) _beginthreadex(NULL, 0, start_address, NULL, 0, NULL);
+if (thread == NULL) {
+exit(1);
+}
+
+for (i = 0; i < 

[Mingw-w64-public] [PATCH 2/2] Add clock_* functions

[Dongsheng Song]

---
 mingw-w64-crt/misc/clock.c  |  234 +++
 mingw-w64-crt/testcases/t_clock_getres.c|   62 +++
 mingw-w64-crt/testcases/t_clock_gettime.c   |   60 +++
 mingw-w64-crt/testcases/t_clock_nanosleep.c |   56 +++
 mingw-w64-crt/testcases/t_clock_settime.c   |   46 ++
 5 files changed, 458 insertions(+), 0 deletions(-)
 create mode 100644 mingw-w64-crt/misc/clock.c
 create mode 100644 mingw-w64-crt/testcases/t_clock_getres.c
 create mode 100644 mingw-w64-crt/testcases/t_clock_gettime.c
 create mode 100644 mingw-w64-crt/testcases/t_clock_nanosleep.c
 create mode 100644 mingw-w64-crt/testcases/t_clock_settime.c

diff --git a/mingw-w64-crt/misc/clock.c b/mingw-w64-crt/misc/clock.c
new file mode 100644
index 000..28126ab
--- /dev/null
+++ b/mingw-w64-crt/misc/clock.c
@@ -0,0 +1,234 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the w64 mingw-runtime package.
+ * No warranty is given; refer to the file DISCLAIMER.PD within this package.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#define POW10_7 1000
+#define POW10_9 10
+
+/* Number of 100ns-seconds between the beginning of the Windows epoch
+ * (Jan. 1, 1601) and the Unix epoch (Jan. 1, 1970)
+ */
+#define DELTA_EPOCH_IN_100NSINT64_C(1164447360)
+
+static __inline int lc_set_errno(int result)
+{
+if (result != 0) {
+errno = result;
+return -1;
+}
+return 0;
+}
+
+/**
+ * Get the resolution of the specified clock clock_id and
+ * stores it in the struct timespec pointed to by res.
+ * @param  clock_id The clock_id argument is the identifier of the particular
+ * clock on which to act. The following clocks are supported:
+ * 
+ * CLOCK_REALTIME  System-wide real-time clock. Setting this clock
+ * requires appropriate privileges.
+ * CLOCK_MONOTONIC Clock that cannot be set and represents monotonic
+ * time since some unspecified starting point.
+ * CLOCK_PROCESS_CPUTIME_ID High-resolution per-process timer from the CPU.
+ * CLOCK_THREAD_CPUTIME_ID  Thread-specific CPU-time clock.
+ * 
+ * @param  res The pointer to a timespec structure to receive the time
+ * resolution.
+ * @return If the function succeeds, the return value is 0.
+ * If the function fails, the return value is -1,
+ * with errno set to indicate the error.
+ */
+int clock_getres(clockid_t clock_id, struct timespec *res)
+{
+switch(clock_id) {
+case CLOCK_MONOTONIC:
+{
+LARGE_INTEGER pf;
+
+if (QueryPerformanceFrequency(&pf) == 0)
+return lc_set_errno(EINVAL);
+
+res->tv_sec = 0;
+res->tv_nsec = (int) ((POW10_9 + (pf.QuadPart >> 1)) / 
pf.QuadPart);
+if (res->tv_nsec < 1)
+res->tv_nsec = 1;
+
+return 0;
+}
+
+case CLOCK_REALTIME:
+case CLOCK_PROCESS_CPUTIME_ID:
+case CLOCK_THREAD_CPUTIME_ID:
+{
+DWORD   timeAdjustment, timeIncrement;
+BOOLisTimeAdjustmentDisabled;
+
+(void) GetSystemTimeAdjustment(&timeAdjustment, &timeIncrement, 
&isTimeAdjustmentDisabled);
+res->tv_sec = 0;
+res->tv_nsec = timeIncrement * 100;
+
+return 0;
+}
+default:
+break;
+}
+
+return lc_set_errno(EINVAL);
+}
+
+/**
+ * Get the time of the specified clock clock_id and stores it in the struct
+ * timespec pointed to by tp.
+ * @param  clock_id The clock_id argument is the identifier of the particular
+ * clock on which to act. The following clocks are supported:
+ * 
+ * CLOCK_REALTIME  System-wide real-time clock. Setting this clock
+ * requires appropriate privileges.
+ * CLOCK_MONOTONIC Clock that cannot be set and represents monotonic
+ * time since some unspecified starting point.
+ * CLOCK_PROCESS_CPUTIME_ID High-resolution per-process timer from the CPU.
+ * CLOCK_THREAD_CPUTIME_ID  Thread-specific CPU-time clock.
+ * 
+ * @param  tp The pointer to a timespec structure to receive the time.
+ * @return If the function succeeds, the return value is 0.
+ * If the function fails, the return value is -1,
+ * with errno set to indicate the error.
+ */
+int clock_gettime(clockid_t clock_id, struct timespec *tp)
+{
+unsigned __int64 t;
+LARGE_INTEGER pf, pc;
+union {
+unsigned __int64 u64;
+FILETIME ft;
+}  ct, et, kt, ut;
+
+switch(clock_id) {
+case CLOCK_REALTIME:
+{
+GetSystemTimeAsFileTime(&ct.ft);
+t = ct.u64 - DELTA_EPOCH_IN_100NS;
+tp->tv_sec = t / POW10_7;
+tp->tv_nsec = ((int) (t % POW10_7)) * 100;
+
+return 0;
+}
+
+case CLOCK_MONOTONIC:
+{
+if (QueryPerformanceFrequency(&pf

Re: [Mingw-w64-public] [PATCH 2/2] Add clock_* functions

[Dongsheng Song]

On Thu, Sep 8, 2011 at 17:44, Kai Tietz  wrote:
> 2011/9/6 JonY :
>> On 9/4/2011 14:56, Dongsheng Song wrote:
>>> ---
>>>  mingw-w64-crt/misc/clock.c                  |  234 
>>> +++
>>>  mingw-w64-crt/testcases/t_clock_getres.c    |   62 +++
>>>  mingw-w64-crt/testcases/t_clock_gettime.c   |   60 +++
>>>  mingw-w64-crt/testcases/t_clock_nanosleep.c |   56 +++
>>>  mingw-w64-crt/testcases/t_clock_settime.c   |   46 ++
>>>  5 files changed, 458 insertions(+), 0 deletions(-)
>>>  create mode 100644 mingw-w64-crt/misc/clock.c
>>>  create mode 100644 mingw-w64-crt/testcases/t_clock_getres.c
>>>  create mode 100644 mingw-w64-crt/testcases/t_clock_gettime.c
>>>  create mode 100644 mingw-w64-crt/testcases/t_clock_nanosleep.c
>>>  create mode 100644 mingw-w64-crt/testcases/t_clock_settime.c
>>
>> Hi,
>>
>> We'll wait for Kai to give the green light.
>
> This work is great.  But we have to add it to the winpthread library.
> Another advantage (as the others I've told in prior threads) is that
> we can add here then also the proper _POSIX_... defines to
> unistd_pthread.h, so that POSIX apps can rely on this information to
> see that API is supported.
>
> Cheers,
> Kai
>

I don't think clock_* functions should go into winpthread instead of
mingw-w64-crt.

In practice (e.g. Linux or BSD), only sem_* and pthread_* functions
going to libpthread.

Yes, POSIX defined these functions, but there no POSIX named library,
they should
be in libc/librt, map to mingw-w64 crt.

nanosleep/clock_nanosleep: Yes,  the accuracy of the SleepEx interval
is the resolution
of the system clock (In our test is 15.625ms on XP or 2008 R2).

But the WaitableTimer API can give us  more accurate than SleepEx is
just expect,
in our testing, not obviously good than SleepEx. There is another
example, GetSystemTimeAsFileTime
allow to have a time-resolutine of 100ns, but in our testing, the
smallest increment interval
of the return value is 15.625ms.

In summary, there no need to use WaitableTimer API to implement
nanosleep/clock_nanosleep
since it not good than SleepEx, but increase the code complexity, use
more system resource.

I don't known what you mean 'pthread-compatible breakable wait', as
POSIX specified,
they can be interrupted by a signal handler, you mean pthread_cancel
or pthread_kill ?
I don't think they can be implement perfectly (only exit the thread at
the moment).

IMHO, nanosleep/clock_nanosleep can be interrupted by IOCP events is enough.

--
Dongsheng

--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
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 2/2] Add clock_* functions

[Dongsheng Song]

For your such plan, I recommend you rename winpthread to libposix,
or other suitable names.

--
Doing More with Less: The Next Generation Virtual Desktop 
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops?   How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Strange gettext-0.18.1.1 compile error on gcc 4.6 for mingw-w64 snapshot (20111122)

[Dongsheng Song]

Hi all,

Here is the build steps:

$ cd ${HOME}/tmp/libiconv
$ ${HOME}/src/libiconv-1.14/configure --prefix=${HOME}/tmp/w32
--host=i686-w64-mingw32 --disable-static --disable-nls
$ make
$ make install

$ cd ${HOME}/tmp/gettext
$ ${HOME}/src/gettext-0.18.1.1/configure --prefix=${HOME}/tmp/w32
--host=i686-w64-mingw32 --with-libiconv-prefix=${HOME}/tmp/w32
$ make
...
make[4]: Entering directory
`/home/oracle/src/gettext-0.18.1.1/gettext-tools/gnulib-lib'
\
/bin/sh ../libtool  --tag=CXX   --mode=compile : -DHAVE_CONFIG_H
-DEXEEXT=\".exe\" -DEXEEXT=\".exe\" -DEXEEXT=\".exe\" -I. -I..  -I../intl
-I../intl -I.. -I.. -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1
-DLIBXML_STATIC -I../intl -DGNULIB_DEFINED_GETOPT   -I./libcroco
 -I/home/oracle/tmp/w32/include   -c -o
../woe32dll/c++html-styled-ostream.lo ../woe32dll/c++html-styled-ostream.cc
libtool: compile:  : -DHAVE_CONFIG_H -DEXEEXT=\".exe\" -DEXEEXT=\".exe\"
-DEXEEXT=\".exe\" -I. -I.. -I../intl -I../intl -I.. -I..
-DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -DLIBXML_STATIC -I../intl
-DGNULIB_DEFINED_GETOPT -I./libcroco -I/home/oracle/tmp/w32/include -c
../woe32dll/c++html-styled-ostream.cc
libtool: compile: mv -f "c++html-styled-ostream.o"
"../woe32dll/.libs/c++html-styled-ostream.o"
mv: cannot stat `c++html-styled-ostream.o': No such file or directory
make[4]: *** [../woe32dll/c++html-styled-ostream.lo] Error 1
make[4]: Leaving directory
`/home/oracle/src/gettext-0.18.1.1/gettext-tools/gnulib-lib'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/home/oracle/src/gettext-0.18.1.1/gettext-tools/gnulib-lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/oracle/src/gettext-0.18.1.1/gettext-tools'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/oracle/src/gettext-0.18.1.1/gettext-tools'
make: *** [all-recursive] Error 1

It seems that libtool running in trouble, but no error messages.
Is there any way to debug it ?

Regards,
Dongsheng
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Strange gettext-0.18.1.1 compile error on gcc 4.6 for mingw-w64 snapshot (20111122)

[Dongsheng Song]

No, I build on the Linux machine.

On Wed, Nov 30, 2011 at 18:45, JonY  wrote:

> On 11/30/2011 18:03, Dongsheng Song wrote:
> > Hi all,
> >
> > Here is the build steps:
> >
> > $ cd ${HOME}/tmp/libiconv
> > $ ${HOME}/src/libiconv-1.14/configure --prefix=${HOME}/tmp/w32
> > --host=i686-w64-mingw32 --disable-static --disable-nls
> > $ make
> > $ make install
> >
> > $ cd ${HOME}/tmp/gettext
> > $ ${HOME}/src/gettext-0.18.1.1/configure --prefix=${HOME}/tmp/w32
> > --host=i686-w64-mingw32 --with-libiconv-prefix=${HOME}/tmp/w32
> > $ make
> > ...
> > make[4]: Entering directory
> > `/home/oracle/src/gettext-0.18.1.1/gettext-tools/gnulib-lib'
> > \
> > /bin/sh ../libtool  --tag=CXX   --mode=compile : -DHAVE_CONFIG_H
> > -DEXEEXT=\".exe\" -DEXEEXT=\".exe\" -DEXEEXT=\".exe\" -I. -I..  -I../intl
> > -I../intl -I.. -I.. -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1
> > -DLIBXML_STATIC -I../intl -DGNULIB_DEFINED_GETOPT   -I./libcroco
> >  -I/home/oracle/tmp/w32/include   -c -o
> > ../woe32dll/c++html-styled-ostream.lo
> ../woe32dll/c++html-styled-ostream.cc
> > libtool: compile:  : -DHAVE_CONFIG_H -DEXEEXT=\".exe\" -DEXEEXT=\".exe\"
> > -DEXEEXT=\".exe\" -I. -I.. -I../intl -I../intl -I.. -I..
> > -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -DLIBXML_STATIC -I../intl
> > -DGNULIB_DEFINED_GETOPT -I./libcroco -I/home/oracle/tmp/w32/include -c
> > ../woe32dll/c++html-styled-ostream.cc
> > libtool: compile: mv -f "c++html-styled-ostream.o"
> > "../woe32dll/.libs/c++html-styled-ostream.o"
> > mv: cannot stat `c++html-styled-ostream.o': No such file or directory
> > make[4]: *** [../woe32dll/c++html-styled-ostream.lo] Error 1
> > make[4]: Leaving directory
> > `/home/oracle/src/gettext-0.18.1.1/gettext-tools/gnulib-lib'
> > make[3]: *** [all] Error 2
> > make[3]: Leaving directory
> > `/home/oracle/src/gettext-0.18.1.1/gettext-tools/gnulib-lib'
> > make[2]: *** [all-recursive] Error 1
> > make[2]: Leaving directory
> `/home/oracle/src/gettext-0.18.1.1/gettext-tools'
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory
> `/home/oracle/src/gettext-0.18.1.1/gettext-tools'
> > make: *** [all-recursive] Error 1
> >
> > It seems that libtool running in trouble, but no error messages.
> > Is there any way to debug it ?
> >
> > Regards,
> > Dongsheng
> >
>
> Is this MSYS? I remember an issue about it not liking "+" in the command
> line, I'm not sure if its a libtool issue. I encountered it a few years
> ago, but never investigated further.
>
>
>
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
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 __int128 and Clang

[Dongsheng Song]

On Sun, Apr 8, 2012 at 22:23, Kai Tietz  wrote:
> Proper fix for Clang would be in _mingw.h.in header before the first
> use of __SIZEOF_INT128__.
>
> #if !defined (__SIZEOF_INT128__) && (__clang_major__ ==3) &&
> (__clang_minor__ >= 1)
> #define __SIZEOF_INT128__ 16
> #endif
>

You maybe permit __clang_major__ >=4 .

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANNOUNCEMENT] mingw-w64-headers build behavior changes in trunk (v3)

[Dongsheng Song]

Thanks for inform. But which gcc version default read $PREFIX/include
instead of $PREFIX/$HOST/include ?
>From my memory, *-w64-mingw* gcc do not read $PREFIX/include.

On Mon, Jul 9, 2012 at 7:02 AM, JonY  wrote:
> Hello all,
>
> mingw-w64-headers will now install headers to $PREFIX/include instead of
> $PREFIX/$HOST/include, where $PREFIX is whatever passed to configure for
> --prefix=
>
> The $HOST part is no longer there, please take note and check your
> buildscripts and update your user guides.
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
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.6.3-1-release and Clang 3.1 release by rubenvb

[Dongsheng Song]

I recommend you use '-march=x86-64' instead of  '-march=nocona'.

On Tue, Aug 7, 2012 at 3:24 AM, Ruben Van Boxem
 wrote:
> Hi everyone,
>
> I have finished messing up my scripts and fixing them afterwards. I
> bring you another GCC 4.6.3 build, with MinGW-w64 v2.0.5.
>
> Changes since the last build:
>  - optimization options are for sure -O2 -march=nocona -mtune=core2.
> This means SSE3 is required.
>  - I now build 32-bit to 64-bit *and* 64-bit to 32-bit native
> compilers. They contain some file duplication, but overwriting stuff
> is fine.
>  - I seperated the LLVM/Clang source from the rest.
>  - I made LLVM/Clang (version 3.1) part of the release build. The
> 32-bit version is meant to work with the -dw2 native GCC package. It
> works well. 64-bit is good for C code, not for C++, as exceptions are
> fundamentally broken and linker errors will appear. You can *compile*
> your code to check it with Clang though, which is also important.
>  - I added mingw*env.cmd and clang*env.cmd windows startup scripts:
> double-click and you are in the build environment. Nothing magical,
> just adds bin to PATH for you.
>  - I added isl as a seperate library in preperation of GCC 4.8.
> Nothing interesting for you, the users, though.
>  - some other stuff I am forgetting right now.
>
> Filenames are as follows:
>
> [target triplet]-gcc-[version]-release-[OS]_rubenvb.*
>
> Where OS is the "host" os: win32 means the toolchain is composed of
> 32-bit programs, win64 means 64-bit.
>
> I am now steaming up an experimental GCC 4.8 build, which since
> recently features native Windows x64 SEH. So expect that goodness
> soon.
>
> I have also been put into contact with a darwin toolchain, so there
> may be Mac hosted toolchains showing up in the near future too.
>
> Enjoy,
>
> Ruben
>
> PS: download links:
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/release/
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/release/
> http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Personal%20Builds/rubenvb/release/
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
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.6.3-1-release and Clang 3.1 release by rubenvb

[Dongsheng Song]

On Wed, Aug 8, 2012 at 5:56 PM, Ruben Van Boxem wrote:

> 2012/8/8 Jean-Claude Beaudoin 
>
>>
>>
>> On Wed, Aug 8, 2012 at 1:39 AM, Dongsheng Song 
>> wrote:
>>
>>> I recommend you use '-march=x86-64' instead of  '-march=nocona'.
>>>
>>
> I don't see that option listed 
> here<http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html>,
> although my 32-bit GCC 4.6.3 seems to accept it. "nocona" is the last
> generation P4, Intel's first attempt at x86_64, and AMD's support of it
> isn't much worse. Again, see:
> http://en.wikipedia.org/wiki/SSE3
>
> I build optimized toolchains, and reserve my artistic right to fail on
> older systems (see PS for the very limited cases in which it actually
> matters)
>
>
>From gcc/config/i386/i386.c:processor_alias_table
gcc/config/i386/i386.c:processor_alias_table
  {"prescott", PROCESSOR_NOCONA, CPU_NONE, PTA_MMX | PTA_SSE | PTA_SSE2 |
PTA_SSE3},
  {"nocona",   PROCESSOR_NOCONA, CPU_NONE, PTA_64BIT | PTA_MMX | PTA_SSE |
PTA_SSE2 | PTA_SSE3 | PTA_CX16 | PTA_NO_SAHF},
  {"x86-64",   PROCESSOR_K8, CPU_K8,   PTA_64BIT | PTA_MMX | PTA_SSE |
PTA_SSE2 | PTA_NO_SAHF},

Nocona have PTA_SSE3 and PTA_CX16, this is not acceptable, e.g. pentium3,
pentium4, prescott,
K8, opteron, athlon64 and athlon-fx do not support these instructions.

But x86-64 have SSE2 and common x64 instructions, this should be enough.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Add VS2012 CRT support

[Dongsheng Song]

On Wed, Sep 12, 2012 at 6:14 PM, Kai Tietz  wrote:
> Hello Dongsheng,
>
> patch looks ok.  Just one nit I see.  Within that patch also a change
> to testsuite's make is made.  For that a changelog entry is missing.
>
> Regards,
> Kai
>

I do not change testsuite, I only change Makefile.am, then run autoreconf 2.69,
maybe my autoconf version issue.

You can just apply the patch, revert Makefile.in, then run your own
autoconf tool.

Regards,
Dongsheng

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Add VS2012 CRT support

[Dongsheng Song]

On Wed, Sep 12, 2012 at 8:50 PM, Dongsheng Song
 wrote:
> On Wed, Sep 12, 2012 at 6:14 PM, Kai Tietz  wrote:
>> Hello Dongsheng,
>>
>> patch looks ok.  Just one nit I see.  Within that patch also a change
>> to testsuite's make is made.  For that a changelog entry is missing.
>>
>> Regards,
>> Kai
>>
>
> I do not change testsuite, I only change Makefile.am, then run autoreconf 
> 2.69,
> maybe my autoconf version issue.
>
> You can just apply the patch, revert Makefile.in, then run your own
> autoconf tool.
>
> Regards,
> Dongsheng

Oh, My automake is 1.11.6, mingw-w64 use 1.12.2. please re-generate
Makefile.in yourself.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Add VS2012 CRT support

[Dongsheng Song]

On Wed, Sep 12, 2012 at 9:57 PM, Ozkan Sezer  wrote:
>
> I applied the v2.x patch at rev. 5396.  Thanks.
>
> --
> O.S.
>

I saw you update revstamp.h too, which file generate revstamp.h ?

I also saw jon_y applied to trunk at r5395 without update ChangeLog.

Regards,
Dongsheng

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Compiling packages with MinGW 32 and 64 bits

[Dongsheng Song]

Thank you, now I know how to compile gettext for windows. Why so mystical ?

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Compiling packages with MinGW 32 and 64 bits

[Dongsheng Song]

On Sun, Dec 9, 2012 at 10:35 PM, Dongsheng Song
 wrote:
> Thank you, now I know how to compile gettext for windows. Why so mystical ?

Now gettext 0.18.2 released, I can build it smoothly without any hack !

*) 32bit
${HOME}/src/gettext-0.18.2/configure \
--enable-shared --disable-static \
--prefix=${HOME}/w32 --enable-threads=windows \
--host=i686-w64-mingw32

make -j4; make install

*) 64bit

${HOME}/src/gettext-0.18.2/configure \
--enable-shared --disable-static \
--prefix=${HOME}/w64 --enable-threads=windows \
--host=x86_64-w64-mingw32

make -j4; make install

Regards,
Dongsheng

--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] File format is ambiguous (Matching formats: coff-x86-64 pe-x86-64)

[Dongsheng Song]

It seems that like this old thread revived:

http://www.sourceware.org/ml/binutils/2007-07/msg00469.html

binutils clone from git://sourceware.org/git/binutils.git, version is:

binutils$ git log -3
commit 69fdfc0c99d106a4a49c45185c654c4b6ba72371
Author: Alan Modra 
Date:   Sat Mar 23 23:00:04 2013 +

daily update

$ i686-w64-mingw32-objdump -h dllcrt*.o
i686-w64-mingw32-objdump: dllcrt1.o: File format is ambiguous
i686-w64-mingw32-objdump: Matching formats: coff-x86-64 pe-x86-64
i686-w64-mingw32-objdump: dllcrt2.o: File format is ambiguous
i686-w64-mingw32-objdump: Matching formats: coff-x86-64 pe-x86-64

--
Dongsheng

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] File format is ambiguous (Matching formats: coff-x86-64 pe-x86-64)

[Dongsheng Song]

[BAD]
${BINUTILS_SRC_ROOT}/configure --prefix=${SYS_ROOT} --with-sysroot=${SYS_ROOT} \
--target=i686-w64-mingw32 --enable-targets=all --disable-nls

[GOOD]
${BINUTILS_SRC_ROOT}/configure --prefix=${SYS_ROOT} --with-sysroot=${SYS_ROOT} \
--target=x86_64-w64-mingw32 --enable-targets=all --disable-nls

On Sun, Mar 24, 2013 at 11:07 PM, Dongsheng Song
 wrote:
> It seems that like this old thread revived:
>
> http://www.sourceware.org/ml/binutils/2007-07/msg00469.html
>
> binutils clone from git://sourceware.org/git/binutils.git, version is:
>
> binutils$ git log -3
> commit 69fdfc0c99d106a4a49c45185c654c4b6ba72371
> Author: Alan Modra 
> Date:   Sat Mar 23 23:00:04 2013 +
>
> daily update
>
> $ i686-w64-mingw32-objdump -h dllcrt*.o
> i686-w64-mingw32-objdump: dllcrt1.o: File format is ambiguous
> i686-w64-mingw32-objdump: Matching formats: coff-x86-64 pe-x86-64
> i686-w64-mingw32-objdump: dllcrt2.o: File format is ambiguous
> i686-w64-mingw32-objdump: Matching formats: coff-x86-64 pe-x86-64
>
> --
> Dongsheng

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mass rebuild report for April 27 2013

[Dongsheng Song]

Here is the root cause.

gettext use C linkage at gettext-runtime/libasprintf/vasprintf.h:

#ifdef __cplusplus
extern "C" {
#endif

/* Write formatted output to a string dynamically allocated with malloc().
   If the memory allocation succeeds, store the address of the string in
   *RESULT and return the number of resulting bytes, excluding the trailing
   NUL.  Upon memory allocation error, or some other error, return -1.  */
extern int asprintf (char **result, const char *format, ...)
   __attribute__ ((__format__ (__printf__, 2, 3)));
extern int vasprintf (char **result, const char *format, va_list args)
   __attribute__ ((__format__ (__printf__, 2, 0)));

#ifdef __cplusplus
}
#endif

On stdio.h, mingw-w64 use C++ linkage:

/* There seems to be a bug about builtins and static overrides of them
   in g++.  So we need to do here some trickery.  */
#ifdef __cplusplus
extern "C++" {
#endif
...
#ifdef _GNU_SOURCE
__mingw_ovr
__attribute__ ((__format__ (gnu_printf, 2, 3))) __attribute__((nonnull (1,2)))
int asprintf(char **__ret, const char *__format, ...)
{
  register int __retval;
  __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
  __retval = __mingw_vasprintf( __ret, __format, __local_argv );
  __builtin_va_end( __local_argv );
  return __retval;
}

__mingw_ovr
__attribute__ ((__format__ (gnu_printf, 2, 0))) __attribute__((nonnull (1,2)))
int vasprintf(char **__ret, const char *__format, __builtin_va_list
__local_argv)
{
  return __mingw_vasprintf( __ret, __format, __local_argv );
}
#endif /* _GNU_SOURCE */
...

I think mingw-w64 should not use C++ linkage for these C functions
when use C++ compiler.


On Sat, Apr 27, 2013 at 9:04 PM, JonY  wrote:
> On 4/27/2013 20:54, Erik van Pienbroek wrote:
 /usr/i686-w64-mingw32/sys-root/mingw/include/stdio.h:319:5: error:
 previous declaration of 'int asprintf(char**, const char*, ...)' with 'C
 ++' linkage
  int asprintf(char **__ret, const char *__format, ...)
  ^
 In file included
 from ../../../gettext-runtime/libasprintf/lib-asprintf.h:30:0,

 from ../../../gettext-runtime/libasprintf/autosprintf.cc:31:
 ../../../gettext-runtime/libasprintf/vasprintf.h:45:54: error: conflicts
 with new declaration with 'C' linkage
 __attribute__ ((__format__ (__printf__, 2, 3)));

 This looks like a change in mingw-w64 regarding the declaration of
 asprintf. Could one of the mingw-w64 devs take a look at this and
 indicate whether this should be fixed in mingw-w64 itself or in gettext?

>>>
>>> Hi,
>>>
>>> Can you retry? This was fixed very recently, depending on your timezone,
>>> it may be on the 25th or 26th.
>>
>> The mass-rebuild was done against mingw-w64 trunk r5820 (I just verified
>> this to be absolutely certain). This is still the latest mingw-w64
>> commit at the time of writing this mail so I guess the problem is still
>> there.
>>
>
> Can you check if gettext is actually checking if asprintf is available
> or is it just assuming it is going to be missing for mingw?
>
>
>
> --
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] GCC 4.8 for W32 use __udivdi3 and __umoddi3 in libgcc_s_sjlj-1.dll but not libgcc

[Dongsheng Song]

Hi,

Wen I use gcc 4.8 for win32, I fount gcc use __udivdi3 and __umoddi3
in libgcc_s_sjlj-1.dll but not libgcc, how can avoid it, use gcc 4.7 behavior ?

DLL Name: libgcc_s_sjlj-1.dll
vma:  Hint/Ord Member-Name Bound-To
22248 119  __udivdi3
22254 121  __umoddi3

Regards,
Dongsheng

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
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.8 for W32 use __udivdi3 and __umoddi3 in libgcc_s_sjlj-1.dll but not libgcc

[Dongsheng Song]

Here is example:

$ cat t-w32.c
long long do_div(long long a, long long b)
{
  return a/b;
}

i686-w64-mingw32-gcc -shared -o t-w32.dll t-w32.c
i686-w64-mingw32-objdump -x t-w32.dll  | grep "DLL Name"

gcc 4.8:
DLL Name: libgcc_s_sjlj-1.dll
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll

gcc 4.7:
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll

Then I investgate why the gcc 4.8 output dll use libgcc_s_sjlj-1.dll, I found
t-w32.dll use the following symbols in libgcc_s_sjlj-1.dll:

i686-w64-mingw32-objdump -x t-w32.dll  | less

DLL Name: libgcc_s_sjlj-1.dll
vma:  Hint/Ord Member-Name Bound-To
c200   41  __divdi3
c20c  119  __udivdi3
c218  121  __umoddi3

I think this is a regress, isn't it ?


On Mon, Apr 29, 2013 at 11:37 PM, LRN  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 29.04.2013 19:28, Dongsheng Song wrote:
>> Hi,
>>
>> Wen I use gcc 4.8 for win32, I fount gcc use __udivdi3 and
>> __umoddi3 in libgcc_s_sjlj-1.dll but not libgcc, how can avoid
>> it, use gcc 4.7 behavior ?
> What did gcc-4.7 do?
>
> Also, what do you mean by "but not libgcc"? "but not libgcc-1.dll"?
> "but not libgcc_s_dw2-1.dll"? What?
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (MingW32)
>
> iQEcBAEBAgAGBQJRfpPOAAoJEOs4Jb6SI2Cwb4QIANjfkReyNqQO4sY0V6qbBd9m
> 5eCgfdb96sUp6bPJTsWwH3bUmwY1L8pWD2TSRAYyeqIc6sB1Aetaosc+p3hzc3at
> +fvI4PaYb8g1clmGUY148yUYtXFi5X59gXkUUqsrgyy4UbUCe3NMvjbEtDfTDq1s
> lnEEUmJIuk6x5Ctx2pjeiiiHSn2G4oFQT6PFMiCrO1iRDQenHtHxEsOvzLOFTYIp
> yA2tpI3a/NP4uxVtBrxjaoVl1eX3tn7oLxUwTZ4VkcpkK2TXCkYd6sFo1RG2jIHc
> uq3apXuQAUJxU5ADyFxcvqpbFVVoL78IViyINI4zT08rL28jnKgTKaFoF8+yiZk=
> =iX5M
> -END PGP SIGNATURE-
>
> --
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
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.8 for W32 use __udivdi3 and __umoddi3 in libgcc_s_sjlj-1.dll but not libgcc

[Dongsheng Song]

On Mon, Apr 29, 2013 at 11:53 PM, Dongsheng Song
 wrote:
> Here is example:
>
> $ cat t-w32.c
> long long do_div(long long a, long long b)
> {
>   return a/b;
> }
>
> i686-w64-mingw32-gcc -shared -o t-w32.dll t-w32.c
> i686-w64-mingw32-objdump -x t-w32.dll  | grep "DLL Name"
>
> gcc 4.8:
> DLL Name: libgcc_s_sjlj-1.dll
> DLL Name: KERNEL32.dll
> DLL Name: msvcrt.dll
>
> gcc 4.7:
> DLL Name: KERNEL32.dll
> DLL Name: msvcrt.dll
>
> Then I investgate why the gcc 4.8 output dll use libgcc_s_sjlj-1.dll, I found
> t-w32.dll use the following symbols in libgcc_s_sjlj-1.dll:
>
> i686-w64-mingw32-objdump -x t-w32.dll  | less
>
> DLL Name: libgcc_s_sjlj-1.dll
> vma:  Hint/Ord Member-Name Bound-To
> c200   41  __divdi3
> c20c  119  __udivdi3
> c218  121  __umoddi3
>
> I think this is a regress, isn't it ?
>

I found in gcc/config/i386/mingw32.h:

/* Include in the mingw32 libraries with libgcc */
#ifdef ENABLE_SHARED_LIBGCC
#define SHARED_LIBGCC_SPEC " \
 %{static|static-libgcc:-lgcc -lgcc_eh} \
 %{!static: \
   %{!static-libgcc: \
 %{!shared: \
   %{!shared-libgcc:-lgcc -lgcc_eh} \
   %{shared-libgcc:-lgcc_s -lgcc} \
  } \
 %{shared:-lgcc_s -lgcc} \
} \
  } "
#else
#define SHARED_LIBGCC_SPEC " -lgcc "
#endif

If I change '-lgcc_s -lgcc' to '-lgcc -lgcc_s', then gcc 4.8 will not
use such symbols like
__divdi3 in libgcc_s_sjlj-1.dll, it back to gcc 4.7 behavior.

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
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.8 for W32 use __udivdi3 and __umoddi3 in libgcc_s_sjlj-1.dll but not libgcc

[Dongsheng Song]

On Tue, Apr 30, 2013 at 6:13 AM, JonY  wrote:
> On 4/30/2013 00:15, Dongsheng Song wrote:
>>
>> If I change '-lgcc_s -lgcc' to '-lgcc -lgcc_s', then gcc 4.8 will not
>> use such symbols like
>> __divdi3 in libgcc_s_sjlj-1.dll, it back to gcc 4.7 behavior.
>>
>
> I think this is a deliberate change and not a bug, have you tried
> -static-libgcc instead?
>

It not works. Because both lib/libgcc_s.a (libgcc_s_sjlj-1.dll）and
lib/gcc/i686-w64-mingw32/4.8.1/libgcc.a
export these symbols:

___absvdi2
___absvsi2
___addtf3
___addvdi3
___addvsi3
___ashldi3
___ashrdi3
___bswapdi2
___bswapsi2
___clear_cache
___clrsbdi2
___clrsbsi2
___clzdi2
___clzsi2
___cmpdi2
___ctzdi2
___ctzsi2
___divdc3
___divdi3
___divsc3
___divtc3
___divtf3
___divxc3
___enable_execute_stack
___eqtf2
___extenddftf2
___extendsftf2
___extendxftf2
___ffsdi2
___ffssi2
___fixdfdi
___fixsfdi
___fixtfdi
___fixtfsi
___fixunsdfdi
___fixunsdfsi
___fixunssfdi
___fixunssfsi
___fixunstfdi
___fixunstfsi
___fixunsxfdi
___fixunsxfsi
___fixxfdi
___floatdidf
___floatdisf
___floatditf
___floatdixf
___floatsitf
___floatundidf
___floatundisf
___floatunditf
___floatundixf
___floatunsitf
___getf2
___gttf2
___letf2
___lshrdi3
___lttf2
___moddi3
___muldc3
___muldi3
___mulsc3
___multc3
___multf3
___mulvdi3
___mulvsi3
___mulxc3
___negdi2
___negtf2
___negvdi2
___negvsi2
___netf2
___paritydi2
___paritysi2
___popcountdi2
___popcountsi2
___powidf2
___powisf2
___powitf2
___powixf2
___subtf3
___subvdi3
___subvsi3
___trunctfdf2
___trunctfsf2
___trunctfxf2
___ucmpdi2
___udivdi3
___udivmoddi4
___umoddi3
___unordtf2

So I think this change is hastily, should be rollback, or make
libgcc_s${LIBGCC_EH_EXTN}-1.dll
DO NOT export extra symbols which not owned their self.

--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [RFC] Change the default size of time_t and off_t

[Dongsheng Song]

Since Visual C++ 2005 (released in November 2005), time_t is now a
64-bit integer by default [1] . But mingw-w64 still use 32-bit integer
by default on 32 bit Windows. I recommend use 64-bit integer by
default on 3.0 CRT.

mingw-w64 use off_t 32-bit integer on 64 bit Windows, I think this is a mistake.

[1] http://msdn.microsoft.com/en-us/library/3b2e7499.aspx

--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] time == _time64 in .DEF not working on MS lib.exe

[Dongsheng Song]

Hi,

mingw-w64 use lots of '==' to redirect symbols, e.g.

time == _time64

dlltool -x -c -k -m i386 --input-def libtest.def  --dllname
libtest.dll  --output-lib libtest.dll.a

lib /NOLOGO /DEF:libtest.def   /OUT:libtest.lib  /MACHINE:X86

But only dlltool works correctly, MS lib.exe not works, is there a
equipment in MS lib.exe ?

Regards,
Dongsheng

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Regression in trunk regarding InterlockedCompareExchange

[Dongsheng Song]

On Fri, May 24, 2013 at 5:29 AM, Erik van Pienbroek
 wrote:
> Hi,
>
> During review of one of our Fedora packages we noticed an unexpected
> change in behavior in recent mingw-w64 trunk snapshots. We noticed that
> several libraries which were built against recent mingw-w64 trunk
> snapshots suddenly started to export the symbols
> _InterlockedCompareExchange and InterlockedCompareExchange@12 in their
> shared libraries.
>
> Libraries which now show this behavior in Fedora are:
> * libasprintf-0.dll (gettext)
> * libcrypto-10.dll (openssl)
> * libffi-6.dll
> * libgmp-10.dll
> * libgnutls-xssl-0.dll
> * libgnutlsxx-28.dll
> * libintl-8.dll (gettext)
> * libobjc-4.dll (gcc)
> * libpixman-1-0.dll
> * libspice-controller-0.dll (spice)
> * libsqlite3-0.dll
> * libusb-1.0.dll (libusbx)
> * QtUiTools4.dll (qt4)
>
> The thing all these libraries have in common that they were built
> against recent mingw-w64 snapshots.
>
> The issue can be illustrated by opening the dll in question in
> dependency walker or by running objdump:
>
> i686-w64-mingw32-objdump
> -p /usr/i686-w64-mingw32/sys-root/mingw/bin/libsqlite3-0.dll | grep -B1
> Interlocked
> [Ordinal/Name Pointer] Table
> [   0] InterlockedCompareExchange@12
> [   1] _InterlockedCompareExchange
>
> So far I've only seen this happening for the i686-w64-mingw32 target. I
> can't confirm yet if it also is happening on x86_64-w64-mingw32.
>

Yes, I can see this happening for the i686-w64-mingw32 target for
compile glib 2.36.2, but x86_64-w64-mingw32 target not take effected.
It's really annoying.

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] How to specify exception module separately when build gcc 4.8

[Dongsheng Song]

When I build gcc 4.8 with mingw-w64 trunk:

${GCC_SRC_ROOT}/configure \
--prefix=${SYS_ROOT} \
--with-sysroot=${SYS_ROOT} \
--build=${BUILD_TRIPLET} --host=${BUILD_TRIPLET}
--target=${TARGET_TRIPLET} \
--enable-targets=all --disable-nls \
--enable-checking=release --enable-languages=c,c++,fortran

If TARGET_TRIPLET is x86_64-w64-mingw32, the building works good.

When TARGET_TRIPLET is i686-w64-mingw32, I got errors:

/home/cauchy/obj/i686-w64-mingw32/gcc/./gcc/xgcc
-B/home/cauchy/obj/i686-w64-mingw32/gcc/./gcc/
-L/home/cauchy/cross/i686-windows/i686-w64-mingw32/lib
-L/home/cauchy/cross/i686-windows/mingw/lib -isystem
/home/cauchy/cross/i686-windows/i686-w64-mingw32/include -isystem
/home/cauchy/cross/i686-windows/mingw/include
-B/home/cauchy/cross/i686-windows/i686-w64-mingw32/bin/
-B/home/cauchy/cross/i686-windows/i686-w64-mingw32/lib/ -isystem
/home/cauchy/cross/i686-windows/i686-w64-mingw32/include -isystem
/home/cauchy/cross/i686-windows/i686-w64-mingw32/sys-include-g -O2
-m64 -O2 
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/../winsup/w32api/include
-g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -I. -I. -I../../.././gcc
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/.
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/../gcc
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/../include
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2.o
-MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind-dw2.c
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind-dw2.c:1698:0:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_RaiseException_Phase2':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:51:60:
error: 'struct _Unwind_Exception' has no member named 'private_2'
   match_handler = (uw_identify_context (context) == exc->private_2
^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_RaiseException':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:127:6:
error: 'struct _Unwind_Exception' has no member named 'private_1'
   exc->private_1 = 0;
  ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:128:6:
error: 'struct _Unwind_Exception' has no member named 'private_2'
   exc->private_2 = uw_identify_context (&cur_context);
  ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_ForcedUnwind_Phase2':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:145:61:
error: 'struct _Unwind_Exception' has no member named 'private_1'
   _Unwind_Stop_Fn stop = (_Unwind_Stop_Fn) (_Unwind_Ptr) exc->private_1;
 ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:146:51:
error: 'struct _Unwind_Exception' has no member named 'private_2'
   void *stop_argument = (void *) (_Unwind_Ptr) exc->private_2;
   ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_ForcedUnwind':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:204:6:
error: 'struct _Unwind_Exception' has no member named 'private_1'
   exc->private_1 = (_Unwind_Ptr) stop;
  ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:205:6:
error: 'struct _Unwind_Exception' has no member named 'private_2'
   exc->private_2 = (_Unwind_Ptr) stop_argument;
  ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_Resume':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:229:10:
error: 'struct _Unwind_Exception' has no member named 'private_1'
   if (exc->private_1 == 0)
  ^
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc: In
function '_Unwind_Resume_or_Rethrow':
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/libgcc/unwind.inc:251:10:
error: 'struct _Unwind_Exception' has no member named 'private_1'
   if (exc->private_1 == 0)
  ^
make[4]: *** [unwind-dw2.o] Error 1
make[4]: Leaving directory
`/home/cauchy/obj/i686-w64-mingw32/gcc/i686-w64-mingw32/64/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory
`/home/cauchy/obj/i686-w64-mingw32/gcc/i686-w64-mingw32/libgcc'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory
`/home/cauchy/obj/i686-w64-mingw32/gcc/i686-w64-mingw32/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Le

[Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?

[Dongsheng Song]

I can build i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc under
Linux, but when I use this compiler to compile native Windows
compiler, gcc 4.7 success, gcc 4.8 failed with same build script like
this:

make[2]: Entering directory `/home/cauchy/obj/native/gcc-4.8-win32/gcc/gcc'
g++ -c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/build
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../include
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../libcpp/include
-I/home/cauchy/native/gcc-4.8-win32-3rd/include
-I/home/cauchy/native/gcc-4.8-win32-3rd/include
-I/home/cauchy/native/gcc-4.8-win32-3rd/include
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../libdecnumber
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../libdecnumber/bid
-I../libdecnumber
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../libbacktrace
   \
-o build/genconstants.o
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c
In file included from /usr/include/x86_64-linux-gnu/sys/resource.h:25:0,
 from /usr/include/x86_64-linux-gnu/sys/wait.h:32,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:352,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/usr/include/x86_64-linux-gnu/bits/resource.h:133:18: error:
declaration does not declare anything [-fpermissive]
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:0:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:444:23:
error: declaration of C function ‘void* sbrk(int)’ conflicts with
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:254:0,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/usr/include/unistd.h:1056:14: error: previous declaration ‘void*
sbrk(intptr_t)’ here
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:0:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:448:48:
error: new declaration ‘char* strstr(const char*, const char*)’
In file included from /usr/include/c++/4.7/cstring:44:0,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:205,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/usr/include/string.h:335:1: error: ambiguates old declaration ‘const
char* strstr(const char*, const char*)’
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:0:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:500:34:
error: declaration of C function ‘const char* strsignal(int)’
conflicts with
In file included from /usr/include/c++/4.7/cstring:44:0,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:205,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/usr/include/string.h:566:14: error: previous declaration ‘char*
strsignal(int)’ here
In file included from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:645:0,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/../include/libiberty.h:110:36:
error: new declaration ‘char* basename(const char*)’
In file included from /usr/include/c++/4.7/cstring:44:0,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/system.h:205,
 from
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/gcc/genconstants.c:28:
/usr/include/string.h:603:28: error: ambiguates old declaration ‘const
char* basename(const char*)’
make[2]: *** [build/genconstants.o] Error 1
make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.8-win32/gcc/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.8-win32/gcc'
make: *** [all] Error 2

Regards,
Dongsheng

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public