High likely you are experiencing DLL hell.
This is
not "DLL hell". The correct DLL (the one the app linked to) is just missing. Missing, that means not necessarily missing entirely, but missing in the sense that the OS can't find it.
You can technically use the DLL that you have been using (wxmsw26u_gcc_cb.dll) if you have compatible import libraries, but that is not good practice.
If you have any possibility, you should compile your own from scratch (or use a library from a DevPak).
EDIT: Also, if you have several versions of import libraries and DLLs, make sure you set up your linker paths correctly while building, so it really uses the one you think it does.
To run the program, you need a copy of the same library (same name and same build) somewhere the OS can find it. One safe way to accomplish this is to copy it to the program's directory. But be sure it is the right one. The
custom version will not work in place of the
cb version or vice versa (nor will two arbitrary
custom versions from different people). Renaming another DLL is an extremely bad idea since it may cause the weirdest things, for example your app may start at first and crash for unknown reason later.
Another way to have a copy of the same library around is to copy it to a system folder (e.g.
C:\windows\system32). This is not a good practice for distributing your software, and it requires prudence, as
this can indeed lead to DLL hell.
What you absolutely have to keep in mind when doing this is that there must not be different versions with the same name in different locations. The loader will search the locations given by the PATH variable and pick the first DLL it finds, and this is not necessarily the one you want.
Nevertheless, although putting DLLs into the system folder is evil for the above reason, it can still be a valid option for you while developing, because it saves you from copying the same DLL over and over again for each and every program you write (which can be a pain).
