Tell me please, i am trying to build Libevent for Windows using Cmake GUI, I select the libevent folder and click - configure. But, cmake reports an error:
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in
the system variable OPENSSL_ROOT_DIR (missing:
OPENSSL_CRYPTO_LIBRARY) (found version "1.1.1i")
Let me ask you two questions:
I understand that I have to show the Cmake the path to OpenSSL.
I found a similar question: CMake not able to find OpenSSL library
Where it says what is needed:
set the variables below:
OPENSSL_ROOT_DIR=D:/softwares/visualStudio/openssl-0.9.8k_WIN32
OPENSSL_INCLUDE_DIR=D:/softwares/visualStudio/openssl-0.9.8k_WIN32/include
OPENSSL_LIBRARIES=D:/softwares/visualStudio/openssl-0.9.8k_WIN32/lib
But I just can't figure out how to do this in CMake GUI.
and i don't understand why the error says about openssl version 1.1.1i. Why exactly - "1.1.1i" ?
Related
I'm trying to build the rustless "basic usage" sample project.
This is my Cargo.toml. I had to add the dependencies in Cargo.toml in order to avoid the build error error[E0463]: can't find crate for 'hyper'
[package]
name = "rustlessTest"
version = "0.1.0"
authors = ["x"]
[dependencies.rustless]
git = "https://github.com/rustless/rustless"
[dependencies]
hyper = "0.9.14"
iron = "0.4.0"
rustc-serialize = "0.3.22"
valico = "1.0.1"
I also downloaded the OpenSSL library & sources. I stored them under C:\OpenSSL\lib and C:\OpenSSL\include and set the directories as a environment variable, as mentioned in this thread about how to using Hyper on Windows.
When I try to compile, it fails with the following output:
Build failed, waiting for other jobs to finish...
error: failed to run custom build command for `openssl v0.7.14`
....
....
I finally managed to build OpenSSL on Windows by following the solution from this blog post.
Here's a summary:
Download Win64 OpenSSL v1.0.1u from here. Install it with default settings.
Set the following environment variables
DEP_OPENSSL_INCLUDE=C:\OpenSSL-Win64\include
OPENSSL_INCLUDE_DIR=C:\OpenSSL-Win64\include
OPENSSL_LIB_DIR=C:\OpenSSL-Win64\lib\VC
OPENSSL_LIBS=ssleay32MT:libeay32MT
Install Visual Studio 2015 or Visual Studio Code with C++ support.
Ensure that all path variables are set correctly
Set rust-msvc as the toolchain. You can check this by typing rustup show into the console. You should get an output like this:
Default host: x86_64-pc-windows-msvc
stable-x86_64-pc-windows-msvc (default)
rustc 1.13.0 (2c6933acc 2016-11-07)
Now you should able to build Rust projects which requires OpenSSL.
You are right that it is because OpenSSL is not found. A good tutorial is in the README of rust-openssl.
Windows MSVC
On MSVC it's unfortunately not always a trivial process acquiring
OpenSSL. Perhaps the easiest way to do this right now is to download
precompiled binaries and install them on your system. Currently it's
recommended to install the 1.1.0 (non-light) installation if you're
choosing this route.
Once a precompiled binary is installed you can configure this crate to
find the installation via an environment variable:
set OPENSSL_DIR=C:\OpenSSL-Win64
Note that this OpenSSL distribution does not ship with any root
certificates. So to make requests to servers on the internet, you have
to install them manually. Download the cacert.pem file from here,
copy it somewhere safe (C:\OpenSSL-Win64\certs is a good place) and
point the SSL_CERT_FILE environment variable there:
set SSL_CERT_FILE=C:\OpenSSL-Win64\certs\cacert.pem
After that, you're just a cargo build away!
Windows GNU (MinGW)
The easiest way to acquire OpenSSL when working with MinGW is to
ensure you're using MSYS2 and to then
execute:
# 32-bit pacman -S mingw-w64-i686-openssl
# 64-bit pacman -S mingw-w64-x86_64-openssl
And after that, a cargo build should be all you need!
Manual configuration
rust-openssl's build script will by default attempt to locate OpenSSL
via pkg-config or other system-specific mechanisms. This will not work
in some situations however, for example cross compiling or when using
a copy of OpenSSL other than the normal system install.
The build script can be configured via environment variables:
OPENSSL_DIR - If specified, a directory that will be used to find OpenSSL installation. It's expected that under this directory the
include folder has header files and a lib folder has the runtime
libraries.
OPENSSL_LIB_DIR - If specified, a directory that will be used to find OpenSSL libraries. Overrides the lib folder implied by
OPENSSL_DIR (if specified).
OPENSSL_INCLUDE_DIR - If specified, a directory that will be used to find OpenSSL header files. Overrides the include folder implied
by OPENSSL_DIR (if specified).
OPENSSL_STATIC - If specified, OpenSSL libraries will be statically rather than dynamically linked.
If OPENSSL_DIR is specified, then the build script will skip the
pkg-config step.
It's a nightmare; OpenSSL with Windows is really painful. I hope that one day Rust has its own implementation of SSL/TLS.
trying to install BlogLiterately on win7/64.
installed HP 2014.2/64
cabal update
cabal install cabal-install
renamed C:\Program Files\Haskell Platform\2014.2.0.0\lib\extralibs\bin\cabal.exe
to *.old
cabal update
cabal install BlogLiterately fails cuz needs unix toolchain to install new version of network
tried installing mingw, but gave up cuz the package manager that pops up only lists packages with suffix 32, i want 64, can't tell from http://www.mingw.org/ if it supports 64 bit.
tried installing cygwin64, added C:\cygwin64\bin to the end of PATH, didn't work, see on internet that people think cygwin doesn't work for ghc so well anymore, even though the original error said cygwin would work
found http://msys2.github.io/, installed it, followed instructions to update with pacman on that page, used Win64 Shell
got error that HsOpenSSL is missing c libs eay32 ssl32, googling says to install http://slproweb.com/products/Win32OpenSSL.html then cabal install HsOpenSSL --extra-include-dirs="c:/OpenSSL-Win64/include" --extra-lib-dirs="c:/OpenSSL-Win64" -- this works, but can't find any official looking docs saying i need Win32OpenSSL -- why can't cabal install this for me?
now cabal install BlogLiterately fails cuz ghc.exe: unable to load package 'hs-bibutils-5.5'
the error:
ghc.exe: warning: _stricmp from msvcrt is linked instead of __imp__stricmp
ghc.exe: warning: _stricmp from msvcrt is linked instead of __imp__stricmp
ghc.exe: warning: _atoi64 from msvcrt is linked instead of __imp__atoi64
ghc.exe: warning: toupper from msvcrt is linked instead of __imp_toupper
ghc.exe: warning: _strnicmp from msvcrt is linked instead of __imp__strnicmp
ghc.exe: C:\Users\nlab\AppData\Roaming\cabal\x86_64-windows-ghc-7.8.3\hs-bibutils-5.5\HShs-bibutils-5.5.o: unknown symbol `strdup'
cabal install hs-bibutils --reinstall --force-reinstalls succeeds, but i get the same error when retrying the BlogLiterately install. i tried moving /c/Program Files/Haskell Platform/2014.2.0.0/mingw/bin to the front of the PATH and again reinstalling hs-bibutils, same result.
what is the right way to do this?!?! which unix toolchain are we supposed to use, and how are we supposed to configure it? why isn't it enough that HP includes mingw's binaries? gah.
For posterity, new versions of the Haskell Platform for windows (since 8.0.1) allow network to build properly if the cabal file is augmented with a few extra settings as described on the platform website: https://www.haskell.org/platform/
Modify your cabal config file (you can verify the location by running "cabal user-config init") to contain the following lines:
extra-prog-path: C:\Program Files\Haskell Platform\8.0.1\msys\usr\bin
extra-lib-dirs: C:\Program Files\Haskell Platform\8.0.1\mingw\lib
extra-include-dirs: C:\Program Files\Haskell Platform\8.
I'm trying to install monadiccp with the "RuntimeGecode" flag so that it includes the Gecode libraries:
cabal install monadiccp --flags="RuntimeGecode Debug" --extra-lib-dirs="D:\Programme\Gecode\lib;d:\programme\Gecode\bin" --extra-include-dirs=D:\Programme\Gecode\include\
But that doesn't work, it fails with:
ld.exe: cannot find -lgecodesupport
ld.exe: cannot find -lgecodeset
And so on... See the -v3 log output.
What am I doing wrong? The libraries don't seem any special, so are there some extra steps I need to do in Windows?
Update: The binaries downloadable from gecode.org are compiled with Visual Studio and aren't compatible with gcc (see this answer for the root problem). As suggested by Stephen, I'll try to build Gecode with MinGW/MSYS from source now.
I'm having issues with CVBlob locating the OpenCV installation on OSX 10.6. I have patch for the osx install as described in an earlier message on the cvblob wiki. When I run make, the build process immediately complains that it cannot find cv.h or highgui.h and then subsequently fails to locate additional symbols and vars declared in those headers.
The cmake command I am using is :
cmake -DOpenCV_DIR=/usr/local/Cellar/opencv/2.3.1a/ .
I can see that cv.h is contained in the includes directory in that location. I also tried the following cmake command where I specify the location of the OpenCV Cmake info:
cmake -DOpenCV_DIR=/usr/local/share/OpenCV/ .
Neither seems to correctly tell the cvblob installation where OpenCV is located.
Please help!
SR
In later versions of cvBlob, openCV is automatically located. But version 0.10.4 and before expects the openCV directory to be located next to the cvblob directory. Specifically, version 0.10.4 seems to expect the opencv-2.4.9 directory to be next to cvblob. In this version of cvBlob, the -DOpenCV_DIR parameter seems to have no effect on OS X, and this was the only way I could get it working.
Are you working with Xcode?
If so, just add the OpenCV-path to your header search path in your Xcode project.
I'm using Qt Creator 2.2.1 under MacOS X 10.6.8, standard MacOS X install for CMake 2.8.5 and Qt SDK version 1.1.2 released on June 21st (Qt 4.7.3 libraries).
My CMakeLists.txt fails in the find_package for Qt4 -- the second of the lines below:
set (CMAKE_MODULE_PATH /Applications/CMake 2.8-5.app/Contents/share/cmake-2.8/Modules)
find_package (Qt4 REQUIRED HINTS /Users/myname/QtSDK)
I added the first just to make sure it knew where FindQt4.cmake lives, but same error either with or without that line.
The error from CMake is as follows:
-- Configuring incomplete, errors occurred!
CMake Error at CMakeLists.txt:30 (find_package):
Could not find a configuration file for package Qt4.
Set Qt4_DIR to the directory containing a CMake configuration file for Qt4.
The file will have one of the following names:
Qt4Config.cmake
qt4-config.cmake
I've done some finds in both the installed QtSDK location and the CMake directories, and there's no Qt4Config.cmake. I did see in the CMake module directory -- FindQt4.cmake, Qt4ConfigDependentSettings.cmake, and UseQt4.cmake
According to this page:
The find_package() command will look in the module path for Find.cmake,
which is the typical way for finding libraries. First CMake checks all directories in
${CMAKE_MODULE_PATH}, then it looks in its own module directory
/share/cmake-x.y/Modules/.
If no such file is found, it looks for Config.cmake or
-config.cmake, which are supposed to be installed by libraries
(but there are currently not yet many libraries which install them) and
that don't do detection, but rather just contain hardcoded values for the
installed library.
So it seems like FindQt4.cmake should find the Qt4 I'm hinting at its location -- so why is it even making it down to Qt4Config.cmake? Anyone get this to work on Mac with those standard installs?
The "find_package(Qt4..." command is very dependent on finding a qmake executable. Is "qmake" on your path? Try something like
set(QT_QMAKE_EXECUTABLE "<actual location of qmake on your system>")
find_package(Qt4 REQUIRED)
Edit: I meant to type QT_QMAKE_EXECUTABLE; and I did not grok your statement about CMAKE_MODULE_PATH at first.