User forums > Announcements
About few annoyances with RC2 (for some people)
null:
I keep getting an error message when I start up CodeBlocks, after the splash window disappears but before the main window pops up. The message is 'The procedure entry point _ZN11TiXmlStringaSEPKc could not be located in the dynamic link library codeblocks.dll'. I kept the preferences from a previous installation (RC1-1) when I uninstalled it. Also, I had replaced some files from a CVS build overtop of the RC1-1 installation, so maybe an older version of something somehow managed to stick around. So this might not be a bug exactly, it might be my fault. Any ideas why I'm getting this error?
Also, CodeBlocks doesn't seem to remember my previous (most recent) workspace file. It keeps opening a much older one when it first starts. I might be misunderstanding the setting 'use default workspace'. (What defines 'default'?)
PS. C::B RC2 r0x0rz. Thanks so much for this wholesome opensource goodness! Soon... soon I will 'uninstall' the filth that is Visual Studio, and 'rm -rf' the horror that is KDevelop.
MortenMacFly:
--- Quote from: null on October 28, 2005, 10:47:59 am ---'The procedure entry point _ZN11TiXmlStringaSEPKc could not be located in the dynamic link library codeblocks.dll'
--- End quote ---
This error seems to origin from a wrong version/linking of the tinyxml library embedded in Code::Blocks. You seem to mix several versions of Code::Blocks DLL's (and therefore libraries) together. This cannot be good. I would strongly recommend a fresh re-install and the issues should be resolved.
I believe this is not a RC2 related issue.
Morten.
null:
--- Quote from: MortenMacFly on October 28, 2005, 10:59:38 am ---
--- Quote from: null on October 28, 2005, 10:47:59 am ---'The procedure entry point _ZN11TiXmlStringaSEPKc could not be located in the dynamic link library codeblocks.dll'
--- End quote ---
This error seems to origin from a wrong version/linking of the tinyxml library embedded in Code::Blocks. You seem to mix several versions of Code::Blocks DLL's (and therefore libraries) together. This cannot be good. I would strongly recommend a fresh re-install and the issues should be resolved.
I believe this is not a RC2 related issue.
Morten.
--- End quote ---
I suspected as much. I uninstalled again, and reinstalled again, and now everything seems to be working fine. Wierd how uninstalling the first time left old stuff behind. :P
MortenMacFly:
I found out that for (static) libraries there is an issue if one uses custom variables for the output folder. This applies at least to the GCC compiler/archivar but maybe others are affected, too.
Steps to reproduce:
1.) Create a static library project (from the template)
2.) Set as output directory for the lib to: $(LIB_DIR_VAR)mylibname.a (note the missing folder separator)
3.) Build
Result: It works (so far!)
4.) Set the custom variable LIB_DIR_VAR to point to a directory, e.g. "D:\MyDir\" (note the trailing folder separator)
5.) Rebuild
Result: The "ar" command fails with:
ar.exe: libD:\MyDir\libmylibname.a: Invalid argument
As you can see the "lib" prefix is obviously added before (!) the environment variable is being translated.
It works, if one uses $(LIB_DIR_VAR)\mylibname.a and LIB_DIR_VAR points to "D:\MyDir" (note the added / removed folder separator).
However: it would work in both cases, if the LIB_DIR_VAR would first be translated and then the "lib" prefix added.
Why am I doing this the other way?
I wanted to have a specific output folder for the libraries in a cross-platform project (Windows and Linux). Thus by just replacing the variable I can set the output folder in the project and the libraries are being created wherever desired. Hence, if I choose the second variant (the working one) leaving out to set the LIB_DIR_VAR variable would leave as output: "/mylibname.a" which is unfortunately the root folder (!) on Linux - which is no good. What I wanted to have then is an output to the project folder which would be the case in the first variant because this leaves "mylibname.a".
I tried to explain as good as possible, hopefully (someone) will understand... :lol:
Morten.
MortenMacFly:
--- Quote from: MortenMacFly on October 30, 2005, 08:08:42 pm ---I found out that [...]
--- End quote ---
I filed this bug on sourceforge as well for better monitoring. One may ignore the message above... Sorry.
Morten.
Navigation
[0] Message Index
[*] Previous page
Go to full version