exchndl related patch because win32/lib folder is empty in SVN

[ollydbg]

Good to know its solved for you.it could also have been that you seem to use the dwarf version which I don't. At least I didn't even try of the lib is actually compatible.it claims to bee so...

I use SJLJ; but, maybe ollydbg uses dwarf version.

Tim S.

Yes, I use dwarf version, is that the reason I get link error, I don't think so, I see exchndl is a pure C library.
BTW: I use the version: MinGW-W64 project, mingw-build i686-4.9.2-posix-dwarf-rt_v4-rev2

ok,I think you should do a recompile and look for old versions of the dll in the path.the linker would pick an old version. Please search for exchndl.* in the path. There is no reason why it should not work except the linker picks a wrong version. You could also add the lib with the full path temporarily to try...

Hi, Morten, thanks, this issue is fixed now. I noticed that there are old exchndl.dll in the folder:
F:\cb_sf_git\trunk\src\devel
And we have the "-Ldevel -Lexchndl\win32\lib" option in the linker option, which means the "devel" folder was searched before the "exchndl/win32/lib", thus the old exchndl.dll is used in the linker. After delete the exchndl.dll in devel folder, I have successfully build the scr now.

[ollydbg]

Code Select Expand


Linking executable: devel\codeblocks.exe
Warning: resolving _ExcHndlInit@0 by linking to _ExcHndlInit
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups


Tim S.

I also have this issue, this is because the linker try to link the exchndl.dll in your devel folder.(this dll will copied to your devel folder when you run the update.bat)

Here is my test: If you remove the exchndl.dll from the devel folder, than you get the good result:

Code Select Expand


-------------- Build: src in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

[ 50.0%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DBUILDING_PLUGIN -iquote.objs\include -I.objs\include -I. -IE:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\include -IE:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -Iexchndl\win32\include -c src\app.cpp -o .objs\src\app.o
[100.0%] g++.exe -Lbase\tinyxml -LE:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll -Ldevel -Lexchndl\win32\lib -o devel\codeblocks.exe .objs\src\app.o .objs\src\appglobals.o .objs\src\associations.o .objs\src\backtracedlg.o .objs\src\breakpointsdlg.o .objs\src\compilersettingsdlg.o .objs\src\cpuregistersdlg.o .objs\src\crashhandler.o .objs\src\debugger_interface_creator.o .objs\src\debuggermenu.o .objs\src\debuggersettingscommonpanel.o .objs\src\debuggersettingsdlg.o .objs\src\debuggersettingspanel.o .objs\src\disassemblydlg.o .objs\src\dlgabout.o .objs\src\dlgaboutplugin.o .objs\src\editkeywordsdlg.o .objs\src\editorconfigurationdlg.o .objs\src\environmentsettingsdlg.o .objs\src\examinememorydlg.o .objs\src\find_replace.o .objs\src\infopane.o .objs\src\main.o .objs\src\notebookstyles.o .objs\src\printdlg.o .objs\src\projectdepsdlg.o .objs\src\projectmanagerui.o .objs\src\projectoptionsdlg.o .objs\src\recentitemslist.o .objs\src\scriptconsole.o .objs\src\scriptingsettingsdlg.o .objs\src\splashscreen.o .objs\src\startherepage.o .objs\src\switcherdlg.o .objs\src\threadsdlg.o .objs\src\virtualbuildtargetsdlg.o .objs\src\watchesdlg.o  .objs\src\resources\resources.res -Wl,--enable-auto-import -Wl,--no-undefined  -lcodeblocks -lwxpropgrid -lexchndl -lshfolder -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lcomctl32 -lodbc32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lwxmsw28u -mwindows
Output file is devel\codeblocks.exe with size 13.82 MB
[ 25.0%] Running target post-build steps
[ 50.0%] cmd /c if not exist devel\share\CodeBlocks mkdir devel\share\CodeBlocks
[ 75.0%] zip -jq9 devel\share\CodeBlocks\resources.zip src\resources\*.xrc
[100.0%] zip -jq9 devel\share\CodeBlocks\start_here.zip src\resources\start_here\*.html src\resources\start_here\*.png
cmd /c "cd src\resources & zip -0 -q ..\..\devel\share\CodeBlocks\resources.zip images\*.png images\16x16\*.png"
Process terminated with status 0 (0 minute(s), 8 second(s))
0 error(s), 0 warning(s) (0 minute(s), 8 second(s))

So, my suggest is that we can search the -Lexchndl\win32\lib before the -Ldevel.

Here is the result, looks good even you have exchndl.dll in your devel folder.

Code Select Expand

-------------- Build: src in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

[ 50.0%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DBUILDING_PLUGIN -iquote.objs\include -I.objs\include -I. -IE:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\include -IE:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\scripting\include -Iinclude\scripting\sqplus -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -Iexchndl\win32\include -c src\app.cpp -o .objs\src\app.o
[100.0%] g++.exe -Lbase\tinyxml -LE:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll -Lexchndl\win32\lib -Ldevel -o devel\codeblocks.exe .objs\src\app.o .objs\src\appglobals.o .objs\src\associations.o .objs\src\backtracedlg.o .objs\src\breakpointsdlg.o .objs\src\compilersettingsdlg.o .objs\src\cpuregistersdlg.o .objs\src\crashhandler.o .objs\src\debugger_interface_creator.o .objs\src\debuggermenu.o .objs\src\debuggersettingscommonpanel.o .objs\src\debuggersettingsdlg.o .objs\src\debuggersettingspanel.o .objs\src\disassemblydlg.o .objs\src\dlgabout.o .objs\src\dlgaboutplugin.o .objs\src\editkeywordsdlg.o .objs\src\editorconfigurationdlg.o .objs\src\environmentsettingsdlg.o .objs\src\examinememorydlg.o .objs\src\find_replace.o .objs\src\infopane.o .objs\src\main.o .objs\src\notebookstyles.o .objs\src\printdlg.o .objs\src\projectdepsdlg.o .objs\src\projectmanagerui.o .objs\src\projectoptionsdlg.o .objs\src\recentitemslist.o .objs\src\scriptconsole.o .objs\src\scriptingsettingsdlg.o .objs\src\splashscreen.o .objs\src\startherepage.o .objs\src\switcherdlg.o .objs\src\threadsdlg.o .objs\src\virtualbuildtargetsdlg.o .objs\src\watchesdlg.o  .objs\src\resources\resources.res -Wl,--enable-auto-import -Wl,--no-undefined  -lcodeblocks -lwxpropgrid -lexchndl -lshfolder -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lcomctl32 -lodbc32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lwxmsw28u -mwindows
Output file is devel\codeblocks.exe with size 13.82 MB
[ 25.0%] Running target post-build steps
[ 50.0%] cmd /c if not exist devel\share\CodeBlocks mkdir devel\share\CodeBlocks
[ 75.0%] zip -jq9 devel\share\CodeBlocks\resources.zip src\resources\*.xrc
[100.0%] zip -jq9 devel\share\CodeBlocks\start_here.zip src\resources\start_here\*.html src\resources\start_here\*.png
cmd /c "cd src\resources & zip -0 -q ..\..\devel\share\CodeBlocks\resources.zip images\*.png images\16x16\*.png"
Process terminated with status 0 (0 minute(s), 9 second(s))
0 error(s), 0 warning(s) (0 minute(s), 9 second(s))

[oBFusCATed]

I see that there is this command now in the wx30.cbp file:

Code Select Expand


cmd.exe /c if exist devel30\exchndl.dll del devel30\exchndl.dll


But how am I supposed to run cb from cb when this dll is deleted?
When I run it, windows tells me that it cannot find the exchndl.dll.
So, what am I supposed to do?

I'm running win7 64bit, 32bit tdm 5.1, wx 3.1 master branch...

BTW, cb development on windows is pretty annoying compared to the linux experience...

[ollydbg]

The command was added in rev 10411.

Code Select Expand


src/CodeBlocks.cbp | 1 +
1 file changed, 1 insertion(+)

diff --git a/src/CodeBlocks.cbp b/src/CodeBlocks.cbp
index 94c335e..ae5f9ef 100644
--- a/src/CodeBlocks.cbp
+++ b/src/CodeBlocks.cbp
@@ -221,6 +221,7 @@
<Add directory="exchndl/win32/lib" />
</Linker>
<ExtraCommands>
+ <Add before="cmd.exe /c if exist devel\exchndl.dll del devel\exchndl.dll" />
<Add after="cmd /c if not exist devel\share\CodeBlocks mkdir devel\share\CodeBlocks" />
<Add after="zip -jq9 devel\share\CodeBlocks\resources.zip src\resources\*.xrc" />
<Add after="zip -jq9 devel\share\CodeBlocks\start_here.zip src\resources\start_here\*.html src\resources\start_here\*.png" />


I think to run C::B correctly, you need to run "update*.dat". In the batch file, the exchndl.dll will be copied there.

The question is: I think we don't need to delete the dll, we just need to set the lib search path priority, as I said before. This can avoid the delete/copy exchndl.dll issue.

[MortenMacFly]

Well first of all olly is right, on Windows cb will not run if you don't run the update script before. Secondly the dll should not be required, if implemented correctly. If loading the dll fails it will still work just that you don't have the debug reports.

[oBFusCATed]

It doesn't work by default on my machine.
I have to remove the post build step in both wx28 and wx30 builds, otherwise it deletes it and fails to start.
And it is hard dependency and cb fails to start if it is missing.

What am I doing wrong? Should I run updata.bat after every build?
Why isn't it an automatically called?
What about debugging which always builds the source?

[stahta01]

It doesn't work by default on my machine.
I have to remove the post build step in both wx28 and wx30 builds, otherwise it deletes it and fails to start.
And it is hard dependency and cb fails to start if it is missing.

What am I doing wrong? Should I run updata.bat after every build?
Why isn't it an automatically called?
What about debugging which always builds the source?

My guess is update.bat needs to be ran manually so you can use the CB in output to build the CB in devel folder.

FYI: I have plans to add an lib folder in addition to the devel folder which would make it easy to fix this problem without doing the deletes.
Does anyone think it a worth while idea for me to create the patch to do it to the Windows builds?

Tim S.

[ollydbg]

FYI: I have plans to add an lib folder in addition to the devel folder which would make it easy to fix this problem without doing the deletes.
Does anyone think it a worth while idea for me to create the patch to do it to the Windows builds?

Tim S.

You mean, do not put the lib files(.a files) in the devel folder? Instead put them in a separate lib folder? I totally agree, I think devel folder should only contains executables.

[stahta01]

FYI: I have plans to add an lib folder in addition to the devel folder which would make it easy to fix this problem without doing the deletes.
Does anyone think it a worth while idea for me to create the patch to do it to the Windows builds?

Tim S.

You mean, do not put the lib files(.a files) in the devel folder? Instead put them in a separate lib folder? I totally agree, I think devel folder should only contains executables.

Correct put all the .a files in the lib folder this includes static libs and import libs.
Also, ones like tinyxml and other static libs in various sub folders.
The reason I was planning to do it; was to make it easier to delete all the .a files; because, I had weird issues that seemed to required that to fix.

Tim S.

[MortenMacFly]

What am I doing wrong? Should I run updata.bat after every build?

To beginners I would say "Yes". A more precise explanation follows below...

Why isn't it an automatically called?

Because it takes time and most of the time you don't need that.

What about debugging which always builds the source?

Again: You shouldn't rely the the presence of this DLL to be able to debug. However, for debugging you rely on update.bat being called at least once in the session to ensure resources are up-to-date. Depending on what you do (whether you change resources or not) you don't need it for a while then...

[oBFusCATed]

As you know I'm not a beginner.

So what I did is:
0. install the latests tdm-32bit sjlj
1. install a night build
2. checkout the tree (new clean one)
3. build wxwidgets
4. build cb
5. run update.bat
6. change some code
7. press f9 to build and run / or press f8 to debug cb (this builds the code, because I have the option to build enabled).
8. codeblocks fails to start, because the dll is deleted and it is automatic dependency

The question is should I add step 7.1 - to be run update.bat to my workflow?

And what do you mean by:

Again: You shouldn't rely the the presence of this DLL to be able to debug.

Are you able to run freshly build cb without this dll in the path or next to the codeblocks.exe?

p.s. I've solved my problem by removing the delete prebuild commands, but this should work out of the box. This is why I'm discussing this.

[scarphin]

Although I'm testing on a 64-bit build with mingw-builds compiler, I can confirm that the exchndl.dll is required to run or debug CB. I think copying the current dll over the one in the devel folder or leaving that to update.bat should be preferred as running update.bat every time after the 'src' target is built is quite inefficient with current implementation.

[MortenMacFly]

OK - looks like in the end you are right. This must have been introduced with one of the latest version: In previous builds, it was really not needed and C::B just silently "disabled" the crash report.

So - my favourite fix would be to move all libs in a lib folder, as suggested here already.  This is a mess anyways. But careful! At least one library (bz2 IIRC) is used twice by plugins.

For the moment I would remove the pre-build command as you suggested. I fact I did that to make sure that an old version of the DLL is removed.

[MortenMacFly]

...until the proper correction is done, an interim fix that works for me on Windows with all wx release versions is in SVN.

[stahta01]

So - my favourite fix would be to move all libs in a lib folder, as suggested here already.  This is a mess anyways. But careful! At least one library (bz2 IIRC) is used twice by plugins.

The lib name is different; likely to avoid this issue (IIRC, The help and devpak plugins are the ones.)

My long term fix used 3 local CB project custom vars of
CB_LIB poniting to lib folder
CB_BIN pointing to devel folder
CB_OBJ pointing to .objs folder

The reasons for the three CB custom vars are multiple of the build changes I want are easier if they exist.

@MortenMacFly: Would you test a Windows patch if I created it using these three custom vars?

If yes, I will start work on it once more.

Tim S.