WineHQ
Bug Tracking Database – Bug 31057

 Bugzilla

 

Last modified: 2014-01-03 13:09:57 UTC  

makefile(3) : fatal error U1034: syntax error : separator missing

First Last Prev Next    This bug is not in your last search results.
Bug 31057 - makefile(3) : fatal error U1034: syntax error : separator missing
makefile(3) : fatal error U1034: syntax error : separator missing
Status: CLOSED FIXED
AppDB: Show Apps affected by this bug
Product: Wine
Classification: Unclassified
Component: msvcrt
1.5.5
x86-64 Linux
: P2 normal
: ---
Assigned To: Mr. Bugs
: download, Installer, testcase
Depends on: 31039
Blocks:
  Show dependency tree
 
Reported: 2012-06-28 07:00 UTC by Mathieu Malaterre
Modified: 2014-01-03 13:09 UTC (History)
8 users (show)

See Also:
Regression SHA1:
Fixed by SHA1: 6122c2ba37a8871c6118d0596e9576b17660f581
Distribution: ---
Staged patchset:

Attachments
Makefile (29 bytes, text/plain)
2012-06-28 07:01 UTC, Mathieu Malaterre 		Details
main.cpp (92 bytes, text/plain)
2012-06-28 07:01 UTC, Mathieu Malaterre 		Details
Makefile in utf-16 (32 bytes, application/octet-stream)
2013-05-06 06:44 UTC, Dmitry Utkin 		Details
commands and tests (1.68 KB, text/plain)
2013-06-03 05:05 UTC, Dmitry Utkin 		Details
commands and tests (1.68 KB, text/plain)
2013-06-03 05:08 UTC, Dmitry Utkin 		Details
minimal reproducer (371 bytes, text/plain)
2013-11-11 03:39 UTC, Roman Kagan 		Details
Show Obsolete (1) View All Add an attachment (back traces, logs, proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Malaterre 2012-06-28 07:00:43 UTC 
Wine does install VS 2005 Express nicely. Nmake & cl.exe are working as should.

However when installing VS 2005 C++ SP1, everything starts failing. For instance nmake stops working, and report:


>nmake

Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

makefile(3) : fatal error U1034: syntax error : separator missing
Stop.


Steps:

$ rm -rf $HOME/.wine
$ winetricks --no-isolate vc2005express
$ wget http://download.microsoft.com/download/7/7/3/7737290f-98e8-45bf-9075-85cc6ae34bf1/VS80sp1-KB926748-X86-INTL.exe
$ wine VS80sp1-KB926748-X86-INTL.exe

hint: you may need to run twice 'wine VS80sp1-KB926748-X86-INTL.exe' to get it working. Sometimes using 'winetricks vcrun2005' helps out...

Anyway from wine then simply do:

$ wine cmd
> "%VS80COMNTOOLS%vsvars32.bat"
> nmake

Here is the simple Makefiles I am using:

$ cat Makefile
foo: main.cpp
	cl main.cpp

Thanks !
Comment 1 Mathieu Malaterre 2012-06-28 07:01:07 UTC 
Created attachment 40767 [details]
Makefile
Comment 2 Mathieu Malaterre 2012-06-28 07:01:28 UTC 
Created attachment 40768 [details]
main.cpp
Comment 3 Dan Kegel 2012-06-28 11:31:03 UTC 
Even running the sp1 twice didn't let it install for me; see bug 31039.
Comment 4 Austin English 2012-06-28 12:43:42 UTC 
May be invalid, depends on bug 31039.
Comment 5 Mathieu Malaterre 2012-06-28 15:31:12 UTC 
I am using a somewhat patched wine 1.5.5 (*). I could not get wine 1.5.7 to simply install 'winetricks vc2005express'. So you may want to revert to an older wine to get SP1 to install.

(*) http://dev.carbon-project.org/debian/wine-unstable/
Comment 6 Dmitry Utkin 2013-05-01 13:17:46 UTC 
I have same thing with Windows SDK provided NMAKE when nmake is started _under the same architecture_ as WINEARCH.

When I start 32-bit nmake.exe under 32-bit wineprefix (and win32 winearch) it cause that error.

When I start 64-bit nmake.exe under 64-bit wineprefix (and x64 winearch) it cause that error.

But, when I start 32-bit nmake.exe under 64-bit wineprefix (and x64 winearch) it works well.

This bug is reproduced even on that simple makefile as such:

----
all:
    echo ok
----

I have that makefile in the same dir as nmake.exe for clear experiment (without calling any vcvars32.bat).

My commands are:

----
cd "~/.wine~x86/drive_c/Program Files/Microsoft Visual Studio 10.0/VC/bin"
WINEPREFIX=~/.wine~x86 WINEARCH=win32 wine cmd
nmake
----

I can attach any logs or any additional info to help you fix that bug.
Comment 7 Dmitry Utkin 2013-05-06 06:42:25 UTC 
Looks like issue is related to Unicode support.

I you convert Makefile to UTF-16 using iconv, nmake works!

iconv -futf-8 -tutf-16 Makefile >Makefile1
mv Makefile Makefile~
mv Makefile1 Makefile

Example of Makefile that is in UTF-16 encoding is in attach.
Comment 8 Dmitry Utkin 2013-05-06 06:44:45 UTC 
Created attachment 44382 [details]
Makefile in utf-16

nmake works with this Makefile (it's in UTF-16/UNICODE), but does not work with makefiles in multibyte encodings.
Comment 9 Hin-Tak Leung 2013-06-01 21:58:35 UTC 
This appears to be a regression. I am on the same machine and $WINEPREFIX (more or less) as 3 years ago, and I just haven't used vc in wine for that long. See bug 21890 /21394  - back in mid 2010, nmake used to work very well, with wine 1.1.{35-44}.

I just remembered - the last time I used it successfully was with gs 9.06, so it was August 2012, less than 10 months ago. It would have been with 1.5.10 or 1.5.11 .

I tried unsetting LANG and LC_* (maybe I need to go further with winserver, etc) but no improvements.

At first I suspect upstream code change. But doing iconv -f utf8 -t utf16 works, and it is just painful to do it for all 90+ included makefiles....

one possibility is that the same binary of nmake behaves differently depends on OS version...
Comment 10 Dan Kegel 2013-06-01 22:14:41 UTC 
Can you confirm that the makefile has tabs, not spaces?
Comment 11 Dmitry Utkin 2013-06-03 05:05:57 UTC 
Created attachment 44638 [details]
commands and tests

I made advanced testing. Results are in attachment.
Comment 12 Dmitry Utkin 2013-06-03 05:08:02 UTC 
Created attachment 44639 [details]
commands and tests
Comment 13 Hin-Tak Leung 2013-06-06 07:14:34 UTC 
(In reply to comment #10)
> Can you confirm that the makefile has tabs, not spaces?

Yes. nmake is now aborting and complaining about the 2nd line (the first 20+ lines are comments). It isn't reaching the parts where tabs vs spaces matter. (and the makefiles are correct with tabs as far as I see).
Comment 14 Hin-Tak Leung 2013-06-12 06:56:05 UTC 
I have something different: I have both VC8 (2005) and VC9 (2008, part of sdk 7). nmake from vc8 is working, nmake in vc9 is broken. Both used to work. HTA.
Comment 15 Roman Kagan 2013-11-08 09:44:09 UTC 
Me too:

wine-1.7.5 packaged with Fedora 19
nmake from WDK7.1
clean WINEPREFIX, with only a few basic MSI packages from WDK installed via msiexec.

Also experimented a bit around comment 6 and comment 7.

In my experiments WINEARCH didn't make any difference.

What did, however, was the presence of the byte-order mark at the beginning of the Makefile.

E.g.

# echo -e 'all:\n\techo ok' > Makefile
# wine nmake.exe -nologo
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
makefile(3) : fatal error U1034: syntax error : separator missing
Stop.

the same with UTF-8 BOM:

# echo -e '\xef\xbb\xbfall:\n\techo ok' > Makefile
wine nmake.exe -nologo
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
        echo ok
fixme:file:NeedCurrentDirectoryForExePathW (L"echo"): partial stub
ok


Ditto with the recipe from comment 7: if you use iconv ... -t utf-16le which omits BOM, nmake still fails to parse the Makefile correctly.
Comment 16 Dmitry Timoshkov 2013-11-08 10:08:21 UTC 
Does it help if you make sure that all lines in Makefile end with \r\n and
tabs are in proper starting positions?
Comment 17 Roman Kagan 2013-11-08 10:19:34 UTC 
(In reply to comment #16)
> Does it help if you make sure that all lines in Makefile end with \r\n and
> tabs are in proper starting positions?

No.  All that seem to matter is BOM.

# echo -e 'all:\n\techo ok' > Makefile
# unix2dos Makefile
unix2dos: converting file Makefile to DOS format ...
# wine nmake.exe -nologo
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
makefile(3) : fatal error U1034: syntax error : separator missing
Stop.


# echo -e 'all:\n\techo ok' > Makefile
# unix2dos --add-bom Makefile 
unix2dos: converting file Makefile to DOS format ...
# wine nmake.exe -nologo
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
        echo ok
fixme:file:NeedCurrentDirectoryForExePathW (L"echo"): partial stub
ok
Comment 18 Roman Kagan 2013-11-11 03:22:13 UTC 
I seem to have narrowed it down to a problem with msvcrt.ungetwc() on a file lacking BOM:

with BOM (working):

# echo -e '\xef\xbb\xbfall:\n\techo ok' > Makefile
# WINEDEBUG=trace+relay wine nmake.exe 2>&1 | grep -F msvcrt.
...
0009:Call msvcrt._wfsopen(0012ed70 L"makefile",00401368 L"rt,ccs=unicode",00000020) ret=0040a88e
0009:Ret  msvcrt._wfsopen() retval=7ef14220 ret=0040a88e
0009:Call msvcrt.fgetwc(7ef14220) ret=00407fd8
0009:Ret  msvcrt.fgetwc() retval=00000061 ret=00407fd8
0009:Call msvcrt.ungetwc(00000061,7ef14220) ret=0040a358
0009:Ret  msvcrt.ungetwc() retval=00000061 ret=0040a358
0009:Call msvcrt.fgetwc(7ef14220) ret=00407fd8
0009:Ret  msvcrt.fgetwc() retval=00000061 ret=00407fd8
0009:Call msvcrt.fgetwc(7ef14220) ret=00407fd8
0009:Ret  msvcrt.fgetwc() retval=0000006c ret=00407fd8
0009:Call msvcrt.fgetwc(7ef14220) ret=00407fd8
0009:Ret  msvcrt.fgetwc() retval=0000006c ret=00407fd8
0009:Call msvcrt.fgetwc(7ef14220) ret=00407fd8
0009:Ret  msvcrt.fgetwc() retval=0000003a ret=00407fd8
0009:Call msvcrt.ungetwc(0000003a,7ef14220) ret=00409b56
0009:Ret  msvcrt.ungetwc() retval=0000003a ret=00409b56
0009:Call msvcrt._wcsicmp(00422178 L"all",0040178c L"include") ret=0040a23a
0009:Ret  msvcrt._wcsicmp() retval=fffffff8 ret=0040a23a
...


without BOM (non-working):

# echo -e 'all:\n\techo ok' > Makefile
# WINEDEBUG=trace+relay wine nmake.exe 2>&1 | grep -F msvcrt.
...
0009:Call msvcrt._wfsopen(0012ed70 L"makefile",00401368 L"rt,ccs=unicode",00000020) ret=0040a88e
0009:Ret  msvcrt._wfsopen() retval=7ef07220 ret=0040a88e
0009:Call msvcrt.fgetwc(7ef07220) ret=00407fd8
0009:Ret  msvcrt.fgetwc() retval=00000061 ret=00407fd8
0009:Call msvcrt.ungetwc(00000061,7ef07220) ret=0040a358
0009:Ret  msvcrt.ungetwc() retval=ffffffff ret=0040a358
0009:Call msvcrt.fgetwc(7ef07220) ret=00407fd8
0009:Ret  msvcrt.fgetwc() retval=00000000 ret=00407fd8
0009:Call msvcrt.fgetwc(7ef07220) ret=00407fd8
0009:Ret  msvcrt.fgetwc() retval=0000006c ret=00407fd8
0009:Call msvcrt.fgetwc(7ef07220) ret=00407fd8
0009:Ret  msvcrt.fgetwc() retval=0000006c ret=00407fd8
0009:Call msvcrt.fgetwc(7ef07220) ret=00407fd8
0009:Ret  msvcrt.fgetwc() retval=0000003a ret=00407fd8
0009:Call msvcrt.ungetwc(0000003a,7ef07220) ret=00409b56
0009:Ret  msvcrt.ungetwc() retval=0000003a ret=00409b56
0009:Call msvcrt._wcsicmp(00422178 L"",0040178c L"include") ret=0040a23a
0009:Ret  msvcrt._wcsicmp() retval=ffffff97 ret=0040a23a
...


Note that in the latter case ungetwc() fails but apparently nmake ignores the error, then the following fgetwc() returns null, which screws up everything else.
Comment 19 Roman Kagan 2013-11-11 03:39:42 UTC 
Created attachment 46500 [details]
minimal reproducer

Minimal reproducer for the ungetwc() problem.

Build with MSVC:

cl -MD repro.c

or mingw32:

i686-w64-mingw32-gcc repro.c -o repro.exe

Run:

# echo -e '\xef\xbb\xbfhi there' > Makefile
# wine repro.exe
hi there
# echo 'hi there' > Makefile
# wine repro.exe
#
Comment 20 Roman Kagan 2013-11-11 04:50:23 UTC 
Looking at the source code, there appears to be a mismatch between MSVCRT_fgetwc() and MSVCRT_ungetwc(): the latter ignores all the smartness of the former, and just feeds all the bytes of its argument to MSVCRT_ungetc() one by one.

However, in case of a file without BOM, the file position after the first fgetwc() is rightfully 1; as a result, only one of the two MSVCRT_ungetc() succeeds.
Comment 21 Dan Kegel 2013-11-11 09:09:59 UTC 
Confirming & setting component to msvcrt
Comment 22 Roman Kagan 2013-11-11 14:04:10 UTC 
Care to update the version as well?  The bug is present in the current git master.
Comment 23 Dan Kegel 2013-11-11 14:08:24 UTC 
The version field means "the version this bug was first seen in", so it should not usually be updated.
Comment 24 bbeschow 2013-12-01 14:44:02 UTC 
I could get nmake of the psdkwin7 package work again with wine 1.7.7 like this:

1) start winecfg
2) go to the "Libraries" tab
3) add new override for library "msvcr90"
4) select "Native (Windows)" after pressing the "Edit" button
=> have fun
Comment 25 Piotr Caban 2013-12-31 03:24:52 UTC 
It's probably fixed by commit 6122c2ba37a8871c6118d0596e9576b17660f581. Please retest.
Comment 26 bbeschow 2014-01-03 07:36:07 UTC 
Yes, with current master I'm able to run nmake w/o the workaround for msvcr90.dll. Thanks for the fix!
Comment 27 Anastasius Focht 2014-01-03 07:46:14 UTC 
Hello folks,

reported fixed by commit http://source.winehq.org/git/wine.git/commitdiff/6122c2ba37a8871c6118d0596e9576b17660f581

Thanks Piotr

Regards
Comment 28 Alexandre Julliard 2014-01-03 13:09:57 UTC 
Closing bugs fixed in 1.7.10.
First Last Prev Next    This bug is not in your last search results.

Privacy Policy
If you have a privacy inquiry regarding this site, please write to [email protected]

Hosted By CodeWeavers