Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Building C::B with MinGW64
stahta01:
Edited: Removed Quoted Text.
Please point to the location of the "-m32" in the compiler build log you posted.
Tim S.
eranon:
--- Quote from: thomas on August 20, 2013, 03:55:46 pm ---It's true that the WoW64 layer adds some considerable overhead, especially when compiling or CC parsing (RtlInitializeExceptionChain, anyone?), and in particular because we create many more threads than would be necessary, which is extra expensive under WoW64. Unluckily, this is something we will have to live with for some time.
--- End quote ---
We're used to live with compromises ; human itself is not issue-free ::)
--- Quote from: thomas on August 20, 2013, 03:55:46 pm ---We have two half-working, broken platform implementations to replace the respective wxWidgets code, but getting them into a working, non-broken implementation is so far wishful thinking due to lack of time.
[...]
But sure enough, no time for approaching that before Christmas here, and even then I won't promise. Though maybe someone else is bored to death and wants to give it a try?
--- End quote ---
Don't worry and thanks a lot for these accurate explainations, Thomas. Code::Blocks is already a best of, whatever be the TODO list... In fact, a project without TODO list is a dead project.
On my side, even if it's not x64 native just now, even if I'm wondering how to work around a specific behavior under wxSmith sometimes, even if we always want more and more... I stay with C::B/wxSmith for its long list of qualities ; and the cons will wait the required time (as Eisenhower said - if the story doesn't lie : "What is important is seldom urgent and what is urgent is seldom important").
--- Quote from: thomas on August 20, 2013, 03:55:46 pm ---Well I don't know about the size of your projects, or anyone else's, but for me Code::Blocks very rarely uses more than 250 megabytes of committed memory, and I've never run out of address space. That said, VMMap tells me that Code::Blocks has 1.5GiB of free address space right now. [...]
It's true that the linker will regularly run out of address space with LTO, but LTO is not really usable except for "hello world" anyway. At least for me it doesn't ever seem to work as soon as you link more than 2 libraries or have more than 10 source files...
The one big advantage of 64-bit mode is that you have twice as many registers. I've had some number crunching code speed up by 20 times due to that.
--- End quote ---
My own projects are at human-level too, even if these days it would be not a marketing argument to say : my app consums a lot, and see, the exe is so big (LOL). I've often met people (not-software involved, of course, I mean) meaning that small is easier than big. So, what to say ? Nothing !
About build optimization (whatever be the stage, compile-time or linker one), there're so many branches and attempts to combinate speed, memory usage and quality of the output... Not so easy to decide what worth the effort or not...
"registers" : not so frequent to hear someone talking about registers these days... But, of course, I agree ; hoping the compiler generates the right intructions (I mean optimizing the use of underlying hardware) ;)
eranon:
--- Quote from: stahta01 on August 20, 2013, 04:30:50 pm ---Please point to the location of the "-m32" in the compiler build log you posted.
--- End quote ---
:o You're right ! I don't retrieve the -m32 neither in compiler nor linker options. So, my mistake (I guess I closed the dlg with cancel, really don't know)... Well, however, I fall in other error after adding (truly this time) -m32... But i'll see this later (must go now) and will be back to tell you.
Thanks for your eye, Tim
--
EDIT : it sounds like all the errors I've seen until now are because of a lack of "-m32" option. What is weird is that even if I add this option in the compiler and linker fields at project level, some targets seem to ignore it (and, then, I have to explicitely add the option at target level too... So, a lot of repetitive manipulations in perspective)... To be continued...
--
EDIT#2 : but, I think (sometimes), what a silly boy : creating a duplicated GCC entry at C::B level I can directly add the option at C::B level... Can't try just now, but will try this way...
--
EDIT#3 : done ! It compiles ;D
--- Code: ---||=== Build finished: 0 error(s), 232 warning(s) (8 minute(s), 56 second(s)) ===|
--- End code ---
eranon:
OK, I've successfully built the contrib-plugins workspace too (unless Autoversioning which shown an error and Nassi Shneiderman which needed Boost), then ran update.bat. And now I face a new situation : when I launch this freshly built C::B (the one under output subdir) I have a long yellow warning message at right side telling me a lot of plugins are disabled because of a difference of SDK... So, what's wrong ? What should I do ?
stahta01:
--- Quote from: eranon on August 21, 2013, 03:36:05 am ---OK, I've successfully built the contrib-plugins workspace too (unless Autoversioning which shown an error and Nassi Shneiderman which needed Boost), then ran update.bat. And now I face a new situation : when I launch this freshly built C::B (the one under output subdir) I have a long yellow warning message at right side telling me a lot of plugins are disabled because of a difference of SDK... So, what's wrong ? What should I do ?
--- End quote ---
I would first try rebuilding just the SDK in the main CB Project; then ran update.bat, again.
Then, make a list of the plugins that you have bad error reporting in the main CB Project.
Rebuild just one of those plugins to see if the problem goes away. Remember to ran update.bat, again; before testing.
If you have no plugins in the main CB Project; make a list of the ones not working in contrib workspace.
I suggest skipping the wxSmith ones because they take a very long time to re-build.
Rebuild just one of those plugins to see if the problem goes away. Remember to ran update.bat, again; before testing.
Edit: If the problem does NOT go away, it is likely a PCH issues; so, deleted the precompiled header files.
PCH Files (I did not check these paths).
.objs\include\sdk_precomp.h.gch
.objs\include\sdk.h.gch
Tim S.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version