How to statically compile Qt with OpenSSL support on Windows (with MinGW compiler)
The desired 'outcome' of this Qt build is to build and ship a portable Qt application with built-in SSL support.
So this is an age old problem with a multitude of questions on this topic, yet very few solutions exist that solves the problem. Some of these questions (and problems):
QT https SSL support for static QT static program build - getting 'Protocol “https” is unknown'
about compiling openssl inside qt application
Build Qt static from source enabling OpenSSL support
Compile static version of QT + OpenSSL Support
how to compile qt static with open ssl
Compiling static for Windows with OpenSSL
there are many more
and some of my own questions (using OpenSSL v1.1.1d & Qt 5.13 with MinGW ):
Statically compiled Qt 5.13.1 with OpenSSL 1.1.1d producing QSslSocket::connectToHostEncrypted: TLS initialization failed
Create a standalone binary using Qt with OpenSSL support
Static OpenSSL *.a libraries not linked target binary (using Statically Compiled Qt with SSL)
Static compile Qt 5.13.1 with -openssl-linked using MinGW (Windows 10)
Most of these questions do not have answers, and those answers provided (obviously) did not help in compiling, due to some error output or simply OpenSSL was never linked (built into the portable/binary application), or many other errors.
Further, there appears to be alot of confusion about using -ssl, -openssl-linked, -openssl and what each means. Also, if one should use -L/path/to/libs/static -l library1 -l library2 vs using the OPENSSL_HOME env variable and specify the path to headers & static / linked libraries, etc
Please note:
Ideally, in compiling, specific instructions for libraries would be required such as OpenSSL v1.0.2 or OpenSSL v1.1 and the qmake arguments in building a static Qt with those specific libraries in addition to things that should be considered during the build process.
What does Qt say?
Qt has provide some help in the form of these 2 posts:
Building a static Qt for Windows using MinGW with a Powershell script which does compile Qt statically using MinGW, but adding the various combinations (and permutations) of OpenSSL libraries -l and/or -L to the various paths (.lib), (.a), header files, etc simply did not work
Compiling OpenSSL with MinGW
The aim of this question is to give a detailed explanation and step-wise method in allowing those who need to compile a static Qt version with SSL some support and direction.
This is an unnatural "question", but having seen so many questions with no/very few solutions for cherrypicked cases in each specific question makes a general solution very difficult to obtain.
I am posting this question in hopes of a general solution being made available that could benefit all.
I just noticed this question just recently, so I haven't had time yet to write complete step-by-step instructions from the ground up, but I was able to do a static build of qt-5.15.0 in my environment which is based on MSYS2 shell together with MinGW-w64 with GCC 10 personal build from http://winlibs.com/ with all the prerequisites already compiled in the same environment.
The version of openssl was 1.1.1g built like this (static and shared libraries):
# location of Perl
PERLDIR=/d/Prog/Perl/strawberry-perl-5.30.0.1-64bit-portable/perl
# install destination
INSTALLPREFIX=/d/Prog/winlibs64-10.1.0/custombuilt
# for 32-bit replace mingw64 with mingw in the next line
./Configure --prefix=$INSTALLPREFIX threads shared zlib-dynamic -DOPENSSL_NO_CAPIENG mingw64 &&
make &&
PATH=$PERLDIR/bin:$PATH make -j1 install OPENSSLDIR_dir=$INSTALLPREFIX &&
strip $INSTALLPREFIX/bin/*.exe $INSTALLPREFIX/bin/*.dll &&
cp -f $INSTALLPREFIX/lib/libcrypto.a $INSTALLPREFIX/lib/libeay32.a &&
cp -f $INSTALLPREFIX/lib/libcrypto.dll.a $INSTALLPREFIX/lib/libeay32.dll.a &&
cp -f $INSTALLPREFIX/lib/libssl.a $INSTALLPREFIX/lib/libssleay32.a &&
cp -f $INSTALLPREFIX/lib/libssl.dll.a $INSTALLPREFIX/lib/libssleay32.dll.a &&
cp -f ms/applink.c $INSTALLPREFIX/include/openssl/ &&
echo Success
Here are the steps I did to do the static build of qt-5.15.0:
# location of Python
PY2DIR=/d/Prog/Python/WinPython-64bit-2.7.13.1Zero/python-2.7.13.amd64
# location of all the prerequisites
MINGWPREFIX=/d/Prog/winlibs64-10.1.0/custombuilt
# install destination
INSTALLPREFIX=/d/Prog/winlibs64-10.1.0/custombuilt
# fix missing SHARE_INFO_1 in qtbase/src/corelib/io/qfilesystemengine_win.cpp
echo "#include <levmar.h>" | gcc -E -xc - &> /dev/null && sed -i.bak -e "s/\(#\s*include <\)lm\.h\(>\)/\1levmar.h\2\n\1lmshare.h\2\n\1lmapibuf.h\2/" qtbase/src/corelib/io/qfilesystemengine_win.cpp
# avoid using missing debug ICU libraries in static builds
sed -i.bak -e "s/\(lsicu..\)d/\1/g" qtbase/src/corelib/configure.json
# configure
mkdir -p build_static &&
cd build_static &&
PATH=$PATH:$PY2DIR ../configure -platform win32-g++ -prefix $INSTALLPREFIX/qt -opensource -confirm-license -release -static -no-pch -no-rpath -strip -skip "qtserialbus" -qpa windows -gif -sql-odbc -sql-sqlite -opengl desktop -icu -system-pcre -dbus -system-sqlite -system-zlib -system-libpng -system-libjpeg -system-doubleconversion -system-freetype -system-harfbuzz -libproxy -system-proxies -openssl -openssl-linked -no-xcb -no-compile-examples -skip qtwebengine -nomake examples -system-proxies -plugin-manifests -pkg-config -I $MINGWPREFIX/include/freetype2 -I $MINGWPREFIX/include/mariadb &&
sed -i.bak -e "s/\(-lclang\)\.a/\1 -lpthread/" qttools/src/qdoc/Makefile.* &&
cd .. &&
# build
(
PATH=$PATH:$PY2DIR mingw32-make -Cbuild_static release QMAKE_CXXFLAGS="-fcommon" QMAKE_LFLAGS="-Wl,-allow-multiple-definition" || (
make -Cbuild_static/qttools/src/qdoc &&
PATH=$PATH:$PY2DIR mingw32-make -Cbuild_static release QMAKE_CXXFLAGS="-fcommon" QMAKE_LFLAGS="-Wl,-allow-multiple-definition"
)) &&
# workaround for missing qmake.exe
cp build_static/qtbase/bin/qmake.exe build_static/qtbase/qmake/ &&
make -Cbuild_static install &&
# manually create qt.conf
echo "[Paths]" > $INSTALLPREFIX/qt/bin/qt.conf &&
echo "Prefix=../../qt" >> $INSTALLPREFIX/qt/bin/qt.conf &&
echo Success
I have tested the result by building KeePassXC (https://github.com/keepassxreboot/keepassxc/archive/2.5.4.tar.gz) against it and the resulting package had no Qt DLLs at all and it ran fine.
Related
I am developing a C++ component that uses gRPC and use the following definitions in my bitbase recipe (Yocto dunfell) to build it with CMake:
DEPENDS += "\
grpc \
grpc-native \
...
"
inherit cmake pkgconfig
I included grpc-native to be able to use the protoc compiler to generate stubs and grpc to link my component with the gRPC libraries for the target host.
In my CMakeLists.txt I use the following CMake functions to find the libraries/cpp-plugin
find_package(Protobuf REQUIRED)
find_package(gRPC CONFIG REQUIRED)
find_program(GRPC_CPP_PLUGIN grpc_cpp_plugin REQUIRED)
However, building the recipe fails with the following error:
| CMake Error at /home/jayjay/build-master/build/tmp/work/corei7-64-mbient-linux/mycomponent/git-r0/recipe-sysroot/usr/lib/cmake/grpc/gRPCTargets.cmake:197 (message):
| The imported target "gRPC::grpc_cpp_plugin" references the file
|
| "/home/jayjay/build-master/build/tmp/work/corei7-64-mbient-linux/mycomponent/git-r0/recipe-sysroot/usr/bin/grpc_cpp_plugin"
|
| but this file does not exist.
And it is true, the grpc_cpp_plugin does not exist in this directory, as well as all the other plugins like grpc_node_plugin, grpc_php_plugin, etc. However, these plugins exist in the corresponding "recipe-sysroot-native/usr/bin/" directory, which is correct as they must be compiled for the build-host (rather than the target host), so that they can be used with protoc to generate stubs.
What I do not understand is, that why the existence of these plugin files are checked, although they are not created?
If I remove grpc from DEPENDS then everything works fine, unless the build host architecture is different from the target host architecture (i.e. for cross compiling). In this case I get a linker error "file in wrong format", which is OK, as I used the libraries compiled for the build host (grpc-native) and not the target host.
As a workaround I simply create all required plugin files in the desired directory like so:
do_configure_prepend() {
touch ${STAGING_BINDIR}/grpc_cpp_plugin
touch ${STAGING_BINDIR}/grpc_csharp_plugin
touch ${STAGING_BINDIR}/grpc_node_plugin
...
}
This works, as only the existence of the files is checked. They are not used.
To be able to find the correct location of the directory with the "native" plugins I pass the following extra parameter to CMake:
EXTRA_OECMAKE = "\
-DSTAGING_BINDIR_NATIVE=${STAGING_BINDIR_NATIVE} \
"
Needless to say that this does not feel right.
I do not really grasp what am I doing wrong here (sorry for the long explanation)?
Solution is very simple: use kirkstone
On dunfell, the gRPC recipe does not include https://github.com/grpc/grpc/pull/31525 which I believe fixes the build on Yocto.
So technically you could also just update/patch/make your own gRPC recipe.
I have a workaround for Yocto Gatesgarth and gRPC version 1.24.x.
Basically I symlink the plugin binaries from recipe-sysroot-native/ to recipe-sysroot/ to make the CMake file happy.
Excerpt from my recipe file for a custom software project with CMake and grpc:
DEPENDS += "grpc"
DEPENDS += "grpc-native"
do_configure_prepend() {
ln -f -s ${STAGING_BINDIR_NATIVE}/grpc_cpp_plugin ${STAGING_BINDIR}/grpc_cpp_plugin
ln -f -s ${STAGING_BINDIR_NATIVE}/grpc_csharp_plugin ${STAGING_BINDIR}/grpc_csharp_plugin
ln -f -s ${STAGING_BINDIR_NATIVE}/grpc_node_plugin ${STAGING_BINDIR}/grpc_node_plugin
ln -f -s ${STAGING_BINDIR_NATIVE}/grpc_objective_c_plugin ${STAGING_BINDIR}/grpc_objective_c_plugin
ln -f -s ${STAGING_BINDIR_NATIVE}/grpc_python_plugin ${STAGING_BINDIR}/grpc_python_plugin
ln -f -s ${STAGING_BINDIR_NATIVE}/grpc_ruby_plugin ${STAGING_BINDIR}/grpc_ruby_plugin
ln -f -s ${STAGING_BINDIR_NATIVE}/grpc_php_plugin ${STAGING_BINDIR}/grpc_php_plugin
}
Note that PROBABLY this will no longer work on later gRPC versions, as they seem to have fixed a lot of things regarding cross compilation in gRPC with version 1.35 and above (see oe-core changelog for grpc_*.bb).
Thanks goes out to all these sources!
Yocto Lists
Another Yocto Mailinglist
gRPC Issue on GitHub
gRPC Pull request with one solution
gRPC Pull request with another solution
Edit:
Since I am now on Yocto Honister with gRPC 1.38.1 the situation has changed as follows:
The above workaround is still needed to cross compile a cmake grpc project from within yocto.
However, on the SDK the grpc_cpp_plugin is no longer included in the SDK, thus I cannot cross compile with the SDK outside of yocto. Here is my workaround:
grpc_1.38.1.bbappend
# We need grpc_cpp_plugin and shared libraries enabled
IMAGE_FEATURES += "cpp shared"
# grpc_cpp_plugin native binary is not correctly installed in this version.
# force it to be included in the yocto sdk
FILES:${PN}-native += " ${bindir}"
FILES:${PN}-nativesdk += " ${bindir}"
FILES:${PN}-compiler += " \
${bindir} \
${libdir}/libgrpc_plugin_support${SOLIBS} \
"
IMAGE_FEATURES += "cpp shared"
And inside my image or local.conf:
TOOLCHAIN_TARGET_TASK += "\
grpc-compiler \
"
I am still looking forward to the day I can switch to Yocto Kirkstone ;-)
I've found the lightweight DSP c library - Soundpipe.
I want to use some filters from it. I do not really need binary files, but the problem is that the repository doesn't have its main header file - soundpipe.h. As I understand, this is because the library uses specific modules ported from Csound and FAUST languages. Also the repository's readme doesn't have installation guide for Windows. It says:
By default, Soundpipe needs libsndfile, and a standard build
environment. Other modules that use other external libraries will need
to be explicitly compiled by modifying config.mk (note: but the Makefile's folder doesn't contain config.mk, there is only config.def.mk)
To compile:
make
sudo make install
Ok, I've downloaded and installed libsndfile.
Then I have tried to use MSVC's nmake - it doesn't work:
makefile(7) : fatal error U1036: syntax error : too many names to left of '='
Stop.
Here is the beginning of the makefile:
> .PHONY: all clean install docs bootstrap
>
> default: all
>
> VERSION = 1.5.0
>
> INTERMEDIATES_PREFIX ?= . PREFIX ?= /usr/local
> ...
After that I've downloaded MinGW, mingw32-make result:
config.mk: No such file or directory
mingw32-make: *** No rule to make target 'config.def.mk', needed by 'config.mk'. Stop.
Ok, when I try to run the configure command, it doesn't work on my Win7 x 64 (sh: ./configure: No such file or directory, etc...)
I have the paths in mt system path variable:
C:\MinGW\bin;C:\MinGW\msys\1.0\bin
Links that I've read:
How Do I Run ./configure with MinGW?
Getting mingw-get to install correctly - mingw/msys path missing plus more!
MinGW's configure doesn't work after reinstalling Git for Windows and GCC_TDM too (No idea how to run configure).
Any ideas how to build the library or at least find missing source files (or make through CSound, Faust, ...) ?
The Soundpipe build system is designed to be used with POSIX environments, of which there are a few to choose from on Windows.
I've been able to build Soundpipe using both MSYS2 and Windows Bash on Windows 10.
I'm really eager to start using Google's new Tensorflow library in C++. The website and docs are just really unclear in terms of how to build the project's C++ API and I don't know where to start.
Can someone with more experience help by discovering and sharing a guide to using tensorflow's C++ API?
To get started, you should download the source code from Github, by following the instructions here (you'll need Bazel and a recent version of GCC).
The C++ API (and the backend of the system) is in tensorflow/core. Right now, only the C++ Session interface, and the C API are being supported. You can use either of these to execute TensorFlow graphs that have been built using the Python API and serialized to a GraphDef protocol buffer. There is also an experimental feature for building graphs in C++, but this is currently not quite as full-featured as the Python API (e.g. no support for auto-differentiation at present). You can see an example program that builds a small graph in C++ here.
The second part of the C++ API is the API for adding a new OpKernel, which is the class containing implementations of numerical kernels for CPU and GPU. There are numerous examples of how to build these in tensorflow/core/kernels, as well as a tutorial for adding a new op in C++.
To add to #mrry's post, I put together a tutorial that explains how to load a TensorFlow graph with the C++ API. It's very minimal and should help you understand how all of the pieces fit together. Here's the meat of it:
Requirements:
Bazel installed
Clone TensorFlow repo
Folder structure:
tensorflow/tensorflow/|project name|/
tensorflow/tensorflow/|project name|/|project name|.cc (e.g. https://gist.github.com/jimfleming/4202e529042c401b17b7)
tensorflow/tensorflow/|project name|/BUILD
BUILD:
cc_binary(
name = "<project name>",
srcs = ["<project name>.cc"],
deps = [
"//tensorflow/core:tensorflow",
]
)
Two caveats for which there are probably workarounds:
Right now, building things needs to happen within the TensorFlow repo.
The compiled binary is huge (103MB).
https://medium.com/#jimfleming/loading-a-tensorflow-graph-with-the-c-api-4caaff88463f
If you are thinking into using Tensorflow c++ api on a standalone package you probably will need tensorflow_cc.so ( There is also a c api version tensorflow.so ) to build the c++ version you can use:
bazel build -c opt //tensorflow:libtensorflow_cc.so
Note1: If you want to add intrinsics support you can add this flags as: --copt=-msse4.2 --copt=-mavx
Note2: If you are thinking into using OpenCV on your project as well, there is an issue when using both libs together (tensorflow issue) and you should use --config=monolithic.
After building the library you need to add it to your project.
To do that you can include this paths:
tensorflow
tensorflow/bazel-tensorflow/external/eigen_archive
tensorflow/bazel-tensorflow/external/protobuf_archive/src
tensorflow/bazel-genfiles
And link the library to your project:
tensorflow/bazel-bin/tensorflow/libtensorflow_framework.so (unused if you build with --config=monolithic)
tensorflow/bazel-bin/tensorflow/libtensorflow_cc.so
And when you are building your project you should also specify to your compiler that you are going to use c++11 standards.
Side Note: Paths relative to tensorflow version 1.5 (You may need to check if in your version anything changed).
Also this link helped me a lot into finding all this infos: link
First, after installing protobuf and eigen, you'd like to build Tensorflow:
./configure
bazel build //tensorflow:libtensorflow_cc.so
Then Copy the following include headers and dynamic shared library to /usr/local/lib and /usr/local/include:
mkdir /usr/local/include/tf
cp -r bazel-genfiles/ /usr/local/include/tf/
cp -r tensorflow /usr/local/include/tf/
cp -r third_party /usr/local/include/tf/
cp -r bazel-bin/libtensorflow_cc.so /usr/local/lib/
Lastly, compile using an example:
g++ -std=c++11 -o tf_example \
-I/usr/local/include/tf \
-I/usr/local/include/eigen3 \
-g -Wall -D_DEBUG -Wshadow -Wno-sign-compare -w \
-L/usr/local/lib/libtensorflow_cc \
`pkg-config --cflags --libs protobuf` -ltensorflow_cc tf_example.cpp
One alternative to using Tensorflow C++ API I found is to use cppflow.
It's a lightweight C++ wrapper around Tensorflow C API. You get very small executables and it links against the libtensorflow.so already compiled file. There are also examples of use and you use CMAKE instead of Bazel.
If you wish to avoid both building your projects with Bazel and generating a large binary, I have assembled a repository instructing the usage of the TensorFlow C++ library with CMake. You can find it here. The general ideas are as follows:
Clone the TensorFlow repository.
Add a build rule to tensorflow/BUILD (the provided ones do not include all of the C++ functionality).
Build the TensorFlow shared library.
Install specific versions of Eigen and Protobuf, or add them as external dependencies.
Configure your CMake project to use the TensorFlow library.
If you don't mind using CMake, there is also tensorflow_cc project that builds and installs TF C++ API for you, along with convenient CMake targets you can link against. The project README contains an example and Dockerfiles you can easily follow.
You can use this ShellScript to install (most) of it's dependencies, clone, build, compile and get all the necessary files into ../src/includes folder:
https://github.com/node-tensorflow/node-tensorflow/blob/master/tools/install.sh
If you don't want to build Tensorflow yourself and your operating system is Debian or Ubuntu, you can download prebuilt packages with the Tensorflow C/C++ libraries. This distribution can be used for C/C++ inference with CPU, GPU support is not included:
https://github.com/kecsap/tensorflow_cpp_packaging/releases
There are instructions written how to freeze a checkpoint in Tensorflow (TFLearn) and load this model for inference with the C/C++ API:
https://github.com/kecsap/tensorflow_cpp_packaging/blob/master/README.md
Beware: I am the developer of this Github project.
I use a hack/workaround to avoid having to build the whole TF library myself (which saves both time (it's set up in 3 minutes), disk space, installing dev dependencies, and size of the resulting binary). It's officially unsupported, but works well if you just want to quickly jump in.
Install TF through pip (pip install tensorflow or pip install tensorflow-gpu). Then find its library _pywrap_tensorflow.so (TF 0.* - 1.0) or _pywrap_tensorflow_internal.so (TF 1.1+). In my case (Ubuntu) it's located at /usr/local/lib/python2.7/dist-packages/tensorflow/python/_pywrap_tensorflow.so. Then create a symlink to this library called lib_pywrap_tensorflow.so somewhere where your build system finds it (e.g. /usr/lib/local). The prefix lib is important! You can also give it another lib*.so name - if you call it libtensorflow.so, you may get better compatibility with other programs written to work with TF.
Then create a C++ project as you are used to (CMake, Make, Bazel, whatever you like).
And then you're ready to just link against this library to have TF available for your projects (and you also have to link against python2.7 libraries)! In CMake, you e.g. just add target_link_libraries(target _pywrap_tensorflow python2.7).
The C++ header files are located around this library, e.g. in /usr/local/lib/python2.7/dist-packages/tensorflow/include/.
Once again: this way is officially unsupported and you may run in various issues. The library seems to be statically linked against e.g. protobuf, so you may run in odd link-time or run-time issues. But I am able to load a stored graph, restore the weights and run inference, which is IMO the most wanted functionality in C++.
answers above are good enough to show how to build the library, but how to collect the headers are still tricky. here I share the little script I use to copy the necessary headers.
SOURCE is the first param, which is the tensorflow source(build) direcoty;
DST is the second param, which is the include directory holds the collected headers. (eg. in cmake, include_directories(./collected_headers_here)).
#!/bin/bash
SOURCE=$1
DST=$2
echo "-- target dir is $DST"
echo "-- source dir is $SOURCE"
if [[ -e $DST ]];then
echo "clean $DST"
rm -rf $DST
mkdir $DST
fi
# 1. copy the source code c++ api needs
mkdir -p $DST/tensorflow
cp -r $SOURCE/tensorflow/core $DST/tensorflow
cp -r $SOURCE/tensorflow/cc $DST/tensorflow
cp -r $SOURCE/tensorflow/c $DST/tensorflow
# 2. copy the generated code, put them back to
# the right directories along side the source code
if [[ -e $SOURCE/bazel-genfiles/tensorflow ]];then
prefix="$SOURCE/bazel-genfiles/tensorflow"
from=$(expr $(echo -n $prefix | wc -m) + 1)
# eg. compiled protobuf files
find $SOURCE/bazel-genfiles/tensorflow -type f | while read line;do
#echo "procese file --> $line"
line_len=$(echo -n $line | wc -m)
filename=$(echo $line | rev | cut -d'/' -f1 | rev )
filename_len=$(echo -n $filename | wc -m)
to=$(expr $line_len - $filename_len)
target_dir=$(echo $line | cut -c$from-$to)
#echo "[$filename] copy $line $DST/tensorflow/$target_dir"
cp $line $DST/tensorflow/$target_dir
done
fi
# 3. copy third party files. Why?
# In the tf source code, you can see #include "third_party/...", so you need it
cp -r $SOURCE/third_party $DST
# 4. these headers are enough for me now.
# if your compiler complains missing headers, maybe you can find it in bazel-tensorflow/external
cp -RLf $SOURCE/bazel-tensorflow/external/eigen_archive/Eigen $DST
cp -RLf $SOURCE/bazel-tensorflow/external/eigen_archive/unsupported $DST
cp -RLf $SOURCE/bazel-tensorflow/external/protobuf_archive/src/google $DST
cp -RLf $SOURCE/bazel-tensorflow/external/com_google_absl/absl $DST
Tensorflow itself only provides very basic examples about C++ APIs.
Here is a good resource which includes examples of datasets, rnn, lstm, cnn and more
tensorflow c++ examples
We now provide a pre-built library and a Docker image for easy installation and usage of the TensorFlow C++ API at https://github.com/ika-rwth-aachen/libtensorflow_cc
We provide the pre-built libtensorflow_cc.so including accompanying headers as a one-command-install deb-package.
We provide a pre-built Docker image based on the official TensorFlow Docker image. Our Docker image has both TensorFlow Python and TensorFlow C++ installed.
Try it out yourself by running the example application:
git clone https://github.com/ika-rwth-aachen/libtensorflow_cc.git && \
cd libtensorflow_cc && \
docker run --rm \
--volume $(pwd)/example:/example \
--workdir /example \
rwthika/tensorflow-cc:latest \
./build-and-run.sh
While we currently only support x86_64 machines running Ubuntu, this could easily be extended to other OS and platforms in the future. Except for a some exceptions, all TensorFlow versions from 2.0.0 through 2.9.2 are available, 2.10.0 coming soon.
If you want to use the TensorFlow C++ API to load, inspect, and run saved models and frozen graphs in C++, we suggest that you also check out our helper library tensorflow_cpp.
I am trying to build gSoap binaries with ssl support. I have downloaded the latest gSoap and binaries for WIN32 openssl from this website: http://slproweb.com/products/Win32OpenSSL.html
According to the gSoap documentation, I have to compile using the standard procedure with the DWITH_OPENSSL option enabled. I think the most natural option would be tu use minGW, but I have little experience with this tool. When I try this, (and after applying this patch I am left with two missing libraries a link time: -lssl and -lcrypto.
I guess I have to add a -L option to the compiling directive, but I dont see any libssl or libcrypto (should it be .a or .lib ?) in the openssl lib folder. Must I recompile these too or am I missing something ?
Yes, as I know if you use minGW 1st off install openssl and after that add path + flag like in followed example:
gcc -I/include/
-I/local/include
-L/local/lib
-o download_file download_file.c -llibcurl -lcurl
Here I compile basic C file.
Or if you run ./configure add flags like this:
LDFLAGS+="-L/local/lib -lcurl" LIBS+=-I/local/include ....
Ok I finally made it, here are the different steps I used :
First, I had to rebuild openssl with mingw since the static libraries are not shipped with the binaries shipped by Shining Light Production. I put the openssl folder in c:/openssl/
Then, in stdsoap2.h, I changed line 2247 to :
#if defined(WIN32) && !defined(__MINGW32__)
#define soap_strtoll _strtoi64
#else
# define soap_strtoll strtoll
#endif
#if defined(WIN32) && !defined(__MINGW32__)
# define soap_strtoull _strtoui64
#else
# define soap_strtoull strtoull
#endif
In the configure file:
I removed all occurence of -DWITH_GZIP and -lz.
I added the -lws2_32 linker option (support for winsocket I think)
Those changes in the configure file are in lines 7338-7347 :
WSDL2H_EXTRA_FLAGS="-DWITH_GNUTLS"
WSDL2H_EXTRA_LIBS="-lgnutls -lgcrypt -lgpg-error"
SAMPLE_SSL_LIBS="-lgnutls -lgcrypt -lgpg-error"
WSDL2H_SOAP_CPP_LIB="libgsoapssl++.a"
else
{ echo "$as_me:$LINENO: result: no" >&5
echo "${ECHO_T}no" >&6; }
WSDL2H_EXTRA_FLAGS="-DWITH_OPENSSL"
WSDL2H_EXTRA_LIBS="-lssl -lcrypto -lws2_32"
SAMPLE_SSL_LIBS="-lssl -lcrypto -lws2_32"
I ran configure in mingw adding the proper LDFLAGS and CXXFLAGS, namely :
LDFLAGS+=" -L/c/openssl/ -L/c/MinGW/lib/" CXXFLAGS+=" -I/c/openssl/include/" ./configure
I ran make and crossed my finger!
You can also use a bit more "native" way, ie. Visual Studio C compiler for that. However this is not very straighforward.
First, compiling openssl (valid for VS 2015 Community Edition, but I believe any 2015 will do):
download openssl sources, unzip to some folder
download PERL for windows (either ActivePerl or Straberry Perl - this one is free) and install
open "Open Visual Studio 2015 Tools Command Prompt" from menu start
cd to openssl uncompressed source folder
Run following commands there (this set is using version w/o assembbler):
perl Configure VC-WIN32 no-asm --prefix=c:\some\openssl\dir
ms\do_ms
nmake -f ms\ntdll.mak
nmake -f ms\ntdll.mak test - optional step
nmake -f ms\ntdll.mak install
Afterwards, you get your openssl products installed in c:\some\openssl\dir
Next, to compile gSoap based application with SSL support, you have to add following settings (All settings are done from "Project->Properties" in Visual Studio):
C/C++ --> General, In Additional Include Directories, add "c:\some\openssl\dir\include" folder to the list
C/C++ --> Command Line, in the box "Additional Options", type: /DWITH_OPENSSL
Linker --> Input, Additional Dependencies: add "c:\some\openssl\dir\lib\libeay32.lib" and "c:\some\openssl\dir\lib\sskeay32.lib" to the list
If you have generated your classes using wsdl2h.exe and soapcpp2.exe tools, you are almost done.
Verify, that your stdsoap2.cpp file has those lines:
#include <openssl\ssl.h>
#include <openssl\rsa.h>
If not, you can add them just after first #ifdef WITH_OPENSSL
That was all for mine project. I could compile with VC2015 and run/debug like any other app.
Good luck.
I am attempting to build Google Breakpad for Mac OS X as a part of porting an application, based on the trunk revision 782.
The Breakpad wiki specifies that one should build client/mac/Breakpad.xcodeproj, which produces a Breakpad.framework including a dynamically linked lib if I understand correctly. There is also sample code on how to use this from an Objective-C application, but all this seem very different from what seems to be the normal way of doing things on other platforms, including the use of plists and other things that are not part of my application. I would much rather do things as similar as possible across platforms.
For instance, this appears to be the way that Firefox uses Breakpad:
// include exception_handler.h from client/<platform>/handler,
// using ... here for brevity
#include "... exception_handler.h"
...
gExceptionHandler = new google_breakpad::
ExceptionHandler(tempPath.get(),
nsnull,
MinidumpCallback,
nsnull,
#if defined(XP_WIN32)
google_breakpad::ExceptionHandler::HANDLER_ALL);
#else
true);
#endif
In my project, we are doing the same thing and just link against exception_handler.lib on Windows. It seems that on Linux, Breakpad generates a corresponding libbreakpad_client.a that can be linked against in the same way, but not on Mac OS X. If I do
./configure
make
from the breakpad root directory a libbreakpad.a is generated that does not contain the exception handler, and the libbreakpad_client.a that should is not being built. I may very well have misunderstood just about anything on both the normal way of using Breakpad as well as the normal procedure for building external libraries on the Mac, so any help is appreciated.
How do I build libbreakpad_client.a on Mac OS X?
This might not be helpful in your case, but I've found this to work for a project I'm working on that needs to work on both Linux and OSX. On Linux we use the "normal" autotools way of doing things; on OSX we invoke xcodebuild to create Breakpad.framework and then link against that.
Here's the relevant portion of the CMakeLists.txt file (for CMake see here):
IF(LINUX)
add_custom_target(
GOOGLE_BREAKPAD_MAKEFILE
COMMAND cd ../google-breakpad/ && ([ -e Makefile ] || (autoreconf && bash configure))
)
add_custom_target(
GOOGLE_BREAKPAD
COMMAND cd ../google-breakpad/ && $(MAKE)
)
add_dependencies(GOOGLE_BREAKPAD GOOGLE_BREAKPAD_MAKEFILE)
ENDIF()
IF(APPLE)
add_custom_target(
GOOGLE_BREAKPAD
COMMAND cd ../google-breakpad/src/client/mac/ && xcodebuild -sdk macosx
)
ENDIF()
If your application is built with clang -stdlib=libc++ (which is pretty normal if you make heavy use of C++11), you should append the phrase GCC_VERSION=com.apple.compilers.llvm.clang.1_0 OTHER_CFLAGS=-stdlib=libc++ OTHER_LDFLAGS=-stdlib=libc++ to the end of the xcodebuild line. This will force xcodebuild to do the right thing.
If your application is built with GCC and GNU libstdc++, you don't need to add anything to the xcodebuild line.
There is no solution in the Breakpad source for this, unfortunately. The XCode projects simply build the Breakpad framework, as that's the more-supported client API. You can build the code with your own set of Makefiles or whatever build setup you desire the same way Firefox does by looking at the set of Mozilla makefiles:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/common/Makefile.in
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/common/mac/Makefile.in
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/client/Makefile.in
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/client/mac/handler/Makefile.in
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/client/mac/crash_generation/Makefile.in
and gathering the set of files referenced in CSRCS/CPPSRCS/CMSRCS/CMMSRCS, and building all of those.
You might also file a bug in the Breakpad issue tracker to ask that the XCode project build this static library as well. It would not be a difficult patch.
How do I build libbreakpad_client.a on Mac OS X?
You could only build dynamic framework for macOS Intel64 & Apple Silicon
Checkout https://github.com/Sunbreak/cli-breakpad.trial
Fetch code
mkdir $BREAKPAD && cd $BREAKPAD
fetch breakpad
Setting up and build
cd $BREAKPAD/src
./configure && make
cd $BREAKPAD/src/client/mac && xcodebuild -target Breakpad
cd $BREAKPAD/src/tool/mac/dump_syms && xcodebuild -target dump_syms
Install library && tools
mkdir -p ./breakpad/mac/$(arch)
cp -r $BREAKPAD/src/src/client/mac/build/Release/Breakpad.framework ./breakpad/mac/
cp $BREAKPAD/src/src/tools/mac/dump_syms/build/Release/dump_syms ./breakpad/mac/
cp $BREAKPAD/src/src/processor/minidump_stackwalk ./breakpad/mac/$(arch)
mkdir Frameworks && cd Frameworks && ln -s ../breakpad/mac/Breakpad.framework .