Re: [Mingw-w64-public] half-missing API

On Sat, Dec 22, 2012 at 6:21 PM, Jim Michaels wrote: > these do not exist. they are used for fixing and getting specialfolder > paths in vista+ > //SHGetKnownFolderPath > http://msdn.microsoft.com/en-us/library/bb762188%28v=vs.85%29.aspx > //KNOWN_FOLDER_FLAG > http://msdn.microso

Re: [Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

2012/12/22 Jacek Caban : > On 12/22/12 8:41 PM, Ruben Van Boxem wrote: > > 2012/12/22 Jacek Caban >> >> On 12/22/12 1:43 PM, Ruben Van Boxem wrote: >> >> 2012/12/22 Jacek Caban >>> >>> On 12/22/12 12:23 PM, Kai Tietz wrote: >>> > Please include first the windows.h header, and then do other includ

Re: [Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

On 12/22/12 8:41 PM, Ruben Van Boxem wrote: 2012/12/22 Jacek Caban > On 12/22/12 1:43 PM, Ruben Van Boxem wrote: 2012/12/22 Jacek Caban mailto:ja...@codeweavers.com>> On 12/22/12 12:23 PM, Kai Tietz wrote: > Please include first the windows

Re: [Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

2012/12/22 Jacek Caban > On 12/22/12 1:43 PM, Ruben Van Boxem wrote: > > 2012/12/22 Jacek Caban > >> On 12/22/12 12:23 PM, Kai Tietz wrote: >> > Please include first the windows.h header, and then do other includes. >> > >> > There is nothing to fix on mingw-w64's side. It might be a >> > gc

Re: [Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

On 12/22/12 1:43 PM, Ruben Van Boxem wrote: 2012/12/22 Jacek Caban > On 12/22/12 12:23 PM, Kai Tietz wrote: > Please include first the windows.h header, and then do other includes. > > There is nothing to fix on mingw-w64's side. It might be a

Re: [Mingw-w64-public] libgomp build failure

Hmm. Might even be a quantum fluctuation; the i686-w64-mingw32 build just completed without a hitch :S... Thanks for taking a look. Ruben 2012/12/22 Kai Tietz > Hmm, by looking into config.log files, I don't see actual that one of > those variables isn't set. So something on replacement see

Re: [Mingw-w64-public] libgomp build failure

Hmm, by looking into config.log files, I don't see actual that one of those variables isn't set. So something on replacement seems to go wrong ... no idea why. Cheers, Kai --- libtool ... you always need to solve issues, you wouldn't have without it ... ---

Re: [Mingw-w64-public] libgomp build failure

This might be caused by one of those: _AC_COMPUTE_INT([sizeof (omp_lock_t)], [OMP_LOCK_SIZE],, [AC_MSG_ERROR([unsupported system, cannot find sizeof (omp_lock_t)])]) _AC_COMPUTE_INT([__alignof (omp_lock_t)], [OMP_LOCK_ALIGN]) _AC_COMPUTE_INT([sizeof (omp_nest_lock_t)], [OMP_NEST_LOCK_SIZE]) _AC_

Re: [Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

2012/12/22 Jacek Caban > On 12/22/12 12:23 PM, Kai Tietz wrote: > > Please include first the windows.h header, and then do other includes. > > > > There is nothing to fix on mingw-w64's side. It might be a > > gcc-intrinsic header bug, as API should be artificial but still has > > language-bindi

Re: [Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

On 12/22/12 12:23 PM, Kai Tietz wrote: > Please include first the windows.h header, and then do other includes. > > There is nothing to fix on mingw-w64's side. It might be a > gcc-intrinsic header bug, as API should be artificial but still has > language-binding. AFAIR there is already a bug-rep

Re: [Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

Please include first the windows.h header, and then do other includes. There is nothing to fix on mingw-w64's side. It might be a gcc-intrinsic header bug, as API should be artificial but still has language-binding. AFAIR there is already a bug-report on gcc's bz about that. See Windows.cpp: li

[Mingw-w64-public] MinGW-w64 trunk ia32intrin C++ problem

Hi, I'm testing trunk MinGW-w64 and GCC trunk, and running into this issue compiling my personal project: In file included from m:\development\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.0\include\x86intrin.h:27:0, from m:\development\mingw64\include\c++\4.8.0\bits\opt_random.h:33,