Re: [Mingw-w64-public] ERROR_SYMLINK_NOT_SUPPORTED missing in the headers (winerror.h)
Hello Luis, ERROR_SYMLINK_NOT_SUPPORTED is missing. We will add it soon. Thanks for reporting, Kai -- 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
[Mingw-w64-public] ERROR_SYMLINK_NOT_SUPPORTED missing in the headers (winerror.h)
Hello, When using -D_WIN32_WINNT=0x0600 to use Vista+ definitions, it seems ERROR_SYMLINK_NOT_SUPPORTED (1464L) appears to be missing. I checked winerror.h in trunk and compared with MSDN list of errors: http://msdn.microsoft.com/en-us/library/windows/desktop/ms681385(v=vs.85).aspx Or I'm missing something? Thank you. -- 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 -- 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] winpthreads patch for pthread_getspecific()/pthread_setspecific() function for restore WIN last error code
2012/7/16 Kai Tietz: > Well, > > I am fine by this patch, but I would love to get additional a testcase > added for it. > > So patch is ok with a testcase. Log in attachment. -- Regards, niXman ___ Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows: http://sourceforge.net/projects/mingwbuilds/ rm -f *.dll rm -f *.lib rm -f pthread.h rm -f semaphore.h rm -f sched.h rm -f *.a rm -f *.e rm -f *.i rm -f *.o rm -f *.so rm -f *.obj rm -f *.pdb rm -f *.exe rm -f *.pass rm -f *.fail rm -f *.x rm -f *.bench rm -f *.static rm -f *.log Copying ../.libs/libwinpthread.dll.a Copying ../.libs/libwinpthread-1.dll make -k TEST=GC CC=-gcc XXCFLAGS="-D__CLEANUP_C" all-pass make[1]: Entering directory `/usr/home/niXman/build/tests' Compiling runall.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o runall.exe runall.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running runall ./runall usage: runall Passed Compiling sizes.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o sizes.exe sizes.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running ./sizes.exe > SIZES.GC Sizes of winpthreads structs --- pthread_t4 pthread_attr_t_ 16 pthread_mutex_t_ 28 pthread_mutexattr_t_4 pthread_spinlock_t_ 12 pthread_barrier_t_ 36 pthread_barrierattr_t_4 pthread_key_t_4 pthread_cond_t_ 108 pthread_condattr_t_4 pthread_rwlock_t_ 32 pthread_rwlockattr_t_4 pthread_once_t_4 sched_param4 --- Passed Compiling loadfree.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o loadfree.exe loadfree.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 loadfree.c: In function 'main': loadfree.c:61:13: warning: unused variable 'hinst' [-Wunused-variable] Preparing loadfree TESTS Running loadfree ./loadfree Passed Compiling self1.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o self1.exe self1.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running self1 ./self1 Passed Compiling mutex5.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex5.exe mutex5.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running mutex5 ./mutex5 Passed Compiling mutex1.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex1.exe mutex1.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running mutex1 ./mutex1 Passed Compiling mutex1e.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex1e.exe mutex1e.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running mutex1e ./mutex1e Passed Compiling mutex1n.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex1n.exe mutex1n.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running mutex1n ./mutex1n Passed Compiling mutex1r.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex1r.exe mutex1r.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running mutex1r ./mutex1r Passed Compiling semaphore1.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o semaphore1.exe semaphore1.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running semaphore1 ./semaphore1 thread: sem_trywait 1: expecting error EAGAIN: got EAGAIN thread: ok 2 main: sem_trywait 1: expecting error EAGAIN: got EAGAIN main: ok 2 Passed Compiling semaphore2.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o semaphore2.exe semaphore2.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running semaphore2 ./semaphore2 Passed Compiling semaphore3.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o semaphore3.exe semaphore3.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running semaphore3 ./semaphore3 Complete Passed Compiling condvar1.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o condvar1.exe condvar1.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running condvar1 ./condvar1 Passed Compiling condvar1_1.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o condvar1_1.exe condvar1_1.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running condvar1_1 ./condvar1_1 Passed Compiling condvar1_2.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o condvar1_2.exe condvar1_2.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Compiling join2.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o join2.exe join2.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Compiling create1.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o create1.exe create1.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Compiling mutex2.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o mutex2.exe mutex2.c -I./include -L../outlib -lwinpthread -lsupc++ -lws2_32 Running mutex2 ./mutex2 Try lock Mutex locked Mutex unlocked Mutex destroyed Passed Running create1 ./create1 Passed Running join2 ./join2 Passed Running condvar1_2 ./condvar1_2 Passed Compiling condvar2.exe -gcc -O3 -UNDEBUG -Wall -D__CLEANUP_C -o condvar2.exe condvar2.c -I./
Re: [Mingw-w64-public] [patch] ddk: Replace all unsigned long with ULONG
2012/7/17 Corinna Vinschen : > Hi, > > as proposed on IRC, the below patch replaces all usage of unsigned long > in the ddk subdir with ULONG. Ok to apply? > > > Thanks, > Corinna Patch is ok. Thanks, Kai -- 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
[Mingw-w64-public] [patch] ddk: Replace all unsigned long with ULONG
Hi,
as proposed on IRC, the below patch replaces all usage of unsigned long
in the ddk subdir with ULONG. Ok to apply?
Thanks,
Corinna
* include/ddrawint.h (MAKE_HRESULT): Define in terms of ULONG
instead of unsigned long.
* include/ddk/scsiwmi.h (struct _GUID): Define Data1 as ULONG.
* include/ddk/d4iface.h (CHANNEL_HANDLE, *PCHANNEL_HANDLE): Define
based on ULONG.
* include/ddk/ntstrsafe.h (DWORD): Ditto.
Index: include/ddrawint.h
===
--- include/ddrawint.h (revision 5223)
+++ include/ddrawint.h (working copy)
@@ -69,7 +69,7 @@
#endif
#ifndef MAKE_HRESULT // fixme this if statment should not be here, but
MAKE_HRESULT should be here
-#define MAKE_HRESULT(sev,fac,code) ((HRESULT) (((unsigned long)(sev)<<31) |
((unsigned long)(fac)<<16) | ((unsigned long)(code))) )
+#define MAKE_HRESULT(sev,fac,code) ((HRESULT) (((ULONG)(sev)<<31) |
((ULONG)(fac)<<16) | ((ULONG)(code))) )
#endif
#ifndef FLATPTR_DEFINED
Index: include/ddk/scsiwmi.h
===
--- include/ddk/scsiwmi.h (revision 5223)
+++ include/ddk/scsiwmi.h (working copy)
@@ -47,7 +47,7 @@
#if ! (defined _GUID_DEFINED || defined GUID_DEFINED)
#define GUID_DEFINED
typedef struct _GUID {
-unsigned long Data1;
+ULONG Data1;
unsigned short Data2;
unsigned short Data3;
unsigned char Data4[ 8 ];
Index: include/ddk/d4iface.h
===
--- include/ddk/d4iface.h (revision 5223)
+++ include/ddk/d4iface.h (working copy)
@@ -31,7 +31,7 @@
#define CONFIG_UPLOAD 14
#define CONFIG_DOWNLOAD15
-typedef unsigned long CHANNEL_HANDLE, *PCHANNEL_HANDLE;
+typedef ULONG CHANNEL_HANDLE, *PCHANNEL_HANDLE;
typedef struct _DOT4_ACTIVITY {
ULONG ulMessage;
Index: include/ddk/ntstrsafe.h
===
--- include/ddk/ntstrsafe.h (revision 5223)
+++ include/ddk/ntstrsafe.h (working copy)
@@ -29,7 +29,7 @@
//
// Typedefs
//
-typedef unsigned long DWORD;
+typedef ULONG DWORD;
/* PRIVATE FUNCTIONS */
--
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] [patch] _mingw_mac.h: Redefine __MSABI_LONG for LP64
2012/7/17 Corinna Vinschen : > Hi, > > per the subject, patch below. Ok to apply? > > > Thanks, > Corinna Yes, patch is ok. Thanks, Kai -- 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
[Mingw-w64-public] [patch] _mingw_mac.h: Redefine __MSABI_LONG for LP64
Hi, per the subject, patch below. Ok to apply? Thanks, Corinna * _mingw_mac.h (__MSABI_LONG): Define for LP64 systems as well. Index: _mingw_mac.h === --- _mingw_mac.h(revision 5225) +++ _mingw_mac.h(working copy) @@ -165,8 +165,12 @@ #endif #ifndef __MSABI_LONG +#ifndef __LP64__ #define __MSABI_LONG(x) x ## l +#else +#define __MSABI_LONG(x) x #endif +#endif #if __GNUC__ #define __MINGW_GCC_VERSION(__GNUC__ * 1 + \ -- 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] [patch] _mingw.h: Introduce the __32LONG macro
On Jul 16 17:25, Corinna Vinschen wrote: > On Jul 16 15:56, Kai Tietz wrote: > > Well, > > > > I would like to have here one define for long, which is then later on > > used consistently to replace use of 'long' type. I don't see much > > advantage in adding here a signed and a unsigned variant to _mingw.h > > header. We want to replace use of 'long' keyword. > > So by this, the keyword 'long' define isn't the same as the boolean > > type. So I am a bit opposed against the WIN prefix. IMHO it > > should be a define with two leading underscores, unlikely to be mixed > > with a destinguished type. So my vote goes all for __32LONG, but I am > > __32LONG or __LONG32? Applied as __LONG32 per the yesterday's discussion on IRC. Corinna -- 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
[Mingw-w64-public] (RESEND) #include causes formatting problems with PRId64
I'm resending this. I have a work-around, which involves putting PRId64 in a
global variable, but that doesn't seem right. Is there a bug in the #include
files?
Simson
When I #include with mingw64-g++ the PRId64 value is no longer
interpreted correctly.
Here is the test program:
#define __STDC_FORMAT_MACROS
#include
#include
#include
#include
#include
#include
int main(int argc,char **argv)
{
uint64_t val=1234567890;
printf("%"PRId64"\n",val);
exit(0);
}
[simsong@FC17 ~]$ x86_64-w64-mingw32-g++ -Wall x.cpp
x.cpp: In function 'int main(int, char**)':
x.cpp:19:29: warning: unknown conversion type character 'l' in format [-Wformat]
x.cpp:19:29: warning: too many arguments for format [-Wformat-extra-args]
[simsong@FC17 ~]$
But if I change the test program to this:
#define __STDC_FORMAT_MACROS
#include
#include
#include
#include
#include
//#include
int main(int argc,char **argv)
{
uint64_t val=1234567890;
printf("%"PRId64"\n",val);
exit(0);
}
Then I have no problem compiling:
[simsong@FC17 ~]$ x86_64-w64-mingw32-g++ -Wall x.cpp
[simsong@FC17 ~]$
[simsong@FC17 ~]$ x86_64-w64-mingw32-g++ --version
x86_64-w64-mingw32-g++ (GCC) 4.7.0 20120322 (Fedora MinGW 4.7.0-2.fc17)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[simsong@FC17 ~]$
This makes no sense to me. Is this a bug?
--
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] include: fix mingw64 build
On 07/16/12 15:33, Jacek Caban wrote: > On 07/16/12 14:26, Ozkan Sezer wrote: >> On Mon, Jul 16, 2012 at 3:03 PM, JonY wrote: >>> On 7/16/2012 19:10, JonY wrote: On 7/16/2012 18:46, Ozkan Sezer wrote: > On Mon, Jul 16, 2012 at 1:38 PM, JonY wrote: >> On 7/16/2012 17:19, Jacek Caban wrote: >>> Sorry about that, I treat my git repository as a temporary place for >>> patch reviews, so they may disappear once I push new versions. Here is a >>> link to a patch already committed to the trunk (which should be >>> persistent since it's already in mingw-w64): >>> >>> http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/8c4da30fd44a7a47e7ba64a0c461d409146b6ae3 >>> >>> Jacek >>> >>> >> Looks like there are a lot of changes, but mostly cosmetic changes and >> moving things about, not exactly new stuff. >> >> Is the change part of a series of change? Are there any actual >> functionality change? >> >> If so, backporting might not be a good idea. If not, I'm OK with >> backporting, but Kai and Ozkan should comment on it first. >> > IIRC, the patch didn't do any functionality changes. I'm OK with the > admins' > decisions on this one. > On closer inspection, it looks like all it does is fix a cross compile case with Wine, no real change to mingw-w64 itself, I'd say it's good to go. Kai? >>> Hi Ozkan, >>> >>> Kai approved by IRC, so feel free to commit the backport. >> I believe I told Jacek that he can commit the backport. >> > Yeah, approval is all I need. I will backport it soon. > Tested and committed as r5227. Jacek -- 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
