[Bug 46901] New: Path environment variable with nested variables is not expanded properly

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=46901

            Bug ID: 46901
           Summary: Path environment variable with nested variables is not
                    expanded properly
           Product: Wine
           Version: 4.0
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: wine-bugs at winehq.org
          Reporter: scorpion8182 at googlemail.com
      Distribution: ---

Created attachment 63979
  --> https://bugs.winehq.org/attachment.cgi?id=63979
Registry entries for HKCU\Environment\PATH

I am trying to set up a crosscompile environment under Linux targeting MSVC.
For that purpose I have copied the contents of a MS VC Build Tools and Win 10
SDK installation to two folders under /opt, basically. Afterwards I added
entries to the PATH environment variable to construct the Pathes to the
compiler, the includes and the libs. My target is to be able to invoke the
tools (compiler, linker, resource compiler) without prepending the path.
Those path entries start with the Z: drive, pointing to Z:\opt .
The attached screenshots show what i entered in the registry under
HKCU\Environment\PATH.

Now, when i try to invoke the cl.exe compiler for example from a wine cmd
like

WINEPREFIX=/home/martin/wine-vc14-64 wine cmd

i get following output:
Z:\home\martin\Schreibtisch\Blender_DEV_gitlab\blender>cl.exe
'cl.exe' could not be recognized as internal or external command or as batch
script.

(Original german output:)
'cl.exe' konnte nicht als interner oder externer Befehl
oder als Batch-Skript erkannt werden.

But 

echo %PATH%

shows:

C:\windows\system32;C:\windows;C:\windows\system32\wbem;C:\ninja;Z:\opt\msvc\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64;Z:\opt\winsdk\win10sdk\bin\10.0.17763.0\x64

so the path at this place seems to be correctly expanded. But the file cl.exe
being there cannot be found.

This breaks the crosscompile invocation scheme. (CMake doesnt find it, etc etc)

I have also asked this question in IRC and i was recommended to file a bug
report, since this works correctly under windows.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.