Technical support > Windows
Compiling for Windows (Thread Tracking for Thyranim)
Muton:
the only diff between odie and me is
the rest is FULLY identical
odie place
MinGW\\include\\gdk\\glext\\glext-extra.h
MinGW\\include\\gdk\\glext\\glext.h
MinGW\\include\\gdk\\glext\\glxext-extra.h
MinGW\\include\\gdk\\glext\\glxext.h
MinGW\\include\\gdk\\glext\\wglext-extra.h
MinGW\\include\\gdk\\glext\\wglext.h
MinGW\\include\\gdk\\win32\\gdkglwglext.h
MinGW\\include\\gdk\\win32\\gdkglwin32.h
Muton place
MinGW\\gtkglext\\gdk\\glext\\glext-extra.h
MinGW\\gtkglext\\gdk\\glext\\glext.h
MinGW\\gtkglext\\gdk\\glext\\glxext-extra.h
MinGW\\gtkglext\\gdk\\glext\\glxext.h
MinGW\\gtkglext\\gdk\\glext\\wglext-extra.h
MinGW\\gtkglext\\gdk\\glext\\wglext.h
MinGW\\gtkglext\\gdk\\win32\\gdkglwin32.h
MinGW\\gtkglext\\gdk\\win32\\gdkglwglext.h
and this headers seems to be unimportant during compilation
My last guess is C::B itself
Because C::B stores settings under documents and settings
you will still usings the same gcc even if you use a different C::B build
But i'm not shure how Vista handles this
Take a look at
Settings->compiler and debugger->toolchain executable
if the path and exe's are the same on odies C::B and mine
replace on my C::B package C::B with
http://download.berlios.de/codeblocks/CB_20090214_rev5456_win32.7z
http://download.berlios.de/codeblocks/
If the problem persists use a newer C::B rev5678
Thyranim:
--- Quote from: Muton on July 17, 2009, 06:57:14 pm ---My last guess is C::B itself
Because C::B stores settings under documents and settings
you will still usings the same gcc even if you use a different C::B build
But i'm not shure how Vista handles this
Take a look at
Settings->compiler and debugger->toolchain executable
if the path and exe's are the same on odies C::B and mine
replace on my C::B package C::B with
http://download.berlios.de/codeblocks/CB_20090214_rev5456_win32.7z
http://download.berlios.de/codeblocks/
If the problem persists use a newer C::B rev5678
--- End quote ---
i was changing the settings/pathes everytime i was changes the package.
so when using odies package, i was changing all pathes to odies directory and vice versa with mutons directory
will give it a try with R5678
Muton:
Than mabe its gcc
determine the used gcc version
Settings->compiler and debugger->toolchain executable->C compiler
this executable can be found at mingw\bin\
run a cmd and append the parameter --v
Thyranim:
sorry but identical :(
--- Code: ---D:\_Development\codeblocks - Muton\MinGW\bin>gcc.exe --v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32'
Thread model: win32
gcc version 4.3.3 (4.3.3-tdm-1 mingw32)
D:\_Development\codeblocks - Odie\MinGW\bin>gcc.exe --v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.3/configure --prefix=/mingw --build=mingw32 --enable-languages=c,ada,c++,fortran,objc,obj-c++ --with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls --disable-win32-registry --enable-libgomp --disable-werror --enable-threads --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-pkgversion='4.3.3-tdm-1 mingw32'
Thread model: win32
gcc version 4.3.3 (4.3.3-tdm-1 mingw32)
--- End code ---
i'll try new c::b-revision next time... but no time actually, other projects with deadline ^^
Update:
Downloaded C::B-R5678
copied "MinGW"-Folder from Mutons-Folder to R5678-Folder
copied wxmsw28u_gcc_cb.dll
checked gcc-version (it's identical, so see above)
loaded last SVN 25237 and rebuild game.... without errors, as before
but again, with activated GLSL Shaders and realtime lighting i get only black models and cpu-usage of app. 90% -_-
deactivating one of them shows the models and drops cpu-usage back to normal...
any other ideas ?
anyone ?
Currently downloading R25206 by odie for further approval...
odie:
So Thyranim,
Did 25206 solved your problem?
Aka any progress since...... ??
:D
Odie
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version