User forums > Using Code::Blocks

Problem with wxWidgets

<< < (2/3) > >>

Pecan:

--- Quote from: calande on March 04, 2006, 06:57:55 pm ---"This application has failed to start because wxmsw26u_gcc_cb.dll was not found. Re-installing the application may fix this."

Problem is there is no installer...  :?

BTW, I am using mingw, would this be a problem? Does GCC work on Windows BTW? (Sorry, I've only used GCC on FreeBSD...)

--- End quote ---

--- Quote from: killerbot on March 04, 2006, 12:44:04 am ---Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
A link to the unicode windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26u_gcc_cb.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://download.berlios.de/codeblocks/mingwm10.7z

For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26_gcc_cb.7z

The 03 March 2006 build is out.
  - Windows : http://download.berlios.de/codeblocks/CB_20060303_rev2132_win32.7z
  - Linux : not supported yet

--- End quote ---

Notice that you can get the link libs from the same place you get the
nightly builds.

You can use the gcc and minGW that came with your codeblocks rc2.
With the nightly build you will be able to tell Codeblocks where to find
gcc.

pecan

duncanka:

--- Quote from: calande on March 04, 2006, 06:57:55 pm ---Thank you. I wasn't able to install the nightly build, I get the following error message:

"This application has failed to start because wxmsw26u_gcc_cb.dll was not found. Re-installing the application may fix this."

--- End quote ---
I received this same message when I tried to compile the latest SVN code and execute the devel version from within CB.  I have a wxmsw26u_gcc_custom.dll in the same folder as the executable, and I linked against a static library that was supposed to be using that DLL, yet I still keep getting this message.  Changing the DLL file's name to wxmsw26u_gcc_cb.dll only makes the problem worse - it tells me I don't have wxmsw26u_gcc_custom.dll, and even sooner in startup than the other way.  And if I have 2 copies, one with each name, it tells me some wxWidgets function isn't available in the DLL.  Any ideas?

takeshimiya:

--- Quote from: duncanka on March 17, 2006, 05:54:52 am ---
--- Quote from: calande on March 04, 2006, 06:57:55 pm ---Thank you. I wasn't able to install the nightly build, I get the following error message:

"This application has failed to start because wxmsw26u_gcc_cb.dll was not found. Re-installing the application may fix this."

--- End quote ---
I received this same message when I tried to compile the latest SVN code and execute the devel version from within CB.  I have a wxmsw26u_gcc_custom.dll in the same folder as the executable, and I linked against a static library that was supposed to be using that DLL, yet I still keep getting this message.  Changing the DLL file's name to wxmsw26u_gcc_cb.dll only makes the problem worse - it tells me I don't have wxmsw26u_gcc_custom.dll, and even sooner in startup than the other way.  And if I have 2 copies, one with each name, it tells me some wxWidgets function isn't available in the DLL.  Any ideas?

--- End quote ---

High likely you are experiencing DLL hell. Try to use the dll that was compiled for your version and never put it in a system dir.
And don't think that because they have the same name "wxmsw26u_gcc_cb.dll" they are compiled with the same settings (debug, unicode, etc), same compiler, same version, etc. :P

thomas:

--- Quote from: Takeshi Miya on March 17, 2006, 07:07:02 am ---High likely you are experiencing DLL hell.
--- End quote ---
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).

sethjackson:
I put the location (C:\wxWidgets-2.6.2\lib\gcc_dll) of the wx DLL in my path variable this avoids problems with DLL's.....

Navigation

[0] Message Index

[#] Next page

[*] Previous page