How to build GRPC with custom BoringSSL symbol prefix? - c++

I need to use in the my application both GRPC (which uses and comes with sources of the BoringSSL) and another third-party library which is tied to OpenSSL, and does not link with BorinSSL. Specifying both of them on the linker arguments leads to some linker errors.
So I've got an idea to build gRPC with custom BoringSSL symbol prefix (and as result do not "shadow" OpenSSL), because I have seen in the standalone BorongSSL build instructions that there is a way to do that ( https://boringssl.googlesource.com/boringssl/+/HEAD/BUILDING.md#building-with-prefixed-symbols ), so I assume this is potentially possible in the GRPC build too.
I am using CMake (and cannot use Bazel). OS: Linux, Windows. Toolchains: VS2017, GCC.
So I've tried to add -DBORINGSSL_PREFIX_SYMBOLS=/path/to/symbols and -DBORINGSSL_PREFIX=my_bssl_prefix on the GRPC cmake command line, but it has finally printed me a warning that these symbols were not used:
CMake Warning:
Manually-specified variables were not used by the project:
BORINGSSL_PREFIX
BORINGSSL_PREFIX_SYMBOLS
If anybody knows, please explain, how to do that correctly.

Related

Ocaml / ReasonML - Missing libraries in built executable

I have an ReasonML project that is using dune build to build an executable. The executable runs on the development machine (where the code is built) without any problems. However, if I copy this exe to my other laptop (Another mac with the same OSX version), I can´t execute the file due to missing libraries:
dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib
Referenced from: /usr/local/bin/foo
Reason: image not found
I´m not very experienced with ocaml / reason but I expected the executable to bundle all necessary dependencies within the binary.
Is there a special build-flag or some other step that I have to perform apart from dune build in order to include all necessary libs?
What you are looking for is statically linking binaries. MacOS unfortunately does not official encourage or recommend static linking. An old page can be found here. You might find this Stackoverflow answer useful as well.
This has less to do with OCaml itself and more wrt how linkers behave on different platforms (MacOS, Linux etc)
To overcome your issue, you could checkout esy-gmp assuming you are using esy as your package manager. If you're on OPAM, you could add conf-gmp to you opam dependencies
All this being said, if you're interested in static linking on supported platform like Linux (and Windows too I guess?), you'll have to provide C linker flags via dune
(link_flags (-ccopt -static))

Custom build cmake using standard library also for project with lower gcc version

I have a custom build cmake v3.10.0 which was compiled with a gcc_4.8.3. I am using this custom build cmake to compile a cmake project that must use gcc _4.1.2 because of legacy code.
Executing cmake promted me with an error because it needs to use the libstdc++-IFX.so.6 provided by gcc_4.8.3 which I fixed by adding the path to the correct library in my LD_LIBRARY_PATH before the path to the libraries provided by gcc_4.1.2.
Compiling my project and linking an executable (which is done by c++) results in the linker taking the gcc_4.8.3 stdlibs over the gcc_4.1.2 libs. Is there any way to tell cmake to not use the libraries it needs for himself for my cmake project preferably without touching LD_LIBRARY_PATH?
Edits:
#squareskittles comment: I did read and try everything this post suggest but without any changes. The libstdc++-IFX.so.6 is still taken from gcc_4.8.3

Cross compiling gRPC using cmake

I'm trying to cross-compile a gRPC using cmake.
I actually managed to do it. Unfortunately my method involves tinkering inside CMakeLists.txt.
Problem was that, when I was trying to compile gRPC it was using protobuffer he just compiled. It cannot run ARM compiled executables on x86 machine.
I managed to compile it by specifying path to protoc and grpc_cpp_plugin manually in gRPCs main CMakeLists.txt. It is dirty and since I would like to include gRPC as submodule I need clean way to do it.
Has anyone managed to cross-compile gRPC using cmake?
This way should work:
Cross-compile Protobuf for target(ARM) and install it.
Make sure that cross-compiled Protobuf can be searched in the toolchain(ARM) you have.
E.g. it is installed into system-default prefix under sysroot.
On host, install Protobuf of the same version. It needn't to be searchable (that is, user-local installation is sufficient).
Cross-compile gRPC with following parameters (set in CMake GUI or as -D option for cmake executable):
gRPC_PROTOBUF_PROVIDER: package
gRPC_PROTOBUF_PACKAGE_TYPE: MODULE
Protobuf_PROTOC_EXECUTABLE: <path to your host protoc executable>
Explanations
Setting parameter gRPC_PROTOBUF_PROVIDER to "package" tells gRPC to not build its own Protobuf, but use already installed variant. This variant is searched by find_package(Protobuf).
Setting parameter gRPC_PROTOBUF_PACKAGE_TYPE to "MODULE" tells gRPC to not use "Config" file, provided by Protobuf installation, for detect Protobuf things (libraries and executable). Config file contains hardcoded paths which cannot be adjusted outside. Instead, FindProtobuf.cmake script is used for find Protobuf.
Setting parameter Protobuf_PROTOC_EXECUTABLE tells FindProtobuf.cmake script to not search Protobuf executable, but takes it from the parameter.

Trying to compile code with references to both protobuffers 2.6.1 and 3.4.1

I am trying to compile a single codebase with references to both protobuffers 3.4.1 and 2.6.1. Now the 2.6.1 variant is globally defined as I am using ubuntu xenial, also:
$ protoc --version
yields:
libprotoc 2.6.1
The requirement for protobuffer version 3.4.1 comes from Google Cartographer (https://github.com/googlecartographer/cartographer) while the requirement for 2.6.1 comes from rotors simulator (https://github.com/ethz-asl/rotors_simulator) as it relies on Gazebo-7 (which uses protobuffer 2.6.1). In order to compile Google Cartographer I have added the binaries (added them in a proto3 folder, see below) to the installation by adapting the CMakeList.txt (see original file here: https://raw.githubusercontent.com/googlecartographer/cartographer/master/CMakeLists.txt) for Google Cartographer by adding the following lines:
set(CMAKE_PREFIX_PATH CMAKE_PREFIX_PATH "${CMAKE_SOURCE_DIR}/proto3")
...
install(DIRECTORY proto3/ DESTINATION .)
So the binaries of the protobuffer 3.4.1 are added to the install folder. I am utilizing catkin-tools (https://catkin-tools.readthedocs.io/en/latest/) to build the whole workspace. Now in a CMakelist.txt for Rotors Simulator I have the following line:
find_package(Protobuf 2.6.1 REQUIRED HINTS "/usr")
But at the moment while trying to compile it does not seem to be able to find the protobuffer 2.4.1 as it returns the following:
Could not find a configuration file for package "Protobuf" that is
compatible with requested version "2.6.1".
The following configuration files were considered but not accepted:
/home/jochem/catkin_ws/install/lib/cmake/protobuf/protobuf-config.cmake,
version: 3.4.1
As a side-note, if I compile the packages separately I am able to compile and install the packages. This is done with the following commands:
catkin build cartographer_ros
and
catkin build rotors_gazebo_plugins
I am at the moment trying to adapt the package of rotors_gazebo_plugins but am so far unsuccessful at making sure the correct protobuffer library is selected, am I missing something by defining references to a local protobuffer version?
You will find it possible to build a single executable that references 2 versions of the same library on mac, quite difficult on windows, and pretty much impossible on unix. This is because the symbol names are not distinct between the two libraries, so if you load both libraries, there is no way to know which library should service which call.
If you are building 2 different executables in one makefile package, then you just need to set the right libraries to load in the link stage. In linux, libraries are usually installed on your system with a version-number suffix, and a symlink that publishes the latest version without the version number. Normally you simply link to the unsuffixed latest version, but in your case, in your link command you will need to explicitly add the suffix.
If you really do need to link this cobble-together into a single executable, on unix you can do a lot with objcopy --redefine-syms to rename all the entrypoints in one of the libraries, and all the references in the dependant code all after compilation, but before linking. Note that the intended end result is that both libraries will run independently and will not be aware of each other.
If you will be able to wrap up at least one of the libs (i.e. either Cartographer or Rotors or both) into a separate shared library, and if the protobuff is only used internally in each of them, you still might be able to use them both in a single executable by building the shared libs with -fvisibility=hidden gcc flag (to switch the default visibility to hide symbols) and only exporting the symbols that are needed (that the app is using) via __attribute__((visibility("default"))).
This way I recall I was able to use two completely different Boost versions in the past, in the same app (by the shared lib not exporting the boost symbols linked in statically).

How to compile Quantlib via Xcode?

I am trying to install QuantLib on my Mac running OSX 10.11.6. Installed Boost 1.59 via MacPorts and then followed these instructions.
I used these additional environment variables
./configure --with-boost-include=/opt/local/include/ \
--with-boost-lib=/opt/local/lib/ --prefix=/opt/local/ \
CXXFLAGS='-O2 -stdlib=libstdc++ -mmacosx-version-min=10.6' \
LDFLAGS='-stdlib=libstdc++ -mmacosx-version-min=10.6'
and then make && sudo make install.
However when I run the Bermuda Swaption test it gave me the same error described here.
Little premise: I don't know anything about C++. I need QuantLib to work on Python. So I read carefully the answer by SmallChess and tried to solve it by myself. As I read in his answer
You can't just compile BermudanSwaption.cpp and hope everything would be fine. You have to compile the entire QuantLib library and link with the generated library files. Please google "compiling and linking C++" for more information.
By far, the easiest way to make it happen on Mac is to do it with Xcode. You will need to create a new Xcode project, and import the entire Quantlib project files into it. Next, you will need to create a main() function. Xcode does the compiling and linking for your automatically.
This is what I exactly did:
created a new project in Xcode (version 8.2.1)(file/new project/Command Line Tool/"HelloWorld"/Documents/create)
selected Targets, Build Phases and Link Binary With Library. Added libQuantLib.0.dylib
set libstdc++(GNUC++ standard library) as C++ Standard Library in Build Settings
Modified Header Search Paths to include: /opt/local/include/, and Library Search Paths to include: /opt/local/lib
C++ Language Dialect is set on Compiler Default.
Dragged the ql folder onto the left window of the Xcode
Now, I managed to copy a simple code which includes the library and even if there are many warnings, it runs. Still when I run on the Terminal the command for the Bermuda Swaption test I get the same error. What am I doing wrong?
Additional info (may or may not be useful): if I change the C++ Standard Library setting on Xcode to libc++, I get on Xcode the same error I get when i try the Bermuda Swaption test (ld: symbol(s) not found for architecture x86_64).
Any help would be very much appreciated
Regards
EDIT: you can find a picture of the code at https://i.stack.imgur.com/1zhjO.png