User forums > Help
#include <iostream> NO such File or Directory
reckless:
aye that makes sense codeblocks seems to pickup compiler path if its set in environment variables i can confirm that.
atleast its easy to fix once known maybe a good idea to sticky it ?
reason i wasnt sure about its handling of long pathnames is if i use C:\program files <- ups space in name \codeblocks atleast msys gave me some trouble there unless i used the dos short version.
happy you got it fixed though :)
reckless:
checked dev-cpp installation and indeed it does set the compiler path in the system PATH the uninstall feature doesnt remove it though so seems like an oversight.
i guess the reason why codeblocks picks it up is it checks both registry and path and maybe executable names before checking its own directory ?
ofc with so many supported compilers this can get a bit hairy especially if the user had several different compilers at some point.
for instance i once used open watcom while having msvc installed also and every time i tried to build something it failed miserably to my horror i found out that watcom picked up the msvc compilers paths before its own and msvc had no idea of the watcom directory structure hence it failed every time cause the headers and libraries were not where it expected.
i since ditched msvc completly and just use the windows sdk's with mingw/codeblocks.
Okaya:
--- Quote from: reckless ---reason i wasnt sure about its handling of long pathnames is if i use C:\program files <- ups space in name \codeblocks atleast msys gave me some trouble there unless i used the dos short version.
--- End quote ---
Yes, I had an issue too when using GCC via msys, but so long as I used double quotes whenever refering to long directory names (e.g. cd C:/"Program Files"/CodeBlocks), it worked fine.
--- Quote from: reckless ---checked dev-cpp installation and indeed it does set the compiler path in the system PATH the uninstall feature doesnt remove it though so seems like an oversight.
i guess the reason why codeblocks picks it up is it checks both registry and path and maybe executable names before checking its own directory ?
--- End quote ---
That's interesting, thanks a lot for checking that. I checked my PATH variable now and it's clean (no Dev-C++ leftovers), I suppose that resetting the compiler directory in CodeBlocks fixed that too.
--- Quote from: reckless ---ofc with so many supported compilers this can get a bit hairy especially if the user had several different compilers at some point.
--- End quote ---
Yes, I suppose so. In fact, it seems that's probably the reason for my erratic compiler behavior for some time now. I've installed Dev-C++ and MSVC++ in the past, before setting up CodeBlocks. I have uninstalled both at the moment, but it seems that there are certain traces left behind in the system from them. For instance, until recently, although .cpp and .h files were set to open with CodeBlocks as the default program, their "Type" attribute was still given as "MS Visual C++ .cpp file" I think. I had to manualy remove some leftover components from MSVC via "Add or Remove Programs" for the file type to stop being affected by it.
--- Quote from: reckless ---atleast its easy to fix once known maybe a good idea to sticky it ?
--- End quote ---
I wonder if others having the same problem have been using multiple compilers too. I don't know if resetting Compiler Install Directory would fix it for everyone, but if anyone's got the same issues occurring, it's probably a good thing to check.
Okaya
Jenna:
Older versions of C::B (including the 8.02 release) use the path and check whether the configured path is included. If another MinGW installation comes earlier in path this one is used.
Newer version (nightlies) always put the configured compiler-directory at the top of the path.
Of course this will also be included in the coming release.
Okaya:
That's very helpful jens, thank you for this clarification.
Okaya
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version