Passing User Variables to make works weird

[osnwt]

Yesterday started my evaluation of VisualGDB. But found an issue and need help.

In my project I want to use user-defined path to cross toolchain which has a default value (relative path to the project location) but can be redefined on per user basis. Then I use this variable in makefiles to define binary dir and extra include locations. The problem I found is that the value of user variable not always is passed to make (or for some reason not always is visible by make). Sometimes it works as desired, sometimes not. How to reproduce:

User variable defined in VisualGDB properties:

CROSS_TOOLCHAIN_ROOT=../../../toolchains/i486-vortex86dx-linux-gnu-4.8.1

debug.mak contains these lines:

$(shell cmd /c /Apps/MinGW/msys/1.0/bin/env.exe >env.txt)

$(error CROSS_TOOLCHAIN_ROOT="$(CROSS_TOOLCHAIN_ROOT)")

The results of build command:
env.txt contains:

CROSS_TOOLCHAIN_ROOT=../../../toolchains/i486-vortex86dx-linux-gnu-4.8.1

But error message is:

C:Workworkabm2compdebug.mak(16): error : CROSS_TOOLCHAIN_ROOT="".  Stop.

That is, environment of started by make shell contains the variable, but make does not see it for some reason. And $(origin) tells “undefined” for the variable. But SOMETIMES it works as expected.

I have no clue what happens. Any ideas?

[support]

Hi,

Does that happen with a stock version of make.exe that comes with MinGW, or are you using some custom make executable?

[osnwt]

I tried both stock binary and also “official” win32 gmake binary: results were identical.

Actually, it even doesn’t look like a WinDBG bug, but I have never seen that behaviour. Also I tried to run make like:

(cmd.exe shell)> make CROSS_COMPILER_PATH=xxx
Result: origin=command line

(sh prompt from msysGit) CROSS_COMPILER_PATH=xxx make
Result: origin=environment

(t.cmd batch file):

set CROSS_TOOLCHAIN_ROOT=xxx
"C:Program Files (x86)SysprogsVisualGDBmake.exe"

Result: origin=environment

In all cases the variable was defined and $(origin) said “command line” and “environment”, accordingly.

So I suspect that somehow environment passed to make from WinDGB isn’t recognized by make.
And stressing once again: SOMETIMES it worked.

PS. Just tried again: it works. Maybe I should have PC rebooted for that (and I yesterday did that). Usually I do not reboot my laptop for weeks (but suspend to RAM). I will try to reproduce it or at least to find out more details.

[support]

Hi,

This looks like it may be related to the environment block size limit. The older versions of Windows had it limited to 32K and some programs may still have it hardcoded. Try cleaning up some unused environment variables and see if that solves the problem.

[osnwt]

Yes, I also thought about that. But using Win7 x64, I’ve never had any problem with env size, and it hardly can be called too old version. My environment has around 2K of data, so it should not be a problem. But still I’ve rebooted the system to see if it helps.

[support]

Hi,

Your Windows itself may not have the limit, but the GNU make may have been compiled with an old version of the cygwin/MinGW runtime that does. That would explain why the shell started from the Make sees the variable, but the Make itself ignores it.
If this is a critical issue, you could rebuild the Make binary from sources and step through it to see why the variables are lost. Let us know if you need instructions on that.

[Author]

Posts