I am trying to build the components of Live555 with Visual Studio 2013 64bit on Windows 7.
I have tried editing win32config and the *.mak files without success. I've been searching the internet for a few hours and trying all kinds of things with command prompts.
For some reason VS2013 x64 command prompt is still building 32bit static libs and I can't figure out why.
If anyone has any good ideas, that would be fantastic!
The win32config file that you get from the .tar.gz file requires substantial editing to make it compatible with recent SDK and MSVC++ releases. This is a version that produced a clean build:
NODEBUG=1
TARGETOS = WINNT
UI_OPTS = $(guilflags) $(guilibsdll)
CONSOLE_UI_OPTS = $(conlflags) $(conlibsdll)
CPU=amd64
COMPILE_OPTS = $(INCLUDES) $(cdebug) $(cflags) $(cvarsdll) -I. /EHsc /O2 /MD /GS /D "WIN64" /Oy- /Oi /D "NDEBUG"
C = c
C_COMPILER = cl
C_FLAGS = $(COMPILE_OPTS)
CPP = cpp
CPLUSPLUS_COMPILER = $(C_COMPILER)
CPLUSPLUS_FLAGS = $(COMPILE_OPTS)
OBJ = obj
LINK = link -out:
LIBRARY_LINK = lib -out:
LINK_OPTS_0 = $(linkdebug) ws2_32.lib /NXCOMPAT
LIBRARY_LINK_OPTS =
LINK_OPTS = $(LINK_OPTS_0) $(UI_OPTS)
CONSOLE_LINK_OPTS = $(LINK_OPTS_0) $(CONSOLE_UI_OPTS)
SERVICE_LINK_OPTS = kernel32.lib advapi32.lib shell32.lib ws2_32.lib -subsystem:console,$(APPVER)
LIB_SUFFIX = lib
LIBS_FOR_CONSOLE_APPLICATION =
LIBS_FOR_GUI_APPLICATION =
MULTIMEDIA_LIBS = winmm.lib
EXE = .exe
PLATFORM = Windows
rc32 = rc.exe
.rc.res:
$(rc32) $<
After you've edited this file, run the genWindowsMakefiles command from bash (or the CMD file). Next, start the x64 Visual Studio Command Prompt. Make sure you got the x64 native configuration flavor of it. Issue the following commands:
cd c:\projects\live\liveMedia
nmake -f liveMedia.mak
cd ..\groupsock
nmake -f groupsock.mak
cd ..\UsageEnvironment
nmake -f UsageEnvironment.mak
cd ..\BasicUsageEnvironment
nmake -f BasicUsageEnvironment.mak
cd ..\testProgs
nmake -f testProgs.mak
cd ..\mediaServer
nmake -f mediaServer.mak
Alter the first command to match the directory where you put the source.
TODO items: cleaning doesn't work, it tries to use the *nix rf command. Simplest workaround is del *.obj to force the compiler to rebuild the object files
the .exe files are built without a manifest. Shouldn't matter for the test programs, I assume you're only interested in the .lib files
it builds the release version of the libraries and executables, you'll have to tweak the COMPILE_OPTS to get a debug build.
In order to compile 64 bit native code with Visual Studio 2013, you
require professional edition.
Open the VS2013 x64 Native Tools Command Prompt
Then make sure you set C_COMPILER to "$(TOOLS32)\bin\amd64\cl" after correcting TOOLS32 to the VC/bin dir.
In order to compile 64 bit native code with Visual Studio 2013, you require professional edition.
Open the VS2013 x64 Native Tools Command Prompt
Then make sure you set C_COMPILER to "$(TOOLS32)\bin\amd64\cl" after correcting TOOLS32 to the VC/bin dir.
Related
So I need to support .usd/.usda/.usdc for my renderer application, and I need to distribute the resulting project .exe and usd .libs/.dlls to our users on install. How do I build the library in a way that I can distribute? If I can't distribute it due to how the library is structured, how do I have the user install the needed dependencies automatically?
I was able to get oneTBB I believe (as TBB is a dependency of the library, but I don't know if USD can use it, here is how I compiled it)
::Issue this creates a .dll, would have been nice to have a static lib for not needed function culling
download: https://github.com/oneapi-src/oneTBB
extract: oneTBB-master folder
copy: include folder to destination (/I.\include in cl command when compiling)
open: cmd inside oneTBB-master folder (TIP: if you type cmd and hit enter in the folder path in the top it opens cmd there)
run: mkdir build && cd build
::if you want HWLOC then you need to rebuild with TBB bindings (for OpenMPI, I believe, but we don't currently use)
run: cmake .. -G "Visual Studio 15 2017 Win64" -DTBB_TEST=OFF -DCMAKE_CXX_STANDARD=17 -DCMAKE_BUILD_TYPE=Release
run: cmake --build . --config Release
run: cd msvc_19.16_cxx17_64_md_release
copy: tbb12.dll to destination
copy: tbb12.lib to destination (link against this)
:: don't think we need tbbmalloc.dll/tbbmalloc_proxy.dll and tbbmalloc.lib/tbbmalloc_proxy.lib
I tested TBB by compiling on the command line with a simple test program and build script like
#echo off
if not defined DevEnvDir (
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars64.bat"
)
set FILES=MinimalTBB.cpp
set LIBS=kernel32.lib user32.lib gdi32.lib
set DLLLIBS=tbb12.lib
:: tbbmalloc.lib tbbmalloc_proxy.lib
cl /nologo /W3 /Z7 /GS- /DEBUG:none /Gs999999 /MT /EHsc /O2 %FILES% -FeMinimalTBB.exe %LIBS% /I.\include /link %DLLLIBS% /incremental:no /opt:icf /opt:ref /subsystem:console
But then I need to do Boost.
And then I would love to do something like:
download: https://github.com/PixarAnimationStudios/USD
extract: USD-release folder
open: cmd inside USD-release folder
run: mkdir build && cd build
run: cmake .. -G "Visual Studio 15 2017 Win64" -DBUILD_SHARED_LIBS=ON -DPXR_BUILD_MONOLITHIC=OFF -DPXR_BUILD_IMAGING=OFF -DPXR_BUILD_USDVIEW=OFF -DPXR_ENABLE_PYTHON_SUPPORT=OFF -DPXR_BUILD_DOCUMENTATION=OFF -DPXR_BUILD_TESTS=OFF -DPXR_VALIDATE_GENERATED_CODE=OFF -DPXR_BUILD_PRMAN_PLUGIN=OFF -DPXR_BUILD_ALEMBIC_PLUGIN=OFF -DPXR_BUILD_DRACO_PLUGIN=OFF -DPXR_ENABLE_MATERIALX_SUPPORT=OFF -DCMAKE_BUILD_TYPE=Release
run: cmake --build . --config Release
to get .dll which i will distribute along with the .exe and then just link against the .lib in my project without the user installing anything
As an aside: I saw nVidia has a precompiled version too, I tried compiling with it, but it threw a bunch of python36.dll missing errors, when I am not even using python (only c++).
I found a ok solution from compiling from the command line, there is probably a much better way to do this, but to get it going here is what I did
The following wastes lots of memory on ur build machine, lots of files that don't need to be there, so go through and remove them:
download: lastest repo to C:\USD and create a USD-install folder inside of it
run: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\Build\vcvars64.bat"
run: py C:\USD\build_scripts\build_usd.py C:\USD\USD-install --no-docs --no-embree --no-python --no-debug-python --no-draco --no-prman --no-materialx --no-alembic --no-hdf5 --no-opencolorio --no-openimageio --no-usdview --no-openvdb --no-ptex --no-imaging
I am compiling a windows program from the command line, so I created a new cpp project, but since we are compiling inside of Fuzor do not worry about this step
copied over the C:\USD\USD-install\bin, C:\USD\USD-install\include, and C:\USD\USD-install\lib folder to place of build. (copied .\include has to be included in include path)
moved tbb.dll, usd_ar.dll, usd_arch.dll, usd_gf.dll, usd_js.dll, usd_js.dll, usd_kind.dll, usd_pcp.dll, usd_plug.dll, usd_sdf.dll, usd_tf.dll, usd_trace.dll, usd_usd.dll, usd_vt.dll, and usd_work.dll all from lib folder to the level where my .exe will be generated and run from
In usd/pcp/types.h on line 119 change the numeric_limits<size_t>::max() to SIZE_MAX and in base/gf/ilmbase_halfLimits.h comment out the min and max functions on line 66 and 67
I then linked against lib/tbb.lib lib/usd_tf.lib lib/usd_sdf.lib lib/usd_vt.lib lib/usd_usd.lib
Create a resources folder at level of .exe and copy C:\USD\USD-install\plugin\usd\plugInfo.json to resources folder
In lib copy over C:\USD\USD-install\lib\usd up to the .exe level
distribute .exe, .dll's, and resources folder
I have an existing makefile project that I am migrating to scons.
The makefile builds several Windows executables with gcc and g++.
However, I also have Visual Studio installed for C# development.
It appears that scons is trying to use the Visual Studio tools rather than the gcc ones:
cl /Fofoo\bar.o /c foo\bar.c /nologo -g -mno-ms-bitfields -fshort-enums -ftest-coverage -fprofile-arcs /D-DUNIT_TESTS /I. <more includes follow...>
cl : Command line warning D9002 : ignoring unknown option '-g'
I have read several answers and have tried adding:
env["CC"] = "gcc"
env["CXX"] = "g++"
env["LINK"] = "g++"
in my Sconstruct file. This has the effect of correctly changing the tool, but not the command syntax:
gcc /Fofoo\bar.o /c foo\bar.c /nologo -g -mno-ms-bitfields -fshort-enums -ftest-coverage -fprofile-arcs /D-DUNIT_TESTS /I. <more includes follow...>
gcc: error: /Fofoo\bar.o: No such file or directory
How can I ensure that scons uses my desired tools and also uses the correct syntax for the command line options (e.g. -I instead of /I)?
If I have to guess the issue your SConstruct is something like this:
env=Environment()
env["CC"] = "gcc"
env["CXX"] = "g++"
env["LINK"] = "g++"
env['CCFLAGS']='-mno-ms-bitfields -fshort-enums -ftest-coverage -fprofile-arcs'
env['CPPDEFINES']=['-DUNIT_TESTS']
env['CPPPATH'] = ['.']
Given that the default list of tools to configure on Windows is the following in order and it will stop configuring tools once it finds one of these and then it sets up the flags which should work for such tools.
c_compilers = ['msvc', 'mingw', 'gcc', 'intelc', 'icl', 'icc', 'cc', 'bcc32']
You'll need to explicitly list the tools you want initialized (And not allow SCons to add the default tools) and the PATH they will be found in. Also your CPPDEFINES should be ['UNIT_TESTS'] and not ['-DUNIT_TESTS'] SCons will add the appropriate flags. Note you may need to add other tools if you are using them in your build.
env=Environment(tools=[])
env.AppendENVPath('PATH', PATH_TO_YOUR_COMPILERS)
for tool in ['gcc','gnulink','ar']:
env.Tool(tool)
env['CCFLAGS']='-mno-ms-bitfields -fshort-enums -ftest-coverage -fprofile-arcs'
env['CPPDEFINES']=['UNIT_TESTS']
env['CPPPATH'] = ['.']
I build C++ code inside Windows container using Microsoft Visual C++ Build Tools 2015
msbuild /p:Configuration=Debug essentially runs cl.exe with /MDd option and produces unusable executable - see below.
/p:Configuration=Release uses /MD and makes perfectly fine executable.
Sample code hello-world.cxx:
#include <iostream>
int main()
{
std::cout << "Hello World!";
}
Compiling with /MDd:
> cl.exe /EHsc /MDd hello-world.cxx
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
hello-world.cxx
Microsoft (R) Incremental Linker Version 14.00.24210.0
Copyright (C) Microsoft Corporation. All rights reserved.
/out:hello-world.exe
hello-world.obj
> echo %ERRORLEVEL%
0
> hello-world.exe
...nothing is printed here...
> echo %ERRORLEVEL%
-1073741515
Compiling with /MD:
> cl.exe /EHsc /MD hello-world.cxx
...
> hello-world.exe
Hello World!
> echo %ERRORLEVEL%
0
Here is the relevant part of my Dockerfile:
FROM microsoft/windowsservercore
...
# Install chocolatey ...
...
# Install Visual C++ Build Tools, as per: https://chocolatey.org/packages/vcbuildtools
RUN choco install -y vcbuildtools -ia "/InstallSelectableItems VisualCppBuildTools_ATLMFC_SDK"
# Add msbuild to PATH
RUN setx /M PATH "%PATH%;C:\Program Files (x86)\MSBuild\14.0\bin"
# Test msbuild can be accessed without path
RUN msbuild -version
As you can see I install Visual C++ Build Tools 2015 via choco package.
I've read documentation: https://learn.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library
So /MDd defines _DEBUG and also places MSVCRTD.lib into the .obj file, not MSVCRT.lib
On my laptop I have full Visual Studio installed and it builds fine.
I've compared MSVCRTD.lib that I have installed under C:\Program Files (x86)\Microsoft Visual Studio 14.0 and on both systems files are the same.
Confused...
SOLVED
Container has no GUI, and compiled .exe tries to show GUI dialog with the message:
"The program can't start because ucrtbased.dll is missing from your
computer. Try reinstalling the program to fix this problem."
(found this when running built .exe in a similar environment but with GUI)
Interestingly C++ Build Tools 2015 installed these dll-s under:
C:\Program Files (x86)\Windows Kits\10\bin\x64\ucrt\
C:\Program Files (x86)\Windows Kits\10\bin\x86\ucrt\
However when .exe runs it can't find them.
On full VS installation I found these files also copied under
C:\Windows\System32\
C:\Windows\SysWOW64\
Reinstallation of C++ Build Tools helped, however it's slow and feels weird.
So I've ended up just copy-ing those files manually instead.
Added to Dockerfile:
RUN copy "C:\Program Files (x86)\Windows Kits\10\bin\x64\ucrt\ucrtbased.dll" C:\Windows\System32\
RUN copy "C:\Program Files (x86)\Windows Kits\10\bin\x86\ucrt\ucrtbased.dll" C:\Windows\SysWOW64\
we're using qmake and *.pro files to generate Visual Studio project files, currently 2 files one for x86 and one for x64. To achieve this we're using a script which first sets the environment variables (e.g. %QTDIR%) for x86, calls qmake after that to generate x86 *.vcxproj and repeat that for x64 (set and call).
setEnvVariables("x86")
cmd /c "$env:QTDIR\bin\qmake" -Wall -tp vc -o "myProj.vcxproj" myProj.pro
setEnvVariables("x64")
cmd /c "$env:QTDIR\bin\qmake" -Wall -tp vc -o "myProj_$platformextension.vcxproj" myProj.pro
We've different lib/include paths for Qt x86 and x64 (Qt4.8.7 and Qt4.8.7_x64).
My question now: Is there a way to force qmake to generate a single project file for both platforms so we can use MSBUILD on a single project file? E.g. msbuild myProj.vcxproj /p:Configuration=Release /p:Platform=x64 and next step msbuild myProj.vcxproj /p:Configuration=Debug /p:Platform=x86.
Could I archieve this with special *.pro and *.pri setup?
I would like to build boost using two different compilers, MinGW and Visual C++ 2010 Express, using bjam:
bjam toolset=gcc,msvc variant=release link=static,shared threading=multi install
The problem is that I do not have bjam. I could not find it in the Boost directory, and the one I downloaded from somewhere else was a wrong version.
I should be able to build it from the code in Boost, but how? I read that I must launch build.bat from the BOOST_ROOT/tools/jam/src directory, but that directory does not exist !
Thank you!
Platform: Windows7
Compilers: MinGW and Visual C++ 2010 Express
Update:
I have been able to get bjam with: bootstrap.bat gcc
Then, launching bjam with the previous parameters, I only get libraries for MinGW (.dll and .a).
This is an extract of the error messages I get with regard to Visual C++ 10:
...
call "c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul
cl /Zm800 -nologo #"bin.v2\libs\test\build\msvc-10.0\release\asynch-exceptions-on\threading-multi\plain_report_formatter.obj.rsp"
...failed compile-c-c++ bin.v2\libs\test\build\msvc-10.0\release\asynch-exceptions-on\threading-multi\plain_report_formatter.obj...
...
...skipped <pbin.v2\libs\test\build\msvc-10.0\release\asynch-exceptions-on\threading-multi>boost_unit_test_framework-vc100-mt-1_48.dll for lack of <pbin.v2\libs\test\build\msvc-10.0\release\asynch-exceptions-on\threading-multi>compiler_log_formatter.obj...
...
common.mkdir bin.v2\libs\thread\build\msvc-10.0\release\threading-multi
common.mkdir bin.v2\libs\thread\build\msvc-10.0\release\threading-multi\win32
compile-c-c++ bin.v2\libs\thread\build\msvc-10.0\release\threading-multi\win32\thread.obj
\Microsoft was unexpected at this time.
...
call "c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul
cl /Zm800 -nologo #"bin.v2\libs\thread\build\msvc-10.0\release\threading-multi\win32\thread.obj.rsp"
...failed compile-c-c++ bin.v2\libs\thread\build\msvc-10.0\release\threading-multi\win32\thread.obj...
compile-c-c++ bin.v2\libs\thread\build\msvc-10.0\release\threading-multi\win32\tss_dll.obj
\Microsoft was unexpected at this time.
...
...skipped <pC:\Boost\lib>boost_thread-vc100-mt-1_48.lib for lack of <pbin.v2\libs\thread\build\msvc-10.0\release\threading-multi>boost_thread-vc100-mt-1_48.lib
...
Trying to use:
bootstrap.bat vc100
I get the error: "Unknown toolset: vc100"
With either:
bootstrap.bat vc10
or:
bootstrap.bat mingw
I get: "\Microsoft was unexpected at this time."
Changing project-config.jam did not help.
So, I did a big step forward, but vc10 is not working, yet...
There is a bootstrap.bat in your boost directory. Run it.
It will build bjam automatically (probably using visual c++).
The directory structure in boost has changed in recent version, I think.
The sources for bjam are in tools/build/v2/engine. Run build.sh mingw from that directory using MinGW shell, and it should build bjam.exe and b2.exe and place them in tools/build/v2/engine/ntx86. Copy b2.exe to the boost root directory. You should then be able to build Visual c++ libraries with b2 toolset=msvc.
Hope that helps.
In my case, the solution from jork works!
I searched the bjam.exe file and found it located in the tools/build/src/engine directory and just copied it to the boost root directory. But I have to say this is awful, I felt like the codebase writer is trying to hide sth. And I found that my bjam.exe is exactly is the same size with b2.exe, which is 404KB.
I will turn back later to ensure that I solved this issue.