I wrote a c++ program using OpenSSL, it works fine on linux but when I try to compile on windows I get an error that libcrypto-1_1-x64.dll, libssl-1_1-x64.dll are missing
I am compiling using
g++ main.cpp -lws2_32 -LC:\msys64\mingw64\bin -IC:\msys64\mingw64\include\openssl
Both dll files can be found in C:\msys64\mingw64\bin, but the executable does not work
I just came up with a simple openssl example and compiled/linked fine
$ g++ ssltest.cpp -lssl -lcrypto -o ssltest
$ ls -l
-rw-r--r-- 1 Fred None 1072 Aug 21 01:18 ssltest.cpp
-rwxr-xr-x 1 Fred None 77824 Aug 21 01:18 ssltest.exe
It just works out of the box.
I am using the CLANG64 environment and I have the mingw-w64-clang-x86_64-openssl package installed. The files are installed on
$ pacman -Ql mingw-w64-clang-x86_64-openssl | grep '.dll'
mingw-w64-clang-x86_64-openssl /clang64/bin/libcrypto-1_1-x64.dll
mingw-w64-clang-x86_64-openssl /clang64/bin/libssl-1_1-x64.dll
mingw-w64-clang-x86_64-openssl /clang64/lib/engines-1_1/capi.dll
mingw-w64-clang-x86_64-openssl /clang64/lib/engines-1_1/padlock.dll
mingw-w64-clang-x86_64-openssl /clang64/lib/libcrypto.dll.a
mingw-w64-clang-x86_64-openssl /clang64/lib/libssl.dll.a
Related
I'm trying to create a recipe for the library here: https://github.com/hyrise/sql-parser
I'm building for OSX 10.13.
My build.sh looks like this:
#!/bin/bash
make VERBOSE=1
make DESTDIR="$PREFIX" install
I've also set up my SDK as per here: https://docs.conda.io/projects/conda-build/en/latest/resources/compiler-tools.html#macos-sdk
I can build the project fine outside of conda build, however conda build fails with the below issue:
x86_64-apple-darwin13.4.0-clang++ -std=c++1z -Wall -Werror -O3 -fPIC -c -o src/SQLParser.o src/SQLParser.cpp
In file included from src/SQLParser.cpp:2:
In file included from src/SQLParser.h:4:
In file included from src/SQLParserResult.h:4:
In file included from src/sql/SQLStatement.h:4:
In file included from /Users/j/miniconda3/envs/p37/conda-bld/sql-parser_1583094509703/_build_env/bin/../include/c++/v1/vector:265:
In file included from /Users/j/miniconda3/envs/p37/conda-bld/sql-parser_1583094509703/_build_env/bin/../include/c++/v1/iosfwd:90:
/Users/j/miniconda3/envs/p37/conda-bld/sql-parser_1583094509703/_build_env/bin/../include/c++/v1/wchar.h:119:15: fatal error: 'wchar.h' file not found
#include_next <wchar.h>
^~~~~~~~~
1 error generated.
make: *** [Makefile:66: src/SQLParser.o] Error 1
I can see wchar.h is in that dir
JMBA:v1 j$ ls -l /Users/j/miniconda3/envs/p37/conda-bld/sql-parser_1583094509703/_build_env/bin/../include/c++/v1 | grep wchar
-rw-rw-r-- 41 j staff 6272 28 Oct 2018 cwchar
-rw-rw-r-- 41 j staff 8080 28 Oct 2018 wchar.h
Any help on this would be appreciated.
You need to find a way to get -I$BUILD_PREFIX/include to the invocation of g++ / gcc
I was just trying to explain to someone the difference between compiled and interpreted code, when I was greeted with a
main.cpp:1:10: fatal error: 'iostream' file not found
when calling g++ main.cpp for a simple hello world c++ file.
I looked into this a bit and found ...
JM:Desktop user$ which g++
/usr/local/bin/g++
JM:Desktop user$ ls -al /usr/local/bin/g++
lrwxr-xr-x 1 user admin 47 4 Dez 2018 /usr/local/bin/g++ -> /Library/Developer/CommandLineTools/usr/bin/c++
JM:Desktop user$ ls -al /Library/Developer/CommandLineTools/usr/bin/c++
lrwxr-xr-x 1 root wheel 5 3 Feb 20:29 /Library/Developer/CommandLineTools/usr/bin/c++ -> clang
...that g++ is linked to clang and not clang++ and I therefore call the C-compiler.
I just deleted the Developer tools and installed them again - same thing.
Is this normal or did something mess up my system? Does it make any sense? What am I missing?
Thanks for the help!
It may actually be Homebrew's fault somehow...
JM:Desktop user$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin
/usr/local/bin is added by Homebrew.
'C++' for example links correctly to clang++ but it is in /usr/bin:
JM:Desktop user$ which c++
/usr/bin/c++
...and so is /usr/bin/g++.
I solved it by just deleting /user/local/bin/g++. The links are still strange.
I am running a Virtual Machine of Ubuntu 18.04 via Oracle VirtualBox.
I need Eclipse (including cdt) for a c++ project. So I ran the following statement on the console:
sudo apt-get install eclipse eclipse-cdt g++
Then I waited until it finished installing. Afterwards, I tried to run Eclipse, which caused the following error:
An error has occurred. See the log file
/home/matthias/.eclipse/org.eclipse.platform_3.8_155965261/configuration/1540208856928.log
So, I checked the log file. It says the following:
!SESSION Mon Oct 22 13:38:43 CEST 2018
----------------------------------------- !ENTRY org.eclipse.equinox.launcher 4 0 2018-10-22 13:38:43.262 !MESSAGE
Exception launching the Eclipse Platform: !STACK
java.lang.ClassNotFoundException:
org.eclipse.core.runtime.adaptor.EclipseStarter at
java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:466)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:566)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:626)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at
org.eclipse.equinox.launcher.Main.run(Main.java:1438) at
org.eclipse.equinox.launcher.Main.main(Main.java:1414)
Unfortunately, I am an absolute beginner with Ubuntu, as well as c++. I have no idea what could cause this problem. Can anybody help me?
I found that on Ubuntu18.04 this is due to a packaging problem (debugged with the help of a talented coworker). The fix was to manually install files from the older libequinox-osgi-java_3.8.1-8 package, to keep packaging happy.
Locate and get the .deb file
Examine contents of package vs. the system for overlaps
Manually extract deb into '/'
Commands:
$ cd /tmp
$ wget http://archive.ubuntu.com/ubuntu/pool/universe/e/eclipse/libequinox-osgi-java_3.8.1-8_all.deb
$ dpkg -c /tmp/libequinox-osgi-java_3.8.1-8_all.deb
$ dpkg -L libequinox-osgi-java
$ cd /
$ sudo dpkg -x /tmp/libequinox-osgi-java_3.8.1-8_all.deb
Notes:
Here we see commands to show eclipse depends on eclipse-rcp, which depends on libequinox-osgi-java (>= 3.9.1), which are all installed:
$ lsb_release -rc
Release: 18.04
Codename: bionic
$ apt-rdepends eclipse 2>&1 | egrep '^eclipse-rcp|libequinox-osgi-java'
eclipse-rcp
Depends: libequinox-osgi-java (>= 3.9.1)
libequinox-osgi-java
$ dpkg-query -W eclipse eclipse-rcp libequinox-osgi-java
eclipse 3.8.1-11
eclipse-rcp 3.8.1-11
libequinox-osgi-java 3.9.1-1
These commands show that the out-of-the box eclipse stubbornly insists on loading the older osgi_3.8.1.dist.jar despite not being able to stat it or open it:
$ strace -f -e trace=file /usr/lib/eclipse/eclipse -debug -clean -initialize 2>&1 |
egrep '^Framework.located|file:.*osgi_3.*jar|stat.*osgi_3.*jar'
[pid 117096] stat("/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar", 0x7f4f0ca95540) = -1 ENOENT (No such file or directory)
[pid 117096] stat("/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar", 0x7f4f0ca954c0) = -1 ENOENT (No such file or directory)
[pid 117096] stat("/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar", 0x7f4f0ca95550) = -1 ENOENT (No such file or directory)
[pid 117096] stat("/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar", 0x7f4f0ca954d0) = -1 ENOENT (No such file or directory)
Framework located:
file:/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar
...
The older package just happens to be the same package used in the Ubuntu16.04 eclipse packages. We tried a few different ways to force install both older and newer packages, etc. but this made packaging unhappy and the manual extract Just Worked(tm).
Following this howto I'm cross-compiling a bluetooth application for Raspberry Pi (ARM). When I try to link with libbluetooth I get the error below. Even the simplest helloworld application (without bluetooth code) won't link.
arm-linux-gnueabihf-g++ -c hello.cpp -o hello.o
arm-linux-gnueabihf-g++ hello.o -o hello -lbluetooth -L/home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf
/home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so: undefined reference to `__fdelt_chk#GLIBC_2.15'
sbf#sbf-VirtualBox ~/raspberrypi/projects/test $ ls -al /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth*
-rw-r--r-- 1 sbf sbf 132886 May 27 2016 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.a
lrwxrwxrwx 1 sbf sbf 23 Nov 24 21:20 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so -> libbluetooth.so.3.17.11
lrwxrwxrwx 1 sbf sbf 23 Nov 24 21:20 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so.3 -> libbluetooth.so.3.17.11
-rw-r--r-- 1 sbf sbf 103376 May 27 2016 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so.3.17.11
Edit (added):
GLIBC Version 2.19
pi#raspberrypi:~ $ ldd --version
ldd (Debian GLIBC 2.19-18+deb8u6) 2.19
What's going wrong?
I was experiencing the same issue yesterday trying to link libbluetooth using raspberry pi tools.
To solve this I downloaded a newer version of Linaro dev tools (6.1.1) than what is supplied by the raspberry pi tools repository.
Here is the link to the latest linaro toolchain release
Download "gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf.tar.xz" and put that folder in your raspberrypi/tools/arm-bcm2708/ directory along with the other toolchains.
Then set compiler/linker paths to point to the new directory.
(I am using cmake)
SET(CMAKE_C_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++)
(edit) I had trouble running my executable with this version of the toolchain compiled since jessie doesn't support gcc versions 5 or 6. Instead try using this release https://releases.linaro.org/components/toolchain/binaries/4.9-2016.02/arm-linux-gnueabihf/
I'm trying to build boost library under Arch Linux
$ uname -a
Linux wincode 2.6.37-ARCH #1 SMP PREEMPT Fri Feb 25 07:53:43 CET 2011 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ AuthenticAMD GNU/Linux
$ python --version
Python 3.2
$ ls /usr/include/python
python2.7/ python3.2mu/
$ ls /usr/lib/python
python2.6/ python2.7/ python3.1/ python3.2/
I'm building it using aur-repo. The auto-compile script could be found here.
Now I get:
./boost/python/*:50:23: fatal error: pyconfig.h: No such file or directory
compilation terminated.
at almost any file from boost.python library. So something is wrong with python and boost can't find it. At the end of the compiling I got:
...failed updating 336 targets...
...skipped 48 targets...
...updated 13264 targets...
Any help?
Quick google search comes up with http://lists.boost.org/boost-build/2006/04/13457.php.
Basically, add your python include directory to the include search paths.