Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: tyeken8 on May 28, 2010, 07:54:57 am

Title: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: tyeken8 on May 28, 2010, 07:54:57 am
Just as the title says, I built the wxMSW 2.8.10 and 2.9.0 and C::B on both of them successfully (with minor hacks in C::B srcs, mainly for the 64-bit pointers),
but then I got a "0xc000007b" error while tried running codeblocks.exe, like this.
(http://tydus.googlecode.com/files/0xc000007b.png)
I found sth. on the M$ Technet and knews that it means "The application or DLL is not a valid Windows image".

And one of my friends, Thynson, an professional GCC player, says that "There's something wrong with the ld in GNU binutils, attach '--enable-auto-image-base' flag on the ld may do", I've tried, but it didn't works.

He said that "you may try to del all the resources and recompile it". I created a tiny dummy project and built like this, IT WORKS.

So I guess that the Original Correct Image Base was ruined by the ".rsrc" segment (but I can do nothing to verify it, my PEiD can't recognize the PE32+ format), so maybe we can solve this problem by re-permutation the segments (of course some automated tools Eg. ld || dlltools is better)?

BTW, the C::B SVN 6272 x86 by MinGW GCC 4.5.0(built by Thynson) works fine on my machine. I created a bundle and pasted it on the web, you can have a try if you want.
http://a.md/cb (http://a.md/cb)

Wating for reply online... Thx.
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: Propagator on May 28, 2010, 09:46:56 am
Did you make sure that your manifest file contains the line

Code
processorArchitecture="amd64"

instead of the usual 32-bit

Code
processorArchitecture="x86"

If you specify the wrong processor architecture, windows will load the wrong version of comctl32.dll (if I remember correctly) and you'll get exactly the error you reported. You can check with dependency walker what dll's are loaded by your application.

Hope that helps...
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: oBFusCATed on May 28, 2010, 10:16:34 am
I think C::B doesn't work on 64bit Windows...
See this topic: http://forums.codeblocks.org/index.php/topic,11567.0.html

Also I think C::B is crashing with wx2.9.x, so try wx2.8 first
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: thynson on May 28, 2010, 04:13:44 pm
Actually I am not sure but just tell him to try '--enable-auto-image-base'. Now the problem is clear, the CodeBlocks use a manifest for x86 other than x64. I have replaced the manifest file 'wx/include/wx/msw/wx.manifest' with amd64.manifest. And we have began the process of build. Waiting for our good news, plz. :D
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: tyeken8 on May 29, 2010, 02:53:17 am
Well, a good news and a bad news.

The lastest C::B (SVN 6284) was build SUCCESSFULLY

BUT the startup.script doesn't work correctly.

It gave me a "Push(): could not create INSTANCE copy (check registration name)".
Following the both startup.script and this error message, I found:
1. this problem occurs when running the script "GetScriptingManager().RegisterScriptMenu()"
2. there's sth. wrong in sqplus. but when I got into, I encontered a macro.

Code
#define DECLARE_INSTANCE_TYPE_NAME_(TYPE,NAME) namespace SqPlus { \
  inline const SQChar * GetTypeName(const TYPE & n) { return sqT(#NAME); } \
  inline void Push(HSQUIRRELVM v,TYPE * value) { \
...

I can't determine the TYPE rapidly, so I go to you for help.
Are there any readymade solutions, or I have to work out with it?

Thx.
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: oBFusCATed on May 29, 2010, 11:28:15 am
Have you read the thread I've shown you? There Biplap has a patch for the scripting, have you tried it?
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: thynson on May 29, 2010, 11:46:27 am
The patch is not enough. The patch is just for svn 5XXX(sorry I forgot). After applying it, there is still many bad cast from pointer to interger. And particulary much of them was found in the SQplus library.
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: Biplab on May 29, 2010, 01:46:24 pm
Quote from: thynson on May 29, 2010, 11:46:27 am
The patch is not enough. The patch is just for svn 5XXX(sorry I forgot). After applying it, there is still many bad cast from pointer to interger. And particulary much of them was found in the SQplus library.

Well that patch is enough to compile code::blocks successfully. I had also uploaded compiled binary for others to try out. I believe you didn't even give it a try.

I have also pointed out remaining issues (mostly runtime issues) in the same thread. Anyway I'm attaching a new patch made against trunk. Do note that - you need WPG-System64 1.99-1 to compile and run it. If you use Mingw-w64 compilers you'll be able to compile; however the resulting binary won't run.

[attachment deleted by admin]
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: thynson on May 29, 2010, 06:08:43 pm
Be calmed, plz. I tried. I'm using MinGW-W64 GCC 4.5.0 to compile Code::Blocks x64. The patch from you tyeken8 and me have applied. But there are still some compile errors. To prove this, here is our patch.
Debating about this is meaningless. But the most important is not that the CodeBlocks x64 version couldn't be built, but how it ran failed. Actually we've successfully built it and  have ran it, through it doesn't run properly, as Tydus descript above. We have found it's a call failed in SQplus.

[attachment deleted by admin]
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: Biplab on May 29, 2010, 06:37:22 pm
Quote from: thynson on May 29, 2010, 06:08:43 pm
Be calmed, plz. I tried. I'm using MinGW-W64 GCC 4.5.0 to compile Code::Blocks x64. The patch from you tyeken8 and me have applied. But there are still some compile errors. To prove this, here is our patch.
Debating about this is meaningless. But the most important is not that the CodeBlocks x64 version couldn't be built, but how it ran failed. Actually we've successfully built it and  have ran it, through it doesn't run properly, as Tydus descript above. We have found it's a call failed in SQplus.

Thanks for the patch! I recently rewrote a portion of SqPlus patch to avoid the use of data type INT and BOOL. Reason is to avoid conflict with pre-defined types. I also see you have added necessary code in crashhandler.cpp file. I'll apply it to my local repo.

Coming back to your runtime issue, I had uploaded a compiled binary at the following post.
Quote
http://forums.codeblocks.org/index.php/topic,11567.msg80360.html#msg80360

The problem you are highlighting is not present in my build. You can give it a try.

However if you use my build I'd suggest you disable Code-Completion plugin and you may need to kill it from Task Manager after you exit. I'll upload a new build based on latest svn code tomorrow.
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: thynson on May 30, 2010, 05:15:43 am
 :DThat's good. I will have a try.
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: tyeken8 on May 30, 2010, 05:23:00 am
Quote from: thynson on May 29, 2010, 06:08:43 pm
Be calmed, plz. I tried. I'm using MinGW-W64 GCC 4.5.0 to compile Code::Blocks x64. The patch from you tyeken8 and me have applied. But there are still some compile errors. To prove this, here is our patch.
Debating about this is meaningless. But the most important is not that the CodeBlocks x64 version couldn't be built, but how it ran failed. Actually we've successfully built it and  have ran it, through it doesn't run properly, as Tydus descript above. We have found it's a call failed in SQplus.

Well, the patch can only result in a successfully build in GCC, there're too many implicit bad casts from pointer to long(int), they don't cause compile errors, but they will cause some runtime errors while handling memorys larger than 4GB.
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: Biplab on May 30, 2010, 05:53:41 am
Quote from: tyeken8 on May 30, 2010, 05:23:00 am
Well, the patch can only result in a successfully build in GCC, there're too many implicit bad casts from pointer to long(int), they don't cause compile errors, but they will cause some runtime errors while handling memorys larger than 4GB.

I found many of them belong to wx itself. Hope they fix it in next release.
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: stahta01 on May 30, 2010, 04:16:56 pm
Quote from: Biplab on May 29, 2010, 01:46:24 pm
Do note that - you need WPG-System64 1.99-1 to compile and run it.

FYI: WPG-System64 is an MSys setup not just a MinGW GCC in case anyone other than me wandered about the size 300MB zipped.

Tim S.
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: Biplab on May 30, 2010, 06:25:30 pm
I have uploaded a new test build. You can download it from the following url.

Quote
http://www.box.net/shared/tl6o3tejxv

It's compiled based on the patch, to trunk, I uploaded few posts earlier. There are several known issues with this build. You may read about them from the original 64 bit thread.
Title: Re: C::B Unable to start (0xc000007b) on win64/MinGW64 GCC 4.5.0
Post by: vityan on June 03, 2010, 08:02:07 pm
[tyeken8]

Try my patch from this (http://forums.codeblocks.org/index.php/topic,11567.0.html) thread.
It has extensions of classes with long long supporting methods and changes to INT/FLOAT/BOOL CB types so they don't collide with MingW-W64 predefined types... It's a little outdated and i'm not that parts from it got to trunk...

Ive had the 0x7b error all the time(coz ive managed to build x64 version for a long time already)... So it's manifest problem at the end...

However CB is not yet ready to work with WX291-SVN(X32 version runs but crashes on for example accessing project files list) so it will probably only work with 2.8.X and below...