I would like to create a HDF5 dataset from a fortran90 program compiled with intel fortran 2011 on Windows 7 using Visual Studio 2010
Can I use prebuilt binaries or how do I build new ones
I build from source, the available built binaries use the MS C/C++ compiler while I want to build with the Intel compiler, and they are built with Intel Fortran v12.x while I'm using v14.x. I won't say that you can't use the binaries, but I've had enough of a struggle in the past to persuade me to build my own.
I've also had struggles with trying to build them directly from VS and now use CMake. Your first step ought to be to install CMake and figure out how to use it. You don't need much knowledge of the tool and the effort will be repaid several times over. You can, for example, also use CMake to build Szip and Zlib, if you want them. An increasing amount of this sort of software is made available with CMake support so you won't necessarily only use it for HDF5. For example, I use CMake to build VTK for Windows too.
Once you've done that and generated the solution/project files with CMake you can load up the solution in VS and build ALL_BUILD. This generally works smoothly, though I have found that some projects need to have their linkages adjusted and sometimes I get spurious flags in the command-lines sent to the compilers. Then, running VS in administrator mode, you can build the pseudo-target INSTALL.
I see that HDF5 1.8.12 is now available, I'll download and build it, let you know how I get on.
Compiling and Linking
If you just want to use HDF5 include the line
USE, NON_INTRINSIC :: hdf5
at the appropriate place in your source file(s). Then, under Project Properties | Fortran | General | Additional Include Directories insert the path to the location of hdf5.mod. That should get you compiling.
To link, under Project | Properties | Linker | General | Additional Library Directories insert the path the location of the .lib files. Then, under Project | Properties | Linker | Input | Additional Dependencies insert hdf5_fortran.lib.
You should then be able to compile and link your program. If you want to use additional facilities, such as the HDF5 Table Interface, then use h5tb and figure out the linkages.
And consult the documentation. See, for example, ../HDF5-1.8.12/release_docs/USING_HDF5_VS.txt
I succeeded thanks to High Performance Mark:
Here was what I did (not sure that everything is necessary):
Download and install cmake
Download and install HDF5 [Windows (32-bit), Compilers: CMake VS 2010 C, C++, IVF 12, RWDI]
Set environment variable: HDF5_DIR=C:/Program Files/HDF_Group/HDF5/1.8.x/cmake/hdf5
Download HDF5 source
Make empty build folder
Run CMake(cmake-gui) from start menu
Set source (HDF5 source) and destination (empty build folder)
Configure
Set generator to Visual Studio 10
Specify native compilers [C:"", C++:"", Fortran: "<..>\ifort.exe"]
Check: BUILD_SHARED_LIBS and HDF5_BUILD_FORTRAN
Configure
Configure
Generate
Open <..>\build\HDF5.sln in Visual Studio 2010
build project ALL_BUILD
And finally
Create new project with a Fortran example
Linked the generated libs exactly as High Performance Mark describes
I hope some else can use the reciepe.
Thanks again
Related
The library mylib consists of the library proper, in directory lib/, and a test suite, in directory test/. It is completely under CMake control:
mylib/CMakeLists.txt:
...
add_subdirectory(lib)
add_subdirectory(test)
...
mylib/lib/CMakeLists.txt:
...
add_library(my_lib ${src_files})
...
mylib/test/CMakeLists.txt:
...
add_executable(mytest mytest.c)
target_link_libraries(mytest mylib)
Build steps are:
mkdir build
cd build
cmake ..
make
ctest # or make test
make install
Works under Linux, stable since many years. Under Windows10 though, a message window pops up, entitled "mytest.exe - System error": "The code execution cannot proceed because mylib.dll was not found. Reinstalling the program may fix this problem."
No, installing (rather than reinstalling) would not be a good solution: I need to first test the library before I install it (btw: this excludes most solutions proposed in response to somewhat similar questions).
Isn't CMake supposed to work cross-platform? What is the minimally invasive adjustment to make the above build steps work under Windows?
The right way of doing this on Windows is to populate the PATH environment variable for the test run:
set_tests_properties(your_test_name
PROPERTIES
ENVIRONMENT PATH="path-containing-your-dll")
I believe you can use generator expression if path-containing-your-dll is a function of an artifact that you generate in your build.
Cherry on top: since cmake 3.13, the variable VS_DEBUGGER_ENVIRONMENT can also be set on the target for having a nice debugging behaviour inside Visual Studio (eg. being able to debug the application directly from Visual instead of going through ctest).
I've been trying this for over 5 days and I have no idea how to get this to work. I had successfully installed boost once, then I got my computer re-imaged and now it's just not happening. I have Windows 7 Enterprise, and 64-bit operating system.
I downloaded boost from here sourceforge
unzipped it into program files.
I then went to the VS 2013 Native Command prompt. Changed directory to boost tools/build
Ran bootstrap.bat
I then ran ./b2 address-model=64
but it did not give me directories for the compiler and the linker like last time.
I then ran ./b2 --prefix=C:\ProgramFiles\boost_1_58_0
but again nothing happens. I get the following errors:
Warning: No Toolsets were configured.
Warning: Configuring default toolset ""msvc"
Warning: If the default is wrong, your build may not work correctly
warning: Use the "toolset=xxxxx" option to overrride out guess
warning: for more configuration please consult
I have no idea why this worked the first time I had done this and why this isn't working now. Can someone please help me out. I know nothing about Unix but I need to install this so I can use the libraries.
I compile boost with both mingw (64 bit) and msvc 2013 pro. I have never in my life used the vs command prompt to build boost with msvc. Here are my commands to build 64 bit binaries on both toolchains.
First go into the boost folder and just double click bootstrap.bat. This should run and build bjam/b2. Nothing special required and doesn't matter what compiler this gets built with.
Then simply run, in a normal command prompt:
bjam.exe -a -j8 --toolset=msvc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\MSVC-X64 release stage
Where -a forces rebuild all, -j8 means for the build to use 8 cores (adjust this based on your processor capabilities), toolset is obvious, layout means how to structure the naming of the output files, address-model is obvious, stagedir is where to output the built binaries (either relative or absolute path) and release stage is the type of build the system. See more here.
Same thing but using 64 bit mingw.
bjam.exe -j8 --toolset=gcc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\x64 release stage
You can even go on to build additional libraries with a second pass tweaking your arguments. For example, after I've built the core libs with the above command, I run the following command to build in zlib and gzip support.
bjam.exe -a -j8 --toolset=msvc --layout=system optimization=speed link=shared threading=multi address-model=64 --stagedir=stage\MSVC-X64 --with-iostreams -s BZIP2_SOURCE=C:\dev\libraries\cpp\bzip2-1.0.6 -s ZLIB_SOURCE=C:\dev\libraries\cpp\zlib-1.2.8 release stage
Anyway that's just as an example. I linked to the full docs for the build system. Try building using these commands NOT inside a vs command prompt. If you still have problems then please post specific errors.
A note about MSVC
So, msvc compiler + boost supports a type of linking where it will automatically include additional libraries that it knows it needs. I believe boost does this by using the #pragma directive in headers. For example you might use boost::asio configured in such a way that it needs boost::system (for error codes and such). Even if you don't explicitly add boost::system library to the linker options, msvc will "figure out" that it needs this library and automatically try to link against it.
Now an issue arises here because you're using layout=system. The libraries are named simply "boost_" + the lib name, like "boost_system.dll". However, unless you specify a preprocessor define, this auto linking will try and link to a name like "boost_system_msvc_mt_1_58.lib". That's not exact as I can't recall the exact name, but you get the idea. You specifically told boost to name your libraries with the system layout (boost_thread, boost_system) etc instead of the default, which includes the boost version, "MT" if multithreaded, the compiler version, and lots of other stuff in the name. So that's why the auto linking feature goes looking for such a crazy weird name and fails. To fix this, add "BOOST_AUTO_LINK_NOMANGLE" in the Preprocessor section of your C++ settings in visual studio.
More on that here. Note that the answer here gives you a different preprocessor definition to solve this problem. I believe I ended up using BOOST_AUTO_LINK_NOMANGLE instead (which ended up working for me) because the ALL_DYN_LINK macro turned out to be designed as an "internal" define that boost controls and sets itself. Not sure as it's been some time since I had this issue, but the define I provide seems to solve the same root issue anyway.
How to build app with source of openssl, without compiled openssl.dll and libeay.dll ?
I downloaded openssl-0.9.8h, set include paths to path-to-sources/include/. Files located in include/openssl/ it's links to files ../../{crypto/_algo-name_/algosource.h}, and VS do not understand this links.
Actually, you need to build OpenSSL and that will generate the library and header files in the patch specified in makefile. And you should use that include files. These header files are like template files and used while building OpenSSL. See this question.
And search how to build OpenSSL on Windows.
As the problem mentioned by you after compilation, there should not be any need of OpenSSL, you can do it in the following manner:
Generate static library of OpenSSL and use it in your application. Now, after compilation of your application, OpenSSL dlls will not be required.
If your application is very small, you can compile it with OpenSSL static library.
How to build app with source of openssl, without compiled openssl.dll and libeay.dll
You cannot. You need to build the OpenSSL library first.
I downloaded openssl-0.9.8h, set include paths to path-to-sources/include/....
Your next step is to open INSTALL.W32 and read the instructions. Here's an exceprt with most of the steps. But be sure to execute it using a Visual Studio Command Prompt so the tools like cl.exe and link.exe are on path.
If you want to compile in the assembly language routines with Visual
C++, then you will need already mentioned Netwide Assembler binary,
nasmw.exe or nasm.exe, to be available on your %PATH%.
Firstly you should run Configure with platform VC-WIN32:
> perl Configure VC-WIN32 --prefix=c:\some\openssl\dir
Where the prefix argument specifies where OpenSSL will be installed to.
Next you need to build the Makefiles and optionally the assembly
language files:
- If you are using NASM then run:
> ms\do_nasm
- If you don't want to use the assembly language files at all then run:
> perl Configure VC-WIN32 no-asm --prefix=c:/some/openssl/dir
> ms\do_ms
If you get errors about things not having numbers assigned then check the
troubleshooting section: you probably won't be able to compile it as it
stands.
Then from the VC++ environment at a prompt do:
> nmake -f ms\ntdll.mak
If all is well it should compile and you will have some DLLs and
executables in out32dll. If you want to try the tests then do:
> nmake -f ms\ntdll.mak test
To install OpenSSL to the specified location do:
> nmake -f ms\ntdll.mak install
Thomas Hruska of Shining Light Productions offers Win32 OpenSSL. Its a pre-built OpenSSL with a Windows installer. He's been providing it for years.
Once installed, just point to it in Visual Studio. There's no fussing with environments like Cygwin, Perl and scripts to modify source code so that Unix and Linux work on Windows. (That's a dumb idea to me. Windows is Windows, and Linux is Linux. Stop trying to make one act like the other).
I am trying to compile the Qt library (I don't need the demos or examples) for 64-bit Windows. There are instructions here but I run into the error described in the comment below it. There doesn't seem to be a reference anywhere for how one might go about doing this process.
I am targetting Microsoft Visual C++ 2010 Express. It looks like I need Perl and the Windows SDK as well - how do I go about this process?
This process is quite tedious and time-consuming - but I will explain each step in detail here for the benefit of others who try to compile Qt in the future.
The first step is to install all of the prerequisites.
ActivePerl, which is used during the configuration process. You will need to restart after installing Perl since it modifies environment variables.
The Windows SDK 7.1 (formerly called the Platform SDK). Be sure to include the x64 libraries when you select the components to install.
Download the Qt source archive from the Qt Downloads page.
Extract the contents of the archive to an easy-to-remember location (like C:\). You need to remember this location later since we will be using it to set some environment variables.
Now open the Windows SDK 7.1 Command Prompt. Begin by setting the environment to 32-bit release mode (we need to build some of the tools as 32-bit applications):
setenv /release /x86
Set the following environment variables (example below assumes you extracted to C:\):
set QTDIR=C:\qt-everywhere-opensource-src-4.8.0
set PATH=%PATH%;%QTDIR%\bin
Now run cd %QTDIR% and specify the configuration options - example is included below:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010
Once the configuration process is complete, cd to the src directory and run:
qmake
nmake
This process may take a considerable amount of time, so now would be a good time to take a break and answer some questions here on Stack Overflow :)
The tools are now built and you need to compile Qt as a 64-bit library. Enter the following command:
setenv /x64
You will need to set the environment variables from step 5 again. Enter those commands now.
Run cd %QTDIR% and then rerun the configure command being sure to specify one additional option:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010 -no-qmake
The -no-qmake option is very important - it indicates that we want to skip the compilation of the qmake.exe program because we want to keep the 32-bit version.
Now things get really complicated here because of some dependency problems. The tools (like moc) that Qt needs to build the core library and some of the other components are listed as dependencies in the src.pro file. This means that the compiler will attempt to build them as 64-bit applications and then try to run them - which will of course fail on a 32-bit system. So what we need to do is edit src.pro and remove those dependencies ourselves. Scroll down near line 85 and look for a line that begins with:
!wince*:!ordered:!symbian-abld:!symbian-sbsv2 {
Each subsequent line in the section lists a sub-target and its dependencies. What you want to do now is remove all dependencies that begin with src_tools_. For example:
src_gui.depends = src_corelib src_tools_uic
Becomes:
src_gui.depends = src_corelib
There might be a better way of doing this, but I haven't figured it out yet :)
Now we cd into the src directory once again and run the following command
nmake sub-winmain sub-corelib sub-xml sub-network sub-sql sub-testlib
sub-gui sub-qt3support sub-activeqt sub-opengl sub-xmlpatterns sub-phonon
sub-multimedia sub-svg sub-script sub-declarative sub-webkit
sub-scripttools sub-plugins sub-imports
This builds only the Qt libraries and skips the tool dependencies. Note that this too may take a considerable amount of time.
You should now have 64-bit libraries in the lib folder that you can link against in your 64-bit Qt applications.
Edit: it turns out that even this wasn't enough since I still ran into some problems when linking the QtWebKit4.dll library (something about unresolved symbols). It turns out that someone else has already found the solution and you need to change QMAKE_HOST.arch to QMAKE_TARGET.arch in WebCore.pro.
Also, the above options will build QNetwork4.dll without OpenSSL support (you won't be able to access sites over HTTPS - even in a QWebView). This, thankfully isn't too hard to fix. Download and build OpenSSL for Win64 and append the options below to the command in step #9:
-openssl -I C:\OpenSSL\inc32 -L C:\OpenSSL\out32dll
(You'll have to change the paths if you installed OpenSSL somewhere other than C:\OpenSSL.)
Further edit: to save the trouble of doing this yourself, I have uploaded the compiled libraries here:
http://www.box.com/s/9710cbb278ef4890a7b5
As I mentioned in the comments to George Edison's answer, there is a bug in the Microsoft Visual C++ compiler that comes with the Windows SDK 7.1. For more information on this, see QTBUG-11445 and QTBUG-19175.
I have compiled the Qt 4.8.2 64-bit binaries following George's instructions, including the OpenSSH library. In addition, I applied Microsoft's hotfix to fix the compiler bug.
For your convenience, I have made the resulting 64-bit libraries available for download from here: https://www.box.com/s/8948c60c3cdd743ef83b
I'm using libcurl in a Win32 C++ application.
I have the curllib.vcproj project added to my solution and set my other projects to depend on it.
How do I build it with SSL support enabled?
Well, since this post failed badly, I had to dig into the matter myself.
Also check out the other answers and comments for additional info regarding other versions etc.
EDIT: Since I posted this Q there seems to be ready-built binaries made available from the curl homepage. Check out James' answer.
So here goes:
-
Preprocessor
The following two symbols need to be fed to the preprocessor to enable SSL for libcurl:
USE_SSLEAY
USE_OPENSSL
(libcurl uses OpenSSL for SSL support)
Alternatively the symbols can be added directly to a file called setup.h in libcurl, but I'm not too happy about modifying code in 3rd party distributions unless I really have to.
Rebuilding the libcurl library, I now got some errors about OpenSSL include files not being found. Naturally, since I haven't set up the OpenSSL distribution properly yet.
Compiling OpenSSL binaries
I downloaded the OpenSSL 0.9.8 source distribution and unpacked it.
In the root of the source distribution there's a file called INSTALL.W32 which describes how to compile the OpenSSL binaries. The build chain requires perl, so I installed the latest version of ActivePerl.
I had some trouble with the build, which might not be applicable to all systems, but I'll go through it here in case somebody experiences the same.
According to INSTALL.W32:
Run the following commandline tasks with current directory set to the source distribution root:
1> perl Configure VC-WIN32 --prefix=c:/some/openssl/dir
(Where "c:/some/openssl/dir" should be replaced by the dir where OpenSSL should be installed. Don't use spaces in this path. The compilation further ahead will fail in that case)
2> ms\do_ms
For me this step was unsuccessful at first, since I lacked the environment variables OSVERSION and TARGETCPU. I set these to 5.1.2600 and x86 respectively. You may get complaint about OSVERSION being "insane", but look closer, this error is for WinCE and doesn't affect the Win32 setup. To get hold of your OS version, run the 'ver' command from a command prompt or run winver.exe.
3> nmake -f ms\nt.mak (for static library)
or
3> nmake -f ms\ntdll.mak (for DLL)
The source now compiles. Took approx 5 minutes on my laptop.
When compilation is completed, the libs or binaries have been placed in:
distroot/out32 - for static library build
or
distroot/out32dll - for DLL build
Building and linking
Now, back to visual studio and point out the libs and include path for headers. The include files are located in distroot/inc32/openssl.
Remember to add libeay32.lib and ssleay32.lib as linker input.
Rebuild the libcurl project.
Error!
Well at least for me with this version of OpenSSL.
it complained about a struct typedef in one of the OpenSSL headers. I couldn't find any info on this. After an hour of googling I broke my own principle and commented out the typedef from the OpenSSL header, and luckily libcurl wasn't using that symbol so it built fine.
Update: As pointed out by Jason, this issue seems to have dissapeared as of version 1.0.0a.
Now, for confirming that SSL support is enabled for libcurl, run the following code:
curl_version_info_data * vinfo = curl_version_info( CURLVERSION_NOW );
if( vinfo->features & CURL_VERSION_SSL )
// SSL support enabled
else
// No SSL
Simple as that.
Maybe this isn't the answer anyone is looking for, but I simply just downloaded the precompiled DLLs from this link found at http://curl.haxx.se/download.html
I ran the test that sharkin provided, and if( vinfo->features & CURL_VERSION_SSL ) proved to be true.
Following Robert Oschler's advice, here is my comment on the question as answer :
You can build recent libcurl (2012) with native SSL support for windows using the preprocessor symbols: USE_WINDOWS_SSPI and USE_SCHANNEL instead of the OpenSSL ones.
When compiling OpenSSL 1.0.0 on Windows with Visual Studio 2010, it eventually threw a 0x2 error:
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0
\VC\BIN\cl.EXE"' : return code '0x2'
Stop.
It seems that this error will be thrown because of a flag in the perl Configure file, namely -WX.
As the MSDN documentation states:
Treats all compiler warnings as errors. For a new project, it may be best to use /WX in all compilations; resolving all warnings will ensure the fewest possible hard-to-find code defects.
After removing the -WX occurrences in the Configure file and re-entering the commands stated here it built fine and passed all tests.
In my case follow the curl README file was enough.
My configuration is the following:
Visual Studio 2015 (VC14)
Static library
Win64
curl version 7.57.0
OpenSSL 1.0.2
Compilation of libCurl
Download libcurl source there: https://curl.haxx.se/download.html
Uncompress the file and go to the folder curl-7.57.0\projects
Open the README file and follow the instructions, this lead me to do the following:
Downloaded OpenSSL
Extract it and rename it to openssl, put it aside the curl folder, this is important as you'll open the VS project that expect to find openssl there.
Install Perl
Execute the utility build-openssl.bat to perform the compilation of openSSL. With my settings this became the following:
.\build-openssl.bat vc14 x64 release ..\..\openssl\
just runs .\build-openssl.bat -help to know more about the parameters.
After that you can see OpenSSL has been compiled as you got a new folder here: openssl\build\Win64
Open the Visual Studio project curl-7.57.0\projects\Windows\VC14\curl-all.sln
Be sure to set the visual studio project to the build configuration you need (LIB Release - LIB OpenSSL in my case)
Build all
The library is located at curl-7.57.0\build\Win64\VC14\LIB Release - LIB OpenSSL\libcurl.lib
Remarks
Don't forget to define the CURL_STATICLIB preprocessor in your own project
With static library, you will have to links with the dependencies of libcurl, see this answer
You might not want to depend on LDAP, in that case you can disable it by setting the preprocessor CURL_DISABLE_LDAP before you compile libcurl.
If you build with Visual Studio IDE and get 58 odd warnings as the likes of
"inconsistent dll linkage curl_global_init / curl_msnprintf /..."
you should add CURL_STATICLIB to the preproccessor definitions.
so the entire definition line should look like:
USE_SSLEAY;USE_OPENSSL;CURL_STATICLIB.
With this all the warning will disappear.
Some would ignore the warnings and go on using the libs, but then will get corresponding *error*s as the likes of curl_global_init / curl_msnprintf. It can be very annoying.
Hope it can help somebody.
\ fatal error C1083: Cannot open include
file: 'stdlib.h': No such file or directory
NMAKE: fatal error U1077::return code
That error can be solved by executing vcvarsall.bat in Visual Studio.
How to build libcurl C/C++ with OpenSSL (SSL support) on Windows
Install libcurl
Install OpenSSl
Build libcurl with OpenSSL
Installing libcurl
Go to the download page of libcurl and donwnload the ZIP file under Source Archives. In my case it is called curl-7.58.0.zip
Extract the archive and open projects/Windows/VC15/curl_all.sln with Visual Studio.
Installing OpenSSL
Download the windows binary of OpenSSL. In my case, I downloaded the windows installer file Win32 OpenSSL v1.1.0g from the Shining Light Productions distribution.
The installation folder for me is C:\OpenSSL-Win32.
Building libcurl with OpenSSL
In the curl_all.sln Visual Studio solution file, change the build configuration to DLL Debug - DLL OpenSSL.
In the Solution Explorer, right click the project curl and go to Properties.
Under Linker -> General modify Additional Library Directories and add the path to your OpenSSL directory + \lib. In my case, this is C:\OpenSSL-Win32\lib.
Apply and close the properties window.
Right click the project libcurl and do the same as the previous step, add OpenSSL directory + \lib to Additional Library Directories under Linker -> General.
Under C/C++ -> General, add C:\OpenSSL-Win32\include to the Additional Include Directories.
Finally go to Linker -> Input and modify Additional Dependencies. Replace all the lib files to the following:
ws2_32.lib
wldap32.lib
openssl.lib
libssl.lib
libcrypto.lib
Apply and close the properties window.
With the DLL Debug - DLL OpenSSL build configuration still selected, go to Build -> Build Solution.
Copy the two dll files libcrypto-1_1.dll and libssl-1_1.dll from the OpenSSL bin directory (C:\OpenSSL-Win32\bin) to the just created build directory curl-7.58.0\build\Win32\VC15\DLL Debug - DLL OpenSSL.
Validating Build
Inside the build directory, run curld.exe. If it runs with no errors (missing dll, etc.) then your build was successful.
i did "do_nt.bat" for windows 7 rc7100
don't forget "nmake -f ms\nt.mak install" to copy the headers correctly
thanks this did help a lot
Couple of notes in response to and/or in addition to the above..
First, if you don't want to mess with ActivePerl, Strawberry Perl is terrific and worked perfectly for this.
Second, in lieu of using do_ms.bat, I would recommend preferring do_masm if possible since, according to INSTALL.W32,
This is worth doing because it will
result in faster code: for example it
will typically result in a 2 times
speedup in the RSA routines.
Also, build 0.9.8l (L) of OpenSSL was a nightmare so I eventually gave up and reverted to 0.9.8k which built and linked (statically) with libcurl 1.9 without issue.