Re: [Mingw-w64-public] Problem with math.h?
On 8/30/2010 6:09 PM, Ozkan Sezer wrote: > On Mon, Aug 30, 2010 at 6:04 PM, Vasilakis wrote: >> On 8/30/2010 5:57 PM, Ozkan Sezer wrote: >>> On Mon, Aug 30, 2010 at 5:49 PM, Vasilakiswrote: On 8/30/2010 5:33 PM, Ozkan Sezer wrote: > On Mon, Aug 30, 2010 at 5:30 PM, Kai Tietz > wrote: >> 2010/8/30 Vasilakis: >>> I have a problem compiling an application under windows XPSP3 x86 >>> with >>> >>> mingw-w32-bin_i686-mingw_20100711_sezero.zip + >>> sezero_20100711_w32_runtime_update_3441.zip >>> >>> The exact error reads. >>> >>> >>> >>> e:\mingw\bin\../lib/gcc/i686-w64-mingw32/4.4.5/../../../../i686-w64-mingw32/include/math.h:384: >>> error: expected unqualified-id before 'float' >>> >>> What does it mean? >>> >>> Thanks >> Hmm, the line you show is 'extern float __cdecl sinf(float _X);'. Now >> is the question which float gcc is warning here about. If it is the >> first, then you have possibly a define of extern (which is a bit >> unlikely). My bets go for the second one and here the issue could be >> that sinf is a define. To check use preprocessed headers (gcc -E) and >> check what this line gets expanded to. >> >> Regards, >> Kai >> > There is the signbit() macro just before that sinf() prototype. If > there > is some voodoo about that one in the user code, that can mess things up > too? Yes, it would help if we see the preprocessed source. > > -- > Ozkan Can you please tell me how to do it? I use the latest stable codeblocks to compile lsm_1_7_15_source.zip (Lionsnake modeller). with -E it compiles fine, without it does not. How can I instruct it to "generate preprocessed headers"? Thanks and sorry for my ignorance. >>> Well, with -E, it is not supposed to compile anything. >>> Find out what the command line is for the particular source file. >>> Suppose it is like: >>> gcc -Dmydefine -Wall -c mysource.c -o mysource.o >>> Now do: >>> gcc -Dmydefine -Wall -E mysource.c>out.txt >>> ... and inspect the generated out.txt to figure things out. >>> >>> -- >>> Ozkan >> I will take a look later. Thank you very much for your advice. >> > OK, I downloaded that lsm_1_7_15_source.zip and it seems like > the calc.h header in it is your problem: It defines sinf (and several > others along with it) and it clashes with the system provided header. > My suggestion would be removing those wrappers which are > already provided by the system headers. Thank you very much. Unfortunately I did not have time to investigate it further last night. So you saved me time and now I will build it. Thanks again. -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ 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 C++0x
Here is Windows API, that almost matches that on POSIX platforms: http://msdn.microsoft.com/en-us/library/ms682052(VS.85).aspx On 31.8.2010 7:28, NightStrike wrote: > On Thu, Aug 26, 2010 at 7:18 AM, Kai Tietz wrote: >> 2010/8/26 Ruben Van Boxem: >>> but poking around, I do not find a "thread" file (the include file for std::thread). >>> >>> it should be in: >>> /libstdc++-v3/include/std >>> My mingw gcc installation does have a "thread" file. (I realize that it may be out of date, but it's all I have.) I see, as Ruben pointed out, that it references (either directly or indirectly) __gthread_cond_t __gthread_time_t (and related), and that these are not defined in gthr-win32.h. >>> >>> As I said, *time_t is easy, but *cond_t seems like a big problem, because >>> the whole concept of threading is different and there's far from a 1-on-1 >>> mapping of *cond_t to win32 API. Once we have that struct though, it should >>> be quite straightforward to get the functions implemented. The gthr-win32.h >>> header is located in >>> >>> gcc trunk/4.6 snapshot: >>> gcc/gthr-win32.h >>> gcc/config/i386/gthr-win32.c >>> >>> This last one will either need >>> Do I take it correctly that the windows version of gthreads does not implement all of the features in the linux/posix version, and that some of these features are needed by the gcc implementation of std::thread? And that our discussion here is basically about sticking with the existing gcc implementation of std::thread and getting it to work on windows by adding the missing features to the windows version of gthreads? >>> >>> Correct. >> >> As I said before, if those functions are implemented in >> gcc/gthr-win32.h and gcc/config/i386/gthr-win32-c, then we can define >> in gthr-win32.h the define to support CXX0X. >> > > Adding GD to the list > > -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] import library overlap
2010/8/30 Chris Sutcliffe :
> On 30 August 2010 11:23, Kai Tietz wrote:
>> Well, this is a bit too much. Just make sure you specify on command
>> line (at end, or before -lkernel32 - if you specify it - the option
>> -ladvapi32. You can file a bug report for gcc, so I don't miss to
>> modify it for 4.6.
>
> Done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45452
>
> Cheers!
>
> Chris
Patch sent to ML and did some corrections on report about affected targets.
Thanks,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
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 C++0x
Hello Jaroslav - On Tue, Aug 31, 2010 at 5:50 AM, Jaroslav Šmíd wrote: > Here is Windows API, that almost matches that on POSIX platforms: > http://msdn.microsoft.com/en-us/library/ms682052(VS.85).aspx Thanks you: I didn't know that windows offered condition variables. On the web page you gave the link for it says: Windows Server 2003 and Windows XP/2000: Condition variables are not supported. Does this mean that windows condition variables are new as of vista and windows 7? As a practical matter, which versions of windows do we sort of expect mingw64 to support? Would implementing std::thread only for vista and later be considered Good Enough? (Yes, something is better than nothing, but there is also such a thing as too little.) It's also probably the case that using the new windows condition variables would give a better, more efficient implementation than reimplementing condition variables using the non-condition-variable part of windows threads. By the way, does anyone know why windows now offers condition variables? Do you think they are anticipating c++0x in particular, or is it just the ongoing evolution and maturation of windows? Thanks. K. Frank > On 31.8.2010 7:28, NightStrike wrote: >> On Thu, Aug 26, 2010 at 7:18 AM, Kai Tietz wrote: >>> 2010/8/26 Ruben Van Boxem: As I said, *time_t is easy, but *cond_t seems like a big problem, because the whole concept of threading is different and there's far from a 1-on-1 mapping of *cond_t to win32 API. Once we have that struct though, it should be quite straightforward to get the functions implemented. The gthr-win32.h header is located in ... -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ 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 C++0x
Win32 has conditions, however it's Vista/2008 and on:
http://msdn.microsoft.com/en-us/library/ms682052(VS.85).aspx
So it won't be available on lower end systems. Thread conditions are
basically "wait until this thing happens" which is essentially the
same thing as a mutex, kinda.
#include
volatile int did_something_happen =3D 0;
DWORD x(void* arg)
{
while (!did_something_happen)
Sleep(0);
printf("Happened\n");
return 0;
}
int main(int argc, char** argv)
{
CreateThread(NULL, 0, x, NULL, 0);
Sleep(5000);
did_something_happen =3D 1;
Sleep(1000);
return 1;
}
I'd say the best way to do it with Win32 would be if you can add a
non-visible static variable which contains the
LoadLibrary("kernel32.dll") and then a call to get the thread
condition function in that DLL, if it's non-null then use the Win32
stuff, if it is NULL, then make your own thread condition. If you want
threads to wake up from a call, the function setting the condition
stuff (called from the calling thread) can add stuff to some structure
of which condition to wake up on, then use the proper Win32
ResumeThread/SuspendThread. If the suspended thread happens to wakeup,
recheck the condition to see if it really happened and resume if it
did.
On Tue, Aug 31, 2010 at 1:28 AM, NightStrike wrote:
> On Thu, Aug 26, 2010 at 7:18 AM, Kai Tietz wrote:
>> 2010/8/26 Ruben Van Boxem :
>>>
but poking around, I do not find a "thread" file (the include file
for std::thread).
>>>
>>> it should be in:
>>> /libstdc++-v3/include/std
>>>
My mingw gcc installation does have a "thread" file. (I realize that
it may be out of date, but it's all I have.) I see, as Ruben pointed
out, that it references (either directly or indirectly)
__gthread_cond_t
__gthread_time_t
(and related), and that these are not defined in gthr-win32.h.
>>>
>>> As I said, *time_t is easy, but *cond_t seems like a big problem, because
>>> the whole concept of threading is different and there's far from a 1-on-1
>>> mapping of *cond_t to win32 API. Once we have that struct though, it should
>>> be quite straightforward to get the functions implemented. The gthr-win32.h
>>> header is located in
>>>
>>> gcc trunk/4.6 snapshot:
>>> gcc/gthr-win32.h
>>> gcc/config/i386/gthr-win32.c
>>>
>>> This last one will either need
>>>
Do I take it correctly that the windows version of gthreads does
not implement all of the features in the linux/posix version, and
that some of these features are needed by the gcc implementation
of std::thread?
And that our discussion here is basically about sticking with the
existing gcc implementation of std::thread and getting it to work
on windows by adding the missing features to the windows
version of gthreads?
>>>
>>> Correct.
>>
>> As I said before, if those functions are implemented in
>> gcc/gthr-win32.h and gcc/config/i386/gthr-win32-c, then we can define
>> in gthr-win32.h the define to support CXX0X.
>>
>
> Adding GD to the list
>
> --
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Yeah...
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] wxWidgets 2.9 + mingw-w64 -> libctl3d32 missing
Hi Mingw-w64 developers and users, I recently downloaded and installed the mingw-w64 package. I use it together with Msys and it just worked out-of-the-box. Amazing! Thanks for providing this great software!!! I'm currently working on a small program which uses wxWidgets 2.9 for its user interface and as I would like to build executables for 32 bit as well as for 64 bit systems I built wxWidgets with the compilers and libs of the mingw-w32 package and then tried to build it with the mingw-w64 package. Unfortunately, the build failed with the mingw-w64 compilers and libs. The problem occurs when wxWidgets tries to link against "libctl3d32.a" which is missing in the mingw-w64 package. Is this this a known problem? Best regards Felix -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wxWidgets 2.9 + mingw-w64 -> libctl3d32 missing
I found that file at this location "C:\MinGW64\x86_64-w64-mingw32\lib32\libctl3d32.a". I let MinGW install itself to the defaul;t location. Regards Chris Saunders -- From: "Felix Wolfheimer" Sent: Tuesday, August 31, 2010 6:01 PM To: Subject: [Mingw-w64-public] wxWidgets 2.9 + mingw-w64 -> libctl3d32 missing > Hi Mingw-w64 developers and users, > > I recently downloaded and installed the mingw-w64 package. I use it > together with Msys and it just worked out-of-the-box. Amazing! Thanks > for providing this great software!!! > > I'm currently working on a small program which uses wxWidgets 2.9 for > its user interface and as I would like to build executables for 32 bit > as well as for 64 bit systems I built wxWidgets with the compilers and > libs of the mingw-w32 package and then tried to build it with the > mingw-w64 package. > > Unfortunately, the build failed with the mingw-w64 compilers and libs. > The problem occurs when wxWidgets tries to link against "libctl3d32.a" > which is missing in the mingw-w64 package. Is this this a known problem? > > Best regards > > Felix > > > > > -- > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wxWidgets 2.9 + mingw-w64 -> libctl3d32 missing
On Wed, Sep 1, 2010 at 1:01 AM, Felix Wolfheimer wrote: > Hi Mingw-w64 developers and users, > > I recently downloaded and installed the mingw-w64 package. I use it > together with Msys and it just worked out-of-the-box. Amazing! Thanks > for providing this great software!!! > > I'm currently working on a small program which uses wxWidgets 2.9 for > its user interface and as I would like to build executables for 32 bit > as well as for 64 bit systems I built wxWidgets with the compilers and > libs of the mingw-w32 package and then tried to build it with the > mingw-w64 package. > > Unfortunately, the build failed with the mingw-w64 compilers and libs. > The problem occurs when wxWidgets tries to link against "libctl3d32.a" > which is missing in the mingw-w64 package. Is this this a known problem? > > Best regards > > Felix > I think the failure you had was with a 64 bit build? If yes, ctl3d32.dll doesn't seem to ship with 64 bit windows, that should be why no import library is given for it in 64 bit mode. -- Ozkan -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wxWidgets 2.9 + mingw-w64 -> libctl3d32 missing
On Wed, Sep 1, 2010 at 2:05 AM, Chris Saunders wrote: > I found that file at this location > "C:\MinGW64\x86_64-w64-mingw32\lib32\libctl3d32.a". I let MinGW install > itself to the defaul;t location. > > Regards > Chris Saunders That is for x86 only.. ctl3d32.dll doesn't seem to ship with 64 bit windows, so, if the failure report is about a 64 bit compilation, nothing can be done. -- Ozkan -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
