I'm trying to build the Boost 1_52 library with VS2012. Everything is building fine except for the Date Time dll (boost_date_time-vc110-mt-1_52.dll).
I'm using B2.exe as shown below
b2.exe toolset=msvc-11.0 --build-type=complete stage debug-symbols=on debug-store=database --abbreviate-paths
I've tried using cxxflags="/Y- " because I get other out of date PDB errors, this didn't change anything. I've tried setting Zm100, again no change.
When it gets to the gregorian section, I get a number of failures like shown below
common.mkdir bin.v2\libs\date_time\build\msvc-11.0\debug\debug-store-database\threading-multi
common.mkdir bin.v2\libs\date_time\build\msvc-11.0\debug\debug-store-database\threading-multi\gregorian
compile-c-c++ bin.v2\libs\date_time\build\msvc-11.0\debug\debug-store-database\threading-multi\gregorian\greg_month.obj
greg_month.cpp
libs\date_time\src\gregorian\greg_month.cpp : fatal error C1033: cannot open program database 'd:\boost\source\boost_1_52_0\gregorian\greg_month.pdb'
call "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcvarsall.bat" x86 >nul
cl /Zm800 -nologo #"bin.v2\libs\date_time\build\msvc-11.0\debug\debug-store-database\threading-multi\gregorian\greg_month.obj.rsp"
The problem is that the build is trying to place the .pdb files for some object files of the date_time library in a non-existent directory.
You can work around the problem by doing:
md gregorian
before performing the build so the directory exists.
I'm not sure yet what the real fix is since the boost build system is more or less a black box to me.
Related
I'm trying to install boost to run PyGMO properly. However, after I unpack it in a directory (did not use git).
After running bootstrap vc142 (I'm using VScode V1.63.2 and I'm on windows). I'm getting this error:
Building Boost.Build engine
LOCALAPPDATA=C:\Users\wojci\AppData\Local
could not find "vswhere"
Call_If_Exists "..\bin\VCVARS32.BAT"
###
### Using 'msvc' toolset.
###
Followed by:
C:\Program Files\boost\boost_1_78_0\tools\build\src\engine>dir *.exe
Volume in drive C has no label.
C:\Program Files\boost\boost_1_78_0\tools\build\src\engine>copy /b .\b2.exe .\bjam.exe
The system cannot find the file specified.
Failed to build Boost.Build engine.
Does anyone know how to fix/work around this?
Thank you in advance
I found the solution here (git)
Prerequisites:
First download and install MinGW installer mingw-w64-install.exe (I fot it from Sourceforge) and make sure you use x86_64 architecture.
Then download the boost file (boost_1_78_0.zip source)
Open and run cmd as admin
Enter the following command to link the MinFW folder in C:\
mklink /J C:\MinGW "C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64"
add MinGW to the system PATH:
set PATH=%PATH%;C:\MinGW\bin
setx /M PATH "%PATH%"
Check if you have at least g++ version of 8.1.0
g++ --version
Methodology to install boost:
Navigate to the install folder created and unzip and extract the boost_1_78_0.zip file into this folder
In the CMD navigated to the boost folder
cd C:\install\boost_1_78_0
Type the following to make directories for building and installing boost
mkdir C:\boost-build
mkdir C:\install\boost_1_78_0\boost-build
mkdir C:\boost
Setup boost.build (second line prepers b2, the third line builds boost.build with b2, and the fourth line adds C:\boost-build\bin to your session PATH variable)
cd C:\install\boost_1_78_0\tools\build
bootstrap.bat gcc
b2 --prefix="C:\boost-build" install
set PATH=%PATH%;C:\boost-build\bin
building boost (first line navigateds to boost directory, second line builds boost with b2 this can take a while)
cd C:\install\boost_1_78_0
b2 --build-dir="C:\install\boost_1_78_0\build" --build-type=complete --prefix="C:\boost" toolset=gcc install
Extra notes:
This should work for boost 1.68.0 too and might work for other version just replace 1_78_0 with 1_68_0.
At the end you should have three lines that look something like this:
...failed updating 72 targets...
...skipped 292 targets...
...updated 22164 targets...
It's totally fine if you have some failed and skipped files.
Type "native tools " in the start search.
Run "Native tools for visual studio" as an administrator. A command prompt opens.
change directory to boost .
run command "bootstrap".
Follow up by ".\b2".
Wait for a while.
Worked for me. Hope it helps.
I'm trying to write Parquet files on Windows using C++.
I followed the instructions I found here and chose the "Using conda-forge for build dependencies" and "Building using Visual Studio (MSVC) Solution Files" approaches.
In contrast to the article on the page mentioned before, my calls to cmake look like this:
cmake .. -G "Visual Studio 16 2019" -A x64 ^
-DARROW_BUILD_TESTS=OFF ^
-DARROW_PARQUET=ON ^
-DARROW_BUILD_SHARED=OFF ^
-DARROW_BUILD_STATIC=ON ^
-DARROW_DEPENDENCY_SOURCE=AUTO
cmake --build . --config Release
I want to use Parquet/Arrow as a static library, so I set -DARROW_BUILD_SHARED=OFF and -DARROW_BUILD_STATIC=ON.
In the "build" folder created after running cmake, I built the Parquet and Arrow INSTALL projects (build\src\parquet\INSTALL.vxcproj, build\src\arrow\INSTALL.vxcproj) with Visual Studio 2019. As a result, a folder structure was created under C:\Program Files\arrow\lib including arrow_static.lib and parquet_static.lib.
Under C:\Program Files\arrow\include\arrow respectively \parquet all related header files can be found.
I then set up a new C++ project (Release Build | x64) in Visual Studio referencing the previously build static libs and including directories.
In the project settings under "C/C++->Preprocessor->Preprocessor Definitions" I added PARQUET_STATIC and ARROW_STATIC.
For a first test, I use the "reader_writer" example from the apache arrow GitHub repo:
Now, if I build the reader_writer example, I receive multiple linking errors (LNK2001) like the following example:
Error LNK2001 unresolved external symbol "public: virtual char const * __cdecl apache::thrift::transport::TTransportException::what(void)const " (?what#TTransportException#transport#thrift#apache##UEBAPEBDXZ) ReaderWriterDemo D:\..\ReaderWriterDemo\parquet_static.lib(column_writer.obj)
All errors have in common that they refer to as "thrift" at some point.
I was under the impression that when using "conda-forge for build dependencies" (see first link above), that all required dependencies would be available/somehow integrated into the solutions built by CMake?!
When running "cmake .. -G "Visual Studio 16 2019" -A x64" I can see the following in the log output though:
-- Checking for module 'thrift'
-- Found thrift, version 0.15.0
-- Found Thrift: D:/Programs/Miniconda3/envs/arrow-dev/Library/lib/thriftmd.lib (found suitable version "0.15.0", minimum required is "0.11.0")
My attempts to build the thrift library separately by using the resources found here weren't successful; information regarding Windows seems to be incomplete/outdated.
I assume that it should be possible to set up the Arrow/Parquet libs only by using resources from https://github.com/apache/arrow/.
Perhaps some of you have already gone through the same process and can give me a hint as to where else I may have missed something.
I am attempting to compile a static wrapper dll that includes the static OpenSSL Fips libraries.
I have linked:
C:\Work\win_x64\fipscanister.lib
C:\Work\libeayfips32.lib
C:\Work\ssleay32.lib
ws2_32.lib
crypt32.lib
I also included the directory of the libs in the includes directory.
I have added the fips_premain.c file that was generated during the openssl-fip2.0 build. I adjusted the SHA1_HASH_SIG to equal the value in fips_premain.c.sha1
I am using Visual Studio 2017 to build my wrapper dll. I include the wrapper dll in my project. When I call, FIPS_mode_set(1), I get the following errors:
17480:error:2D0A3073:FIPS routines:func(163):fips selftest failed:
.\crypto\ecdh\ech_ossl.c:125: Exception thrown:
'System.Exception' in Test.OpenSSL.dll [Test][11872][26]
ERROR [Native][-] 2018-10-03T01:13:54.971Z ERROR
Setting fips mode: fingerprint does not match
[Native][11872][27] ERROR [Native][-] 2018-10-03T01:13:54.972Z
ERROR Setting fips mode: fingerprint does not match Exception thrown: 'System.Exception'
in Test.OpenSSL.dll Exception thrown:
'System.NullReferenceException' in Test.OpenSSL.dll
When I ran nmake f ms\nt.mak test all the tests completed successfully
I must be missing a step somewhere, I am curious how others have gotten this to work.
I built the library like:
perl Configure VC-WIN64A --prefix=C:\Build-OpenSSL-VC-64
ms\do_win64a
nmake -f ms\nt.mak
nmake -f ms\nt.mak install
Im using openssl-1.0.2p and openssl-fips-2.0.16 Both built properly which makes me think its how I am building my wrapper. Or maybe its unable to process the hash because its been wrapped?
So I had to add the fips_premain.c to my visual studio project. Run fips_premain_dso.exe passing in my new static lib (make sure the fips_premain.c isnt changed or it wont generate the hash) and then put the hash value into the fips_premain.c and then rebuild in visual studio and it works :D
I just have followed the tutorials from: https://www.youtube.com/watch?v=57dbxWj7b4U
to install c++, but I can't build the project even I take the example project in eclipse: "Hello World c++ Project".The building seems successful, for exe file is generated, and concole shows
13:38:04 **** Incremental Build of configuration Release for project FirstC ****
Info: Internal Builder is used for build
g++ -O3 -Wall -c -fmessage-length=0 -o FirstProgram.o "..\\FirstProgram.cpp"
g++ -o FirstC.exe FirstProgram.o
13:38:05 Build Finished (took 1s.90ms)
But when I press "run", it says "Info: Nothing to build for TestProject", as the enclosed picture.
The system path is as following:
"c:\program files\gcc\bin;c:\program files\gcc\libexec\gcc\x86_64-pc-mingw32\5.3.0;%MINGW_HOME%\bin;%MSYS_HOME%bin;C:\Program Files (x86)\Java\jre1.8.0_25\bin;C:\ProgramData\Oracle\Java\javapath;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files\Common Files\Autodesk Shared\;C:\Program Files (x86)\Autodesk\Backburner\;C:\Program Files\GDAL\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\nodejs\".
What will the reason probably be? I have install java several days before, and just install c++ today. Will they conflict?
"Nothing to build for TestProject" means that the project was already built before and nothing changed since then, so the project does not need to rebuild.
If you change anything in the source code, save and try again, the project should then rebuild again (once).
I have restarted the computer and now it runs well, and "hello world" comes out. I'm fooled by the system and feel so tired.....
anyone have jsoncpp working on vc90?
they use a build system, Scons, which I have never heard of. I installed the latest Scons, found an undocumented scons.bat, launched a vc90 prompt in my jsoncpp dir, modified the SConstruct file to support a msvc90 target (i copied the boilerplate from the msvc80 platform which was already supported) ran scons.bat platform=msvc90 and got errors:
scons: done reading SConscript files.
scons: Building targets ...
cl /Fobuildscons\msvc90\src\jsontestrunner\main.obj /c src\jsontestrunner\main.c
pp -GR -EHsc /nologo /MT /nologo /Iinclude /I.
main.cpp
c:\projects\docwayhead\wspt_docway_plugins\contrib\jsoncpp-src-0.5.0\include\jso
n\value.h(5) : fatal error C1083: Cannot open include file: 'string': No such fi
le or directory
scons: *** [buildscons\msvc90\src\jsontestrunner\main.obj] Error 2
scons: building terminated because of errors.
i've already put too much effort into getting this to build, and jsoncpp is clearly unmaintained, so i give up for now.
No need to use Scons.
Under the /makefiles/vc71/ you can find a visual studio solution which you can up convert and build.
Modify the msvc90 platform file to make sure VC90 include directories are used when calling cl (clearly not yet the case in the provided command line you provided).
Note that Scons is written using Python and so are its configuration files, so people who know Python around you might be able to help you efficiently, even if they know nothing about scons.
Are you sure your VS command line is working properly? I got it to work just by:
- Adding a msvc90 entry in allowed_values
- copy/pasting the msvc80 section later and modifying it to use env['MSVS_VERSION'] = 9.0
I'm using scons 1.3.0.
The scons setup for jsoncpp 0.5.0 does not support VS 9.0 or 10.0 out of the box. You need to first add msvc90 to the allowed_values in the SConstruct line 21, and the to add this section on line 103.
elif platform == 'msvc90':
env['MSVS_VERSION']='9.0'
for tool in ['msvc', 'msvs', 'mslink', 'masm', 'mslib']:
env.Tool( tool )
env['CXXFLAGS']='-GR -EHsc /nologo /MT'
Just replace 9.0 with 10.0 and 90 with 100 for VS 10.0 support.
As of version 0.6.0 of jsoncpp, you can avoid a lot of hassle by using the new Amalgamated version. This is just two .h files and one .cpp file that you compile directly into your projects. It's working great for me so far in VS 9 (and with a few mods I'm now able to compile it with C++Builder 2010 as well -- haven't really tested the result yet).
By the way, I've filed a bug against version 0.6.0-rc2; one line in the Amalgamated version of json.h needs to have a macro name changed.