Linker error when building on Windows 10 x64

[IndyJones]

I have a problem building the latest VirtualBox OSE on Windows 10 x64. I get the following error - no matter if I compile for x86/x64 or debug/release:

Code: Select all

kBuild: Linking bin2c
C:/Users/xxx/AppData/Local/Temp/make12000-1.sh: 1: Syntax error: "(" unexpected
kmk: *** [D:/VirtualBox/out/win.x86/release/obj/bin2c/bin2c.exe] Error 2 (0x2)
The failing command:
@  C:/PROGRA~2/MICROS~4.0/VC/bin/link.exe -nologo -machine:x86                           -Ignore:4197 /NOD /INCREMENTAL:NO /MAPINFO:EXPORTS /LargeAddressAware /DynamicBase /NxCompat /Release /Debug /Opt:Ref /Opt:Icf /Version:501.51 /DISALLOWLIB:libcd.lib /DISALLOWLIB:libcmtd.lib /DISALLOWLIB:msvcrt.lib /DISALLOWLIB:msvcrtd.lib /DISALLOWLIB:msvcprt.lib /DISALLOWLIB:msvcprtd.lib      /OUT:D:/VirtualBox/out/win.x86/release/obj/bin2c/bin2c.exe /MAPINFO:EXPORTS /INCREMENTAL:NO /MAP:D:/VirtualBox/out/win.x86/release/obj/bin2c/bin2c.map    /LIBPATH:C:/Program  /LIBPATH:Files  /LIBPATH:(x86)/Microsoft  /LIBPATH:SDKs/Windows/v7.1A/Lib @D:/VirtualBox/out/win.x86/release/obj/bin2c/bin2c.rsp
kmk: *** [D:/VirtualBox/out/win.x86/release/obj/bin2c/bin2c.exe] Deleting file `D:/VirtualBox/out/win.x86/release/obj/bin2c/bin2c.rsp'

Obviously the linker command line is screwed because of the blanks in the SDK path for the library path (/LIBPATH).
I have also tried to call --with-sdk="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A" in the configure script but that didn't change anything.
I have attached the whole build output.
Any ideas what could be the problem?

[CaptainFlint]

The problem is, path with spaces was split into components, each of them treated as separate path:

Code: Select all

/LIBPATH:C:/Program  /LIBPATH:Files  /LIBPATH:(x86)/Microsoft  /LIBPATH:SDKs/Windows/v7.1A/Lib

You need to use short DOS paths instead.

[IndyJones]

I already tried to specify the SDK path as a short path (i.e. --with-sdk="C:\PROGRA~2\MICROS~3\Windows\v7.1A").
But without success - I get the same error ...

[CaptainFlint]

Check what you have in your AutoConfig.kmk after calling configure.vbs.

[IndyJones]

AutoConfig.kmk looks correct:

Code: Select all

# -*- Makefile -*-
#
# Build configuration generated by cscript configure.vbs --with-kbuild=C:/kBuild/kBuild --with-ddk=C:/WinDDK/7600.16385.1 --with-mingw32=c:/mingw --with-libsdl=c:/SDL --with-openssl=c:/OpenSSL-1-0-1 --with-libcurl=c:/libcurl --with-python=C:/Python27 --with-qt5=C:/Qt/5.6.1/Qt5 --with-sdk=C:\PROGRA~2\MICROS~3\Windows\v7.1A
#
VBOX_OSE := 1
VBOX_VCC_WERR = $(NO_SUCH_VARIABLE)
PATH_SDK_WINDDK71     := C:/WinDDK/7600.16385.1
VBOX_WITH_WDDM_W8     := 
PATH_TOOL_VCC100      := C:/PROGRA~2/MICROS~4.0/VC
PATH_TOOL_VCC100X86   := $(PATH_TOOL_VCC100)
PATH_TOOL_VCC100AMD64 := $(PATH_TOOL_VCC100)
PATH_SDK_WINPSDK71    := C:/PROGRA~2/MICROS~3/Windows/v7.1A
VBOX_WINPSDK          := WINPSDK71
VBOX_MAIN_IDL         := C:/PROGRA~2/MICROS~3/Windows/v7.1A/bin/Midl.exe
PATH_TOOL_MINGW32     := C:/mingw
PATH_SDK_W32API       := c:/mingw
VBOX_WITH_OPEN_WATCOM := 
PATH_SDK_LIBSDL       := C:/SDL
SDK_VBOX_OPENSSL_INCS := C:/OpenSSL-1-0-1/include
SDK_VBOX_OPENSSL_LIBS := C:/OpenSSL-1-0-1/lib/ssleay32.lib C:/OpenSSL-1-0-1/lib/libeay32.lib
SDK_VBOX_BLD_OPENSSL_LIBS := C:/OpenSSL-1-0-1/lib/ssleay32.lib C:/OpenSSL-1-0-1/lib/libeay32.lib
SDK_VBOX_LIBCURL_INCS := C:/libcurl/include
SDK_VBOX_LIBCURL_LIBS := C:/libcurl/libcurl.lib
PATH_SDK_QT5          := C:/Qt/5.6.1/Qt5
PATH_TOOL_QT5         := $(PATH_SDK_QT5)
VBOX_PATH_QT          := $(PATH_SDK_QT5)
VBOX_BLD_PYTHON       := C:/Python27\python.exe

I have no idea where it suddenly takes the long path name with the spaces ...

[CaptainFlint]

Do you use LocalConfig.kmk? What does it look like if you do?

Frankly, I have no ideas why this might happen. When I build VB myself, the SDK paths are pretty straight-forward and don't require any fiddling (not even explicit specifying in the configure parameters). Maybe your default environment variables have some excessive values that kBuild does not expect to meet. BTW, why do you use external kBuild instead of the one present in the VB source tree? And why so many PATH modifications before starting kmk? For example, when I build VB I just open the clean cmd session and only enter the following commands:

Code: Select all

"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /Release /x86 /win7
COLOR 07
set BUILD_TARGET_ARCH=x86
cscript configure.vbs --with-DDK=C:\WinDDK\7600.16385.1 --with-MinGW-w64=C:\Programs\mingw64 --with-MinGW32=C:\Programs\mingw32 --with-libSDL=C:\Programs\SDL\x32 --with-openssl=C:\Programs\OpenSSL\x32 --with-libcurl=C:\Programs\curl\x32 --with-Qt5=C:\Programs\Qt\5.6.2-x32 --with-python=C:\Programs\Python
env.bat
kmk

Though I do have many paths specified in LocalConfig.kmk, but not the ones for PATH and none of them contains any VB or kBuild tools.

[IndyJones]

This is how my LocalConfig.kmk looks like:

Code: Select all

VBOX_WITH_WARNINGS_AS_ERRORS =
VBOX_WITH_TESTSUITE =
VBOX_WITH_TESTCASES =
VBOX_WITH_HARDENING =
VBOX_WITH_VMSVGA =
VBOX_WITH_VMSVGA3D = 

I have checked out kBuild into a directory on C:\kBuild from http://svn.netlabs.org/kbuild (as referenced by https://www.virtualbox.org/wiki/kBuild) and the source to D:\VirtualBox. That's why I have the kbuild path modification and the others are in order to make code signing and installer creation work.
It all used to work for me as well without any path fiddling but since I updated to the latest VBox version I'm getting this problem (I was on 5.1.0 release before).

[IndyJones]

Just did a clean checkout of the VirtualBox source from http://www.virtualbox.org/svn/vbox/trunk and tried building with the included kBuild copy - but still receiving the exact same error
@CaptainFlint are you building on Windows 10 Version 1607 (14393.576) x64 as well?

[CaptainFlint]

No, my build system is Windows 7 x64. I've configured a separate virtual machine with this OS inside for keeping the clean and working build environment.

Some time ago I've written an article about building VB, complete with deploying a new build environment from scratch, but it's in Russian. I think Google Translate should provide good enough translation, especially since most of it is what programs to install, which commands to run and what files to edit. So if you are interested you can get it here:
https://geektimes.ru/post/269524/ (Google Translate ru->en)
It might be superflous for your needs though, because my goal was to create a complete installer similar to that provided by Oracle; mere compilation would require much less tools to be installed and files to be edited. Also keep in mind that existing programs in your system might affect the environment, so that my instruction might not work because of them. It's better to start with clean OS for such complex systems.

[IndyJones]

Thanks for your help and feedback. I start to think that this problem is related to Win10 which runs on my dev machine

[CaptainFlint]

No problem, you are welcome. I hope you'll find out what that problem is and how to deal with it.

[IndyJones]

I found out what the problem is and opened an issue here https://www.virtualbox.org/ticket/16357

[CaptainFlint]

Thank you for sharing that info. Good to know you found the source of the problem!

[bird]

Should be fixed in kBuild revision 3025 and later.
Cheers, bird.