How to know the name of a library installed with vcpkg? - c++

In my simple app which I build with cmake I use opencv, which is installed with vcpkg.
On CMakeLists.txt I have to find_package(OpenCV REQUIRED), replacing OpenCV by opencv will fail the build.
From vcpkg list I see opencv is installed.
So from where should I get the correct spelling, OpenCV?
Executing the command to install the package again does not help for opencv.
./vcpkg install opencv
Computing installation plan...
The following packages are already installed:
opencv[core,default-features]:x64-osx -> 4.5.5
Package opencv:x64-osx is already installed
Restored 0 packages from /Users/user/.cache/vcpkg/archives in 2.309 us. Use --debug to see more details.
Total elapsed time: 4.752 ms
user#users-MacBook-Pro vcpkg % ./vcpkg install opencv --debug
[DEBUG] Feature flag 'binarycaching' unset
[DEBUG] Feature flag 'manifests' unset
[DEBUG] Feature flag 'compilertracking' unset
[DEBUG] Feature flag 'registries' unset
[DEBUG] Feature flag 'versions' unset
[DEBUG] Failed to open: /Users/user/vcpkg/vcpkg-bundle.json
[DEBUG] Bundle config: readonly=0, usegitregistry=0, embeddedsha=nullopt
[DEBUG] Using builtin-ports: /Users/user/vcpkg/ports
[DEBUG] Using installed-root: /Users/user/vcpkg/installed
[DEBUG] Using buildtrees-root: /Users/user/vcpkg/buildtrees
[DEBUG] Using packages-root: /Users/user/vcpkg/packages
[DEBUG] Using scripts-root: /Users/user/vcpkg/scripts
[DEBUG] Using vcpkg-root: /Users/user/vcpkg
[DEBUG] Using scripts-root: /Users/user/vcpkg/scripts
[DEBUG] Using builtin-registry: /Users/user/vcpkg/versions
[DEBUG] Using downloads-root: /Users/user/vcpkg/downloads
[DEBUG] Default binary cache path is: /Users/user/.cache/vcpkg/archives
Computing installation plan...
The following packages are already installed:
opencv[core,default-features]:x64-osx -> 4.5.5
Package opencv:x64-osx is already installed
Restored 0 packages from /Users/user/.cache/vcpkg/archives in 2.227 us. Use --debug to see more details.
Total elapsed time: 5.909 ms
[DEBUG] /Users/runner/work/1/s/src/vcpkg/install.cpp(1229):
[DEBUG] Time in subprocesses: 3284 us
[DEBUG] Time in parsing JSON: 1094 us
[DEBUG] Time in JSON reader: 577 us
[DEBUG] Time in filesystem: 903 us
[DEBUG] Time in loading ports: 2630 us
[DEBUG] Exiting after 9.574 ms (5984 us)
It just mentions opencv every time, not OpenCV.

CMake module/config name is not equivalent to the vcpkg port name
vcpkg might print a usage message (if your vcpkg is new enough and the heuristics kick in.)
find_package is not always case insensitive as stated in the docs how the CONFIG lookup works:
In this mode, CMake searches for a file called <lowercasePackageName>-config.cmake or <PackageName>Config.cmake.
-> As such I deduce that OpenCV installs a config file which is named OpenCVConfig.cmake which is backed up by the vcpkg file list:
opencv4:x64-windows:/share/opencv/OpenCVConfig-version.cmake
opencv4:x64-windows:/share/opencv/OpenCVConfig.cmake

Related

Failed to install POCO C++ through vcpkg

I am trying to install POCO libraries for C++ through vcpkg, through this command in Windows PowerShell :
.\vcpkg install poco:x64-windows
And I am getting this error :
Error: Building package pcre:x64-windows failed with: BUILD_FAILED
What should I do?
(This is the full command's output)
The following packages will be built and installed:
* pcre[core]:x64-windows -> 8.45
poco[core]:x64-windows -> 1.11.0
* vcpkg-cmake[core]:x64-windows -> 2021-09-13
* vcpkg-cmake-config[core]:x64-windows -> 2021-09-27
* zlib[core]:x64-windows -> 1.2.11#13
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-windows...
Restored 0 packages from C:\Users\AB\AppData\Local\vcpkg\archives in 244.5 us. Use --debug to see more details.
Starting package 1/5: pcre:x64-windows
Building package pcre[core]:x64-windows...
CMake Warning at scripts/cmake/vcpkg_download_distfile.cmake:170 (message):
SILENT_EXIT has been deprecated as an argument to vcpkg_download_distfile
-- remove the argument to resolve this warning
Call Stack (most recent call first):
ports/pcre/portfile.cmake:12 (vcpkg_download_distfile)
scripts/ports.cmake:142 (include)
-- Downloading https://ftp.pcre.org/pub/pcre/pcre-8.45.zip -> pcre-8.45.zip...
[DEBUG] Feature flag 'binarycaching' unset
[DEBUG] Feature flag 'manifests' = off
[DEBUG] Feature flag 'compilertracking' unset
[DEBUG] Feature flag 'registries' unset
[DEBUG] Feature flag 'versions' unset
[DEBUG] Downloading https://ftp.pcre.org/pub/pcre/pcre-8.45.zip
[DEBUG] Download failed -- retrying after 1000 ms.
[DEBUG] Download failed -- retrying after 2000 ms.
[DEBUG] Download failed -- retrying after 4000 ms.
[DEBUG] D:\a\_work\1\s\src\vcpkg\base\downloads.cpp(656)
Error: Failed to download from mirror set:
https://ftp.pcre.org/pub/pcre/pcre-8.45.zip: WinHttpSendRequest() failed: 12002
https://ftp.pcre.org/pub/pcre/pcre-8.45.zip: WinHttpSendRequest() failed: 12002
https://ftp.pcre.org/pub/pcre/pcre-8.45.zip: WinHttpSendRequest() failed: 12002
https://ftp.pcre.org/pub/pcre/pcre-8.45.zip: WinHttpSendRequest() failed: 12002
[DEBUG] Exiting after %s (%d us)
CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:84 (message):
Failed to download file with error: 1
If you use a proxy, please check your proxy setting. Possible causes are:
1. You are actually using an HTTP proxy, but setting HTTPS_PROXY variable
to `https://address:port`. This is not correct, because `https://` prefix
claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr
, etc..) is an HTTP proxy. Try setting `http://address:port` to both
HTTP_PROXY and HTTPS_PROXY instead.
2. You are using Fiddler. Currently a bug (https://github.com/microsoft/vcpkg/issues/17752)
will set HTTPS_PROXY to `https://fiddler_address:port` which lead to problem 1 above.
Workaround is open Windows 10 Settings App, and search for Proxy Configuration page,
Change `http=address:port;https=address:port` to `address`, and fill the port number.
3. You proxy's remote server is out of service.
In future vcpkg releases, if you are using Windows, you no longer need to set
HTTP(S)_PROXY environment variables. Vcpkg will simply apply Windows IE Proxy
Settings set by your proxy software. See (https://github.com/microsoft/vcpkg-tool/pull/49)
and (https://github.com/microsoft/vcpkg-tool/pull/77)
Otherwise, please submit an issue at https://github.com/Microsoft/vcpkg/issues
Call Stack (most recent call first):
scripts/cmake/vcpkg_download_distfile.cmake:292 (z_vcpkg_download_distfile_show_proxy_and_fail)
ports/pcre/portfile.cmake:12 (vcpkg_download_distfile)
scripts/ports.cmake:142 (include)
Error: Building package pcre:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `git pull` and `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
package: pcre[core]:x64-windows -> 8.45
vcpkg version: 2021-11-02-af04ebf6274fd6f7a941bff4662b3955c64f6f42
vcpkg-tool version: 3730cbe99 2021-11-08 (49 minutes ago)
Additionally, attach any relevant sections from the log files above.```

VS Code use Jupyter Notebook behind proxy

I referred to this question but I have a different question
Get VS Code Python extension to connect to Jupyter running on remote AWS EMR master node
Environment:
The Jupyter Notebook is on AWS EMR.
To access notebook from the browser using a SOCKS5 proxy. To do so, I have to connect to the VPN to work, SSH using PuTTY using .ppk file and Tunnel (Dynamic Port Forwarding).
To automate the step above, I am using PLink(Homepage | Docs | Download) : c:\stuff\plink.exe --ssh -i c:\stuff\file.ppk -D XXXX user-name#<some_IP_address
I can successfully enable proxy by using msedge.exe --proxy-server="socks5://<address>" or chrome.exe --proxy-server="socks5://<address>"
VS Code Version:
C:\Users\ablaze>code --version
1.55.2
3c4e3df9e89829dce27b7b5c24508306b151f30d
x64
Objective:
How can I access the remote Jupyter Notebook hosted on AWS EMR behind a proxy from Visual Studio Code?
I tried and failed:
Given Visual Studio Code is built on top of Electron and benefits from all the networking stack capabilities of Chromium.
I used Plink like above to SSH and then executed the following command on my windows command prompt: C:\Users\ablaze>code --proxy-server="socks5://<address>" --verbose
Error message:
[17668:0505/104410.116:WARNING:dns_config_service_win.cc(692)] Failed to read DnsConfig.
[main 2021-05-05T14:44:10.224Z] Starting VS Code
[main 2021-05-05T14:44:10.224Z] from: c:\Users\ablaze\AppData\Local\Programs\Microsoft VS Code\resources\app
[main 2021-05-05T14:44:10.224Z] args: {
_: [],
...
'no-proxy-server': false,
'proxy-server': 'socks5://localhost:8088',
...
logsPath: 'C:\\Users\\ablaze\\AppData\\Roaming\\Code\\logs\\20210505T104410'
}
...
[main 2021-05-05T14:44:10.258Z] windowsManager#open pathsToOpen [
{
backupPath: 'C:\\Users\\ablaze\\AppData\\Roaming\\Code\\Backups\\1620224957079',
remoteAuthority: undefined
}
]
To double check I also opened the log file C:\Users\ablaze\AppData\Roaming\Code\logs\20210505T104410\main.log
...
[2021-05-05 10:44:40.345] [main] [trace] update#checkForUpdates, state = idle
[2021-05-05 10:44:40.345] [main] [info] update#setState checking for updates
[2021-05-05 10:44:40.345] [main] [trace] RequestService#request https://update.code.visualstudio.com/api/update/win32-x64-user/stable/3c4e3df9e89829dce27b7b5c24508306b151f30d
[2021-05-05 10:44:40.346] [main] [trace] resolveShellEnv(): skipped (Windows)
[2021-05-05 10:44:44.354] [main] [error] Error: net::ERR_PROXY_CONNECTION_FAILED
at SimpleURLLoaderWrapper.<anonymous> (electron/js2c/browser_init.js:109:6508)
at SimpleURLLoaderWrapper.emit (events.js:315:20)
[2021-05-05 10:44:44.354] [main] [info] update#setState idle

Stack install Yesod fails at GHC decompressing

Running stack install yesod-bin --install-ghc fails at ghc decompressing with message: "Problem while decompressing C:\Users\user\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.4.tar.xz"
I try to run this command on Windows 10 64 bit, cmd, with the latest Haskell platform version 8.6.5-core-x86_64 after creating a project with yesod-sqlite template. I've tried a different version as well, with same result. stack install yesod-bin-1.4.11 --install-ghc
> stack install yesod-bin --install-ghc
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Downloaded ghc-8.4.4.
Downloaded 7z.dll.
Downloaded 7z.exe.
Problem while decompressing C:\Users\user\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.4.tar.xz
stack build retries and fails at the same point. I'd expect some proper install instead.
Update: stack setup --verbose output:
Version 1.9.3, Git revision 40cf7b37526b86d1676da82167ea8758a854953b (6211 commits) x86_64 hpack-0.31.1
2019-06-16 16:47:58.662299: [debug] Checking for project config at: E:\Dev\haskell\dosey\stack.yaml
2019-06-16 16:47:58.666295: [debug] Loading project config file stack.yaml
2019-06-16 16:47:58.675310: [debug] Decoding build plan from: C:\sr\build-plan\lts-12.26.yaml
2019-06-16 16:47:58.678295: [debug] Trying to decode C:\sr\build-plan-cache\lts-12.26.cache
2019-06-16 16:47:58.689295: [debug] Success decoding C:\sr\build-plan-cache\lts-12.26.cache
2019-06-16 16:47:58.696299: [debug] Potential GHC builds: standard
2019-06-16 16:47:58.698299: [debug] Found already installed GHC builds:
2019-06-16 16:47:59.145295: [debug] Trying to setup GHC build: standard
2019-06-16 16:47:59.147298: [info] Preparing to install GHC to an isolated location.
2019-06-16 16:47:59.149296: [info] This will not interfere with any system-level installation.
2019-06-16 16:47:59.151297: [debug] Downloading from https://github.com/commercialhaskell/ghc/releases/download/ghc-8.4.4-release/ghc-8.4.4-x86_64-unknown-mingw32.tar.xz to C:\Users\user\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.4.tar.xz ...
2019-06-16 16:47:59.153294: [debug] Will check against sha1 hash: 697db44cdf7fdf1a6d83ada61e36857f2e241e3d
2019-06-16 16:47:59.157298: [debug] Will check against sha256 hash: da29dbb0f1199611c7d5bb7b0dd6a7426ca98f67dfd6da1526b033cd3830dc05
2019-06-16 16:48:00.717297: [info] Already downloaded.
2019-06-16 16:48:00.721299: [debug] Downloading from https://github.com/fpco/minghc/blob/master/bin/7z.dll?raw=true to C:\Users\user\AppData\Local\Programs\stack\x86_64-windows\7z.dll ...
2019-06-16 16:48:00.724298: [debug] Will check against sha1 hash: 168a288d4456f0473f66e86a2d6fec4eb6f4b993
2019-06-16 16:48:00.729295: [info] Already downloaded.
2019-06-16 16:48:00.731294: [debug] Downloading from https://github.com/fpco/minghc/blob/master/bin/7z.exe?raw=true to C:\Users\user\AppData\Local\Programs\stack\x86_64-windows\7z.exe ...
2019-06-16 16:48:00.738296: [debug] Will check against sha1 hash: 187dff8a3327da87050f678579816e5bae40c632
2019-06-16 16:48:00.742294: [info] Already downloaded.
2019-06-16 16:48:00.744297: [debug] Run process: C:\Users\user\AppData\Local\Programs\stack\x86_64-windows\7z.exe x -oC:\Users\user\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.4-tmp1496\ -y C:\Users\user\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.4.tar.xz
2019-06-16 16:48:02.169297: [debug] Process finished in 1423ms: C:\Users\user\AppData\Local\Programs\stack\x86_64-windows\7z.exe x -oC:\Users\user\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.4-tmp1496\ -y C:\Users\user\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.4.tar.xz
Problem while decompressing C:\Users\user\AppData\Local\Programs\stack\x86_64-windows\ghc-8.4.4.tar.xz
Another cabal install attempt revealed that the network package is not willing to compile in Windows at all, at least not in the generic command prompt (cmd), but it requires MingW, MSys or Cygwin. I tried the latter for cabal self update, and it succeeded. Then still in Cygwin, I tried the stack install again, and it worked.
Unfortunately the stack command's output didn't provide any hint towards Cygwin, and left me clueless for a while. In Cygwin however, Yesod builds and starts, and demo website works properly. Maybe some emphasis against generic windows command prompt could help to avoid such misunderstandings.

Google Cloud Bigtable HBase shell connectivity hangs

To start, I think this issue is related to the issue in this post. However, the fix for HBase shell connectivity suggested in comments did not work for me either, and I see no resolution.
Connecting to my Bigtable cluster from the HBase shell just hangs on any command. Example:
ubuntu:/opt/hbase-1.1.2# ./bin/hbase shell
2016-02-29 13:43:38,975 WARN [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
2016-02-29 13:43:39,114 INFO [main] grpc.BigtableSession: Opening connection for projectId [removed], zoneId us-central1-b, clusterId [removed], on data host bigtable.googleapis.com, table admin host bigtabletableadmin.googleapis.com.
2016-02-29 13:43:39,191 INFO [BigtableSession-startup-0] grpc.BigtableSession: gRPC is using the JDK provider (alpn-boot jar)
2016-02-29 13:43:39,516 INFO [bigtable-connection-shared-executor-pool1-t2] io.RefreshingOAuth2CredentialsInterceptor: Refreshing the OAuth token
HBase Shell; enter 'help<RETURN>' for list of supported commands.
Type "exit<RETURN>" to leave the HBase Shell
Version 1.1.2, rcc2b70cf03e3378800661ec5cab11eb43fafe0fc, Wed Aug 26 20:11:27 PDT 2015
hbase(main):001:0> list
TABLE
The shell just hangs there indefinitely and does this on any command entered.
Here are the results CheckConfig utility:
ubuntu:/opt/hbase-1.1.2# ./bin/hbase com.google.cloud.bigtable.hbase.CheckConfig
User Agent: bigtable-hbase-1.1-0.2.2
Project ID: [removed]
Cluster Id: [removed]
ZoneId: us-central1-b
Cluster admin host: bigtableclusteradmin.googleapis.com
Table admin host: bigtabletableadmin.googleapis.com
Data host: bigtable.googleapis.com
Attempting credential refresh...
Exception in thread "main" java.lang.IllegalAccessError: tried to access field sun.security.ssl.Handshaker.localSupportedSignAlgs from class sun.security.ssl.ClientHandshaker
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:278)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:913)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:849)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1035)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1093)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
at com.google.bigtable.repackaged.com.google.api.client.http.javanet.NetHttpRequest.execute(NetHttpRequest.java:77)
at com.google.bigtable.repackaged.com.google.api.client.http.HttpRequest.execute(HttpRequest.java:965)
at com.google.auth.oauth2.ServiceAccountCredentials.refreshAccessToken(ServiceAccountCredentials.java:222)
at com.google.auth.oauth2.OAuth2Credentials.refresh(OAuth2Credentials.java:76)
at com.google.cloud.bigtable.hbase.CheckConfig.main(CheckConfig.java:68)
Here are the relevant versions and environment variables:
Linux ubuntu7 3.19.0-30-generic #34~14.04.1-Ubuntu SMP Fri Oct 2 22:09:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
java version "1.7.0_95"
export ALPN_VERSION=7.1.3.v20150130
export HBASE_CLASSPATH="$(pwd)/lib/bigtable/bigtable-hbase-1.1-0.2.2.jar"
export HBASE_OPTS="${HBASE_OPTS} -Xms1024m -Xmx2048m -Xbootclasspath/p:$(pwd)/lib/bigtable/alpn-boot-${ALPN_VERSION}.jar"
I'd appreciate any solutions/advice/hints at resolving this. Thanks!
You might wish to use our Quickstart for HBase Shell access - It should just work. (Take a look at the hbase-site & hbase-env after running quickstart to see how to configure in the future)
The 1.7.0_95 release of Java is incompatible w/ alpn-boot. We are moving all of our samples to use netty-tcnative-boringssl see the Managed-VM-GAE example for additional info.

hue installation error on AWS EC2

Hello I am trying to install Hue on AWS EC2 instance.
Following below link.
https://github.com/cloudera/hue
While doing step make apps I am getting below error.
[WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVersion failed with message:
Detected JDK Version: 1.6.0-30 is not in the allowed range [1.7.0,1.7.1000].
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 14.717s
[INFO] Finished at: Sun Mar 09 13:18:59 EDT 2014
[INFO] Final Memory: 5M/25M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce (default) on project hue-parent: Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
I have java version
java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (rhel-2.3.10.4.el6_4-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
Additional information can be provided. Thanks for your help.
You can also remove the JDK 7 check by editing:
vim maven/pom.xml
And replacing the '7' by '6':
<javaVersion>1.7</javaVersion>
<sourceJavaVersion>1.7</sourceJavaVersion>
<targetJavaVersion>1.7</targetJavaVersion>
(obviously you should it might be better to make sure Java 7 is the default if you plan to use 7)
It looks like you have another Java version in your system too. Based on what your installation says:
Detected JDK Version: 1.6.0-30
Make sure your JAVA_HOME variable points to the home of your Java 1.7 installation.