Building Codeblocks 25.03 using the Self-Hosting method

[charles5577]

I recently bought a new computer and decided to reinstall the lastest versions of wxWidgets and Codeblocks. I had a link error stating that "exchndl.dll" was missing. It was obvious that I to rename the existing "exchndl.dll" to "exchndl.dll.dll". I did this and the build went fine and I updated. After building the ContribPlugins I did the update again. Copied the output file to a new directory and ran Codeblocks. It was missing "exchndl.dll". I then renamed "exchndl.dll.dll" to "exchndl.dll". Codeblocks ran fine.

While all of this worked it might be better to fix ths build procedure.

I have been using wxWidgets and Codeblocks for years. The combination is a good as any commercial IDE that I have used.

Keep up the good work!

[Miguel Gimenez]

The linker error would be helpful.

I use the self hosting method almost exclusively and never found this problem, even for clean compilations.

[stahta01]

From CodeBlocks_wx32_64.cbp

Code

<Add library="exchndl.dll" />

I can see the above line causing problems like the OP for some toolchains.

Tim S.

[charles5577]

I used CodeBlocks_wx32_64.cbp with the last version of TDM-GCC. The link error is:

C:/msys64/TDM-GCC/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lexchndl.dll
collect2.exe: error: ld returned 1 exit status

exchndl.dll does exist.

I changed the line in the project file to <Add library="exchndl" and got the same error. Changing the file extension of exchndl.dll also does not help.

Anyway, my original work around seems to work but it would be nice to find a "clean" solution.

[stahta01]

Your compiler likely wants "libexchndl.dll.a" file to be copied along with the "exchndl.dll" file.

Tim S.

[charles5577]

I have never heard of  linking with a dll. I also think there should be a "libexchndl.dll.a". The link command has the following:

-lcodeblocks -lexchndl.dll -lshfolder -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lcomctl32 -lodbc32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lwxmsw32u -mwindows

The first "-lcodeblocks" : codeblocks.dll and libcodeblocks.a are  created in the "devel32_64" directory. No problrm;

The second "-lexchndl.dll" : exchndl.dll is created in the "src\exchndl\win64\bin" directory. The is no export library (a or lib file). To be consistant there should be a "libexchndl.dll.a". There is a "src\exchndl\win64\lib" directory but it is empty.

To conform to usual practice:

1. "-lexchndl.dll" should be changed to "-lexchndl" in the link command
2. There should be a "exchndl.dll" in the "src\exchndl\win64\bin" directory. This is OK.
3. There should be a "libexchndl.a" in the "src\exchndl\win64\lib" directory.

I hope I am not wasting people's time on this.

[stahta01]

My "src/exchndl/win64/lib" contains both "libexchndl.dll.a" and "libmgwhelp.dll.a"; since yours does not I think you have a problem on your end!

Edit: I am using an svn repo!
Edit2: Add zipped file to this message
Edit3: Delete zipped file

Tim S.

[ollydbg]

...

To conform to usual practice:

1. "-lexchndl.dll" should be changed to "-lexchndl" in the link command
...

I hope I am not wasting people's time on this.

Maybe "-lexchndl" command line option is better, because in this case, the linker can directly link to the dll file or .a file.

See:

WIN32(LD)

For instance, when ld is called with the argument '-lxxx' it will attempt to find, in the first directory of its search path,

libxxx.dll.a
xxx.dll.a
libxxx.a
xxx.lib
libxxx.lib
cygxxx.dll (*)
libxxx.dll
xxx.dll

before moving on to the next directory in the search path.

[charles5577]

Thanks for all of the replies.

I just used stahta01's method. I used TortoiseSVN to download, rebuilt Codeblocks without issue and it runs fine. The previous download did not have all of the files that the SVN download had. Too bad I do not remember where I downloaded the first time.

Anyway, all is solved for me. And thanks to all for the replies.