News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

Environment var "Path" problem

Started by kisoft, July 24, 2012, 03:26:44 PM

Previous topic - Next topic

kisoft

I have a problem with PATH on run my project from Code::Blocks.

You can see a test project into attached archive (MinGW project, Windows XP SP3).

Steps for test:
1. Add element to the PATH environment variable. Element - is relative path(!!!), for ex. "..\dll".
  1.1. For example: "PATH=ABC;"
  1.2. After addition: "PATH=ABC;..\dll;"
2. Start Code::Blocks and load a my test project. Rebuild it and start.
  2.1. Output see like this: "PATH=ABC;Programs\dll" instead "PATH=ABC;..\dll". Wrong. Why Code::Blocks do resolved a ".." to  relative path?
3. Close project and quit from Code::Blocks.
4. Start from command line: gcctest.exe
  4.1. Output see like this: "PATH=ABC;..\dll". Ok.

On revision 7929 Code::Blocks worked by 4.1., on revision 8153 - by 2.1.

Question: Why Code::Blocks do resolved a ".." to relative path?

Windows XP SP3 32-bit.
Code::Blocks rev. 7929 & 8153 (self compiled versions)
wxWidgets 2.8.12
gcc.EXE (tdm-1) 4.5.2

Thanks! Sorry for my bad english.
OS: WinXPSP3
wxWidgets: 2.8.12
CodeBlocks: Master github cbMakefileGen plugin:
[url="https://github.com/kisoft/cbmakefilegen"]https://github.com/kisoft/cbmakefilegen[/url]

ollydbg

I can confirm this bug. But no time to dig further, I think you can read and debug the code in compiler plugin

void CompilerGCC::SetupEnvironment()
.....
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

Quote from: ollydbg on August 30, 2012, 05:39:44 PM
I can confirm this bug. But no time to dig further, I think you can read and debug the code in compiler plugin

void CompilerGCC::SetupEnvironment()
.....

This function is called when the compiler plugin was loaded in CB start up.
I just enabled the debug log in this function(it log out the PATH before and after the change), I can confirm that the value "..\dll" was changed to something like "src\dll" like string.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

kisoft

Thanks, ollydbg!

I will try see this method and debug it.

I have no time too, but will try read and debug.

Good luck!
OS: WinXPSP3
wxWidgets: 2.8.12
CodeBlocks: Master github cbMakefileGen plugin:
[url="https://github.com/kisoft/cbmakefilegen"]https://github.com/kisoft/cbmakefilegen[/url]

ollydbg

I found the bug, to reproduce this bug, you can try the code below:

   wxPathList pathArray;
   pathArray.AddEnvList(_T("PATH"));  // 1
   pathArray.Add(_T("..\\dll"));           // 2

   wxPathList newPathArray;
   newPathArray.Add(pathArray);       //3


1, if you have "..\\xyz" like string in your PATH, those string will directly added to pathArray without any normalization.
2, wxWidgets will internally call "wxFileName::Normalize" in somewhere to expand the "..", so when this finished, you get a changed value, in my case, ".." was converted to "SomeParentPath", so you get something like "SomeParentPath\\dll" in the pathArray.
3, when running the step 3, wxWidgets will run "Normalize" on every piece of the pathArray, so there will be no ".." in the newPathArray.

Note: In the compiler plugin's source code, there is no such "step 2", so ,initially, the pathArray is OK, but it do have a "step 3", so finally, your ".." will be expanded.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.