I'm on Ubuntu 22.04 and compiling this C++ Github pull request:
https://github.com/ftexchange/ftx/pull/13
However, the PR contains a compile error.
Somebody posted to fix the error OpenSSL 3.0 devel version must be "removed":
It seems like the compiler was using OpenSSL 3.0 devel version, I had
to remove that
How do I achieve this?
This is what I did on Ubuntu 22.04 LTS.
$ sudo apt install libboost-dev libssl-dev
$ git clone --recursive --branch openssl-1.1 https://github.com/arf-labs-ou/ftx.git
$ cmake -G Ninja -S ftx/cpp -B build -DCMAKE_BUILD_TYPE=Release
$ cmake --build build
Trying to build at this point will trip deprecation warnings when compiling against the system OpenSSL 3. But because ftx has done the extremely inadvisable thing of hard-coding -Werror in their build, this is promoted to a spurious error. Deprecated doesn't mean "won't work today"; it means "upstream must fix". You are not upstream, so this ought not affect you, but, alas, low-quality build code is not a great surprise.
We will hack around this by wrapping the compiler with a shell script that deletes warning flags from the command line. Create a file called no-warnings.sh:
#!/bin/bash
ARGS=()
for arg in "$#"; do
if [[ ! "$arg" =~ ^-W ]]; then
ARGS+=("$arg")
fi
done
"${ARGS[#]}"
Now let's inject it into the build via the CMAKE_CXX_COMPILER_LAUNCHER hook:
$ chmod +x no-warnings.sh
$ rm -rf build
$ cmake -G Ninja -S ftx/cpp/ -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_COMPILER_LAUNCHER=$PWD/no-warnings.sh
$ cmake --build build/
This should work but, unfortunately, even this wasn't enough to build successfully. The code itself has a type error! I wonder if something changed between Boost 1.71 and 1.74. Anyway, I applied the following patch:
diff --git a/cpp/src/util/HTTP.cc b/cpp/src/util/HTTP.cc
index 30e0277..2d043f2 100644
--- a/cpp/src/util/HTTP.cc
+++ b/cpp/src/util/HTTP.cc
## -100,8 +100,8 ## void HTTPSession::authenticate(http::request<http::string_body>& req)
std::string path(req.target());
std::string body(req.body());
- long ts = get_ms_timestamp(current_time()).count();
- std::string data = std::to_string(ts) + method + path;
+ auto ts = std::to_string(get_ms_timestamp(current_time()).count());
+ std::string data = ts + method + path;
if (!body.empty()) {
data += body;
}
And now the above commands produce a successful build. The example programs run and produce reasonable output, as well.
Related
How to compile a C ++ simulation in SimGrid? I am using Ubuntu, following the installation steps in the documentation but when I try to test some example of the documentation itself, there are several errors and warnings.
I went to the examples folder and tried to run some of the S4U interface, but without success.
I tried this: g++ example.cpp -o example
And:
erros and warnings
Build example:
tar xvf simgrid-3.27.tar.gz
cd simgrid-3.27/ && mkdir build && cd build/
cmake ..
make
make tests ## build tests and examples
sudo make install
The make options https://simgrid.org/doc/latest/Installing_SimGrid.html .. ( Ref. https://simgrid.org/doc/latest/index.html ) and simgrid-3.27/docs/source/Installing_SimGrid.rst,
line 342:- make tests: Build the tests and examples.
When the examples have been built, the executable´s are in "build/examples/..". E.g. simgrid-3.27/build/examples/cpp/actor-create/s4u-actor-create
Is there any solution to make compilation with g++-8.2 for the project using Hazelcast C++ client library ?
If I compile it with g++-8.2, it shows a lot of errors "undefined reference ...".
While using g++-4.9, it works well.
The issue is a bit like the discussion in this google group forum, which indicated the compilation errors are because of the wrong version of a compiler.
However, the compiler g++-4.9 is too old for me to build my big project.
The sample code can be found in the official org website, if someone needs to give it a try.
I finally solved it by upgrading the library from 3.10 to 3.11.
The 3.11 library is built manually using g++-8.2 from Hazelcast source code in Github.
Because there is no make install after building hazelcast-cpp-clienet package, so I use some scripts to arrange header files together in one directory (hazelcast-cpp-client/include) so that a program can easily link the library and headers.
Build script:
#!/bin/bash
# Package Requirements:
# - asio
mkdir hazelcast-cpp-client ; cd hazelcast-cpp-client
# Build
git clone https://github.com/hazelcast/hazelcast-cpp-client.git
mv hazelcast-cpp-client tmp
cd tmp
git checkout v3.11
mkdir release ; cd release
cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_BUILD_TYPE=Release ..
make
# Back to 'hazelcast-cpp-client' directory
cd ../..
# Copy .a library out from tmp/
cp tmp/release/*.a .
# Arrange all header files in an one directory
cp -r tmp/hazelcast/include .
cp -r tmp/hazelcast/generated-sources/include/hazelcast/client/protocol ./include/hazelcast/client
rm tmp/external/include/*.md # We don't need readme file
cp -r tmp/external/include/* ./include
# Delete tmp directory
rm -rf tmp
Compilation command is like:
g++ -std=c++11 \
-I/path/to/hazelcast-cpp-client/include \
hz_test.cpp \
/path/to/hazelcast-cpp-client/libHazelcastClient3.11_64.a \
-lpthread
Thanks for reporting this problem. We did not test with the g++-8.2 compiler. I opened an issue to solve the problems: https://github.com/hazelcast/hazelcast-cpp-client/issues/494
Can you tell me also your OS environment? What distribution and version is it?
I just installed gcc-8.1 from source using those steps:
wget https://ftp.gnu.org/gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.gz
tar xvf gcc-8.1.0.tar.gz
cd gcc-8.1.0
apt build-dep gcc
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
$PWD/../gcc-8.1.0/configure --prefix=/usr/bin/gcc-8.1 --enable-languages=c,c++,fortran,go --disable-multilib
make -j8
make install
Everything is correct?
Then I add it to update-alternatives
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8.1 60 --slave /usr/bin/g++ g++ /usr/bin/g++-8.1
There are 3 choices for the alternative gcc (providing /usr/bin/gcc).
Selection Path Priority Status
------------------------------------------------------------
0 /usr/bin/gcc-7 60 auto mode
1 /usr/bin/gcc-5 60 manual mode
* 2 /usr/bin/gcc-7 60 manual mode
3 /usr/bin/gcc-8.1 60 manual mode
Press <enter> to keep the current choice[*], or type selection number: 3
update-alternatives: using /usr/bin/gcc-8.1 to provide /usr/bin/gcc (gcc) in manual mode
update-alternatives: warning: skip creation of /usr/bin/g++ because associated file /usr/bin/g++-8.1 (of link group gcc) doesn't exist
My issue is when I type gcc -v, it said bash: /usr/bin/gcc: Is a directory
--prefix=/usr/bin/gcc-8.1 means that everything that is part of the installation will be placed in the /usr/bin/gcc-8.1/ directory.1
This means that your actual GCC binary is probably located at /usr/bin/gcc-8.1/bin/gcc (or some similarly-named executable, maybe it is actually called gcc-8 or gcc-8.1).
When you set the GCC binary to /usr/bin/gcc-8.1 using update-alternatives, you set the symlink that is normally used to resolve which GCC binary you want to a directory - resulting in the error that you are now getting.
To fix this issue, follow these steps:
Remove the wrong entry in update-alternatives:
update-alternatives --remove gcc /usr/bin/gcc-8.1
Add the right entry.2
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8.1/bin/gcc 60 \
--slave /usr/bin/g++ g++ /usr/bin/gcc-8.1/bin/g++
1 Well, mostly, anyways. Usual prefixes include / (binaries in /bin/), /usr/ (binaries in /usr/bin/) and /usr/local/ (binaries in /usr/local/bin/)
2 I am assuming you want to keep GCC installed at that awkward location. Recompiling and re-installing with --prefix=/opt/gcc-8.1 or something similar would probably be better, just modify the path as needed
This is a double edged sword. I am on windows so don't have the linux jargon. But located my gcc problem in a very wierd way. But maybe this will help someone from hours of digging and trying this and that. But cant say i have not learned a lot in the process.
gcc 10.4 release for windows
and that at least got me to here
Read down to the soundforge link
I'm trying to build the latest clickhouse release (v1.1.54292-stable) in cygwin (mintty-2.7.9) on Windows server 2012 (build 9600).
I've picked and installed these additional packages in cygwin:
automake 10-1
automake 1.15.1-1
cmake 3.6.2.-1
gcc 6.3.0-2
g++ 6.3.0-2
gccmakedep 1.0.3.-1
git 2.14.1-2
libboost_system 1.63.0-1
libmcpp-devel 2.7.2-2
libmysqlclient-devel 10.1.26-1
libpcreposix0 8.40-3
libpoco-devel 1.7.9-1
libpoco-49 1.7.9-1
libtool 2.4.6-5
make 4.2.1-2
mcpp 2.7.2-2
poco 1.7.9-1
python3 3.6.1-1
I'm following the official instructions so I ran:
export THREADS=$(grep -c ^processor /proc/cpuinfo)
export CC=gcc
export CXX=g++
export CMAKE_LEGACY_CYGWIN_WIN32=1
mkdir build
cd build
cmake ..
make -j $THREADS
The compilation error I'm getting is this:
In function ‘CityHash_v1_0_2::uint128 CityHash_v1_0_2::CityMurmur(const char*, size_t, CityHash_v1_0_2::uint128)’:
/home/user/ClickHouse/contrib/libcityhash/src/city.cc:261:3:
error: ‘ssize_t’ was not declared in this scope
ssize_t l = len - 16;
If I grep the /usr/include/sys/types.h for ssize_t it's properly defined there, but for some reason the compiler can't find it.
Thanks for any advice...
I'm getting this error:
OpenCV-2.4.3/modules/features2d/src/freak.cpp:437: error: unable to
find a register to spill in class 'GENERAL_REGS'
After doing:
tar xfj OpenCV-2.4.3.tar.bz2
cd OpenCV-2.4.3
mkdir release
cd release
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_NEW_PYTHON_SUPPORT=ON -D BUILD_EXAMPLES=ON ..
make
The same procedure works on another machine. Any ideas?
You need to dig into the Makefiles to remove -O for freak.cpp.
UPDATE:
This is exactly how one should do it (tested with 2.4.3 and 2.4.4).
you need to edit
YOUR_BUILD_DIR/modules/features2d/CMakeFiles/opencv_features2d.dir/build.make
Search for freak.cpp. You find three blocks: Building CXX..., Preprocessing CXX..., and Compiling CX.... I just needed to change the Building part. The last line of that block looks like this:
.... YOUR_COMPILER $(CXX_DEFINES) $(CXX_FLAGS) ...
and if you check you find out that CXX_FLAGS has a -O3 in it. If you add -O0 after CXX_FLAGS it suppresses the O3. So your lines should look like this.
.... YOUR_COMPILER $(CXX_DEFINES) $(CXX_FLAGS) -O0 ...
This is at least working here!
I struggled with this for quite a few hours as well on my CentOS 5.x boxen, and here's my solution.
It's apparent you need to update 'gcc' but natively upgrading via RPM or just grabbing RPM's at random causing some serious config mgmt issues on your server. I don't have time to compile gcc/g++ via source right now either. After grazing out in the repo for a while, I found that there is, indeed, an 4.x release of gcc in the base repo.
Do this (or someone with 'root' to do it in case of OP who doesn't have access):
# yum install gcc44 gcc44-c++ -y
...CentOS/RHEL have bundled a preview RPM of gcc-4.4.6.
Then when you go to do 'cmake' to build your release environment, do at least the following (your cmake params may vary):
# cd /path/to/OpenCV-2.4.3
# mkdir release && cd release
# env CC=/usr/bin/gcc44 CXX=/usr/bin/g++44 cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/place/to/install/ -D BUILD_PYTHON_SUPPORT=ON /path/to/OpenCV-2.4.3/
That will give you a successful build of OpenCV-2.4.3 natively with CenOS/RHEL 5.x.
Had the same problem and solved it like wisehippy with one slight change:
# yum install gcc44 gcc44-c++ -y
# mkdir release && cd release
# cmake -D CMAKE_BUILD_TYPE=RELEASE -DCMAKE_CXX_COMPILER=/usr/bin/g++44 -DCMAKE_C_COMPILER=/usr/bin/gcc44 <OpenCV_Dir>
I found the problem to be solved once I updated my c++ to point to g++44, instead of the default g++ which was 4.1.
As root verify that the files are the same before doing this step, it may not be necessary for you.
diff /usr/bin/c++ /usr/bin/g++
There should be nothing returned if the files are the same. If this is the case, continue.
Backup your old file. You can delete the file as well because it's the same as g++, but I like to be careful.
mv /usr/bin/c++ /usr/bin/c++4.1
Create a link so that C++ points to your g++44. You could use symbolic link here as well.
ln /usr/bin/g++44 /usr/bin/c++
Done.