I'm afraid I don't have a Linux machine, so I would need some more info to crack this one.Gentoo linux, gcc 4.3.1 for mingw cross compiling.
Planning for 0.77 Release
Moderator: Moderators
Re: Planning for 0.77 Release
Re: Planning for 0.77 Release
get one, it's easy - vmware or virtualbox work great. you'll only need to setup cross-compiling, which may require some googling and asking around.
Re: Planning for 0.77 Release
OT: I hate VMS....
BTW, sometime next week I should have a vista 64 machine with an nvidia 280 in it, will post results as soon as I put her together... I think I will name her hanai.. after hanai miri, because damnit this one is going to have some biguns and she is hawt!
BTW, sometime next week I should have a vista 64 machine with an nvidia 280 in it, will post results as soon as I put her together... I think I will name her hanai.. after hanai miri, because damnit this one is going to have some biguns and she is hawt!
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: Planning for 0.77 Release
zerver wrote:I'm afraid I don't have a Linux machine, so I would need some more info to crack this one.Gentoo linux, gcc 4.3.1 for mingw cross compiling.
Code: Select all
=>1 0xf7fc9430 (0x0111f3cc)
2 0xffffffff (0x0111f3e8)
3 0x7efc384b NtDelayExecution+0x5b() in ntdll (0x0111f438)
4 0x7ee5c872 SleepEx+0x32() in kernel32 (0x0111f458)
5 0x7ee5c8b6 Sleep+0x26() in kernel32 (0x0111f478)
6 0x00b07682 in spring (+0x707682) (0x0111f488)
7 0x0082f955 in spring (+0x42f955) (0x0111f4a8)
8 0x00661e4a in spring (+0x261e4a) (0x0111f4d8)
9 0x00663862 in spring (+0x263862) (0x0111f7a8)
10 0x00853ae4 in spring (+0x453ae4) (0x0111f9c8)
11 0x0085fc91 in spring (+0x45fc91) (0x0111fcf8)
12 0x005cb811 in spring (+0x1cb811) (0x0111fd28)
13 0x005d7a5e in spring (+0x1d7a5e) (0x0111fd78)
14 0x005ca515 in spring (+0x1ca515) (0x0111fe08)
15 0x005ca716 in spring (+0x1ca716) (0x0111fe28)
16 0x00b0eac1 in spring (+0x70eac1) (0x0111fea8)
17 0x004010a7 in spring (+0x10a7) (0x0111fee8)
18 0x00401123 in spring (+0x1123) (0x0111ff08)
19 0x7ee46e49 in kernel32 (+0x56e49) (0x0111ffe8)
20 0xf7e7c067 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000)
Unfortunately I don't know how to treanslate these symbols.
Re: Planning for 0.77 Release
I'm not compiling- I'm just testing Bibim's builds. Haven't had a chance to even do that for a week, so it was, er, a little shocking to see that it was borked this much. Er, and sorry LordMatt, no offense was intended by my whining... I just hate having to sit through 3 minutes of downloads every time I fire up the Installer at this pointAre you compliling with or without multithreading (/D USE_GML)?
Re: Planning for 0.77 Release
gdb info line *address or addr2line.Auswaschbar wrote:[snip]
Unfortunately I don't know how to treanslate these symbols.
Re: Planning for 0.77 Release
Tested 0.77 branch, build 6331. Locks during Finalizing. I'll go rebuild current SVN now...
<tests>
6337, broken. If there are working win32 builds, I'd like to test one, but Bibim's builds are currently hosed, at least for me
<tests>
6337, broken. If there are working win32 builds, I'd like to test one, but Bibim's builds are currently hosed, at least for me
-
- Spring Developer
- Posts: 1254
- Joined: 24 Jun 2007, 08:34
Re: Planning for 0.77 Release
http://spring.jobjol.nl/show_file.php?id=1428
Build without gml to make it working. Only contains spring.exe, unzip it in your installation folder.
Build without gml to make it working. Only contains spring.exe, unzip it in your installation folder.
Re: Planning for 0.77 Release
BuildServ's r6337 works fine here
Re: Planning for 0.77 Release
At least one other P.U.R.E. beta-tester reports a hang during Finalize, on this end. It's not just me.
Re: Planning for 0.77 Release
I've deactivated GML in BuildServ until the problem get solved. r6341 has been reuploaded with non-GML binaries.
Re: Planning for 0.77 Release
Like I wrote in the other thread, problem appears to be caused by the fact that GCC 4.3 does not support TLS using __thread. I'm surprised it does not spit out any error messages though.
Maybe TLS must be enabled somehow?
Maybe TLS must be enabled somehow?
Re: Planning for 0.77 Release
according to the release notes, gcc 4.3 actually started supporting this on windows. what's being used on the buildbot?
Re: Planning for 0.77 Release
I know! There could be something wrong with the experimental 4.3.2 from tdragon.net of course.
I added a TLS test to my library, it is in trunk now. If there is an error, a message box will appear and spring will terminate.
I added a TLS test to my library, it is in trunk now. If there is an error, a message box will appear and spring will terminate.
Re: Planning for 0.77 Release
Newest builds worked. Thanks for taking the time to look into this, bibim.
Hope you can get those issues licked before release, that was a bad moment there...
Hope you can get those issues licked before release, that was a bad moment there...
Re: Planning for 0.77 Release
For win32 cross-compilation, BuildServ uses the latest stable mingw gcc: 4.2.1-sjlj (gcc versions used by BuildServ are listed here).imbaczek wrote:according to the release notes, gcc 4.3 actually started supporting this on windows. what's being used on the buildbot?
Concerning LordMatt's buildbot, the gcc version can be found in its configure output:
Code: Select all
Checking i586-mingw32msvc-gcc version... 4.2.1
-
- Posts: 34
- Joined: 29 May 2008, 21:06
Re: Planning for 0.77 Release
The 0.77 release looks very promising, however I don't use Windows much anymore even though I have access to a fairly new Vista computer. I have managed to get the latest SVN almost completely compiled using XCode for Mac OS X 10.4, however I am stuck on linker errors. I am missing the symbols _MacMessageBox, _PreInitMac, and _pool.
The 0.76b1+ release works flawlessly on my computer. If I can get this build working then I might be able to help Spring support Mac OS X.
P.S. Argh: I would love to beta test P.U.R.E. once this is fixed!
The 0.76b1+ release works flawlessly on my computer. If I can get this build working then I might be able to help Spring support Mac OS X.
P.S. Argh: I would love to beta test P.U.R.E. once this is fixed!
Re: Planning for 0.77 Release
zerver: your fixes for boost 1.36 work fine here, gcc 4.3.2 compiles with gml=yes, but unfortunately it looks like TLS isn't supported. I had a message box once, and twice a dual-core 100% cpu usage deadlock. suggest refactoring (reverting?) to arrays and thread ids (if that's possible.) it used to work, and worked pretty well, after all.
Re: Planning for 0.77 Release
I'm afraid we will have to wait for TLS support.
Thread ID's are simply too slow - every single GL call needs the thread ID and would need to call GetCurrentThreadID().
Compare this to the ultra-efficient TLS in Visual Studio, where each variable access translates into just three CPU instructions.
My library has been based on TLS all the time. If it "used to work" before, it must have been a different compiler, a single core system or maybe the library was disabled.
Thread ID's are simply too slow - every single GL call needs the thread ID and would need to call GetCurrentThreadID().
Compare this to the ultra-efficient TLS in Visual Studio, where each variable access translates into just three CPU instructions.
My library has been based on TLS all the time. If it "used to work" before, it must have been a different compiler, a single core system or maybe the library was disabled.
Re: Planning for 0.77 Release
http://pastebin.com/m1accec86
this doesn't work at first, but adding -mthreads to compilation and linking flags made it to work (gcc 4.3.2). will investigate further.
oh btw, TLS isn't that efficient on gcc, actually, it's rather slow.
http://pastebin.com/m37e2318f
edit: adding -mthreads didn't help with locking on finalizing, but the message box doesn't appear.
this doesn't work at first, but adding -mthreads to compilation and linking flags made it to work (gcc 4.3.2). will investigate further.
oh btw, TLS isn't that efficient on gcc, actually, it's rather slow.
http://pastebin.com/m37e2318f
edit: adding -mthreads didn't help with locking on finalizing, but the message box doesn't appear.