I'm testing clickhouse. Finally I installed ClickHouse on my virtual machine. But I've got some problem to make it.
--> Finished Dependency Resolution
Error: Package: clickhouse-server-1.1.54236-4.el6.x86_64 (clickhouse)
Requires: libbfd-2.20.51.0.2-5.44.el6.so()(64bit)
But, I already have this "binutils-2.20.51.0.2-5.47". (More recent version)
[root#node01 ~]# rpm -qa | grep "binutils"
binutils-2.20.51.0.2-5.47.el6_9.1.x86_64
So, I removed binutils-2.20.51.0.2-5.47 and install binutils-2.20.51.0.2-5.44, it works well.
Is this common issue?
Thanks.
Chan.
The BFD libraries are only intended for internal use by binutils and related tools. There is no ABI stability even within the same release of CentOS (or Red Hat Enterprise Linux). This is why the library name can change from minor release to minor release, breaking RPM dependencies in this way.
You need to talk to whoever builds clickhouse. They need to bundle their own version of BFD if they truly need it, or use supported libraries such as libelf from elfutils if they need only a tiny subset.
Related
I've been trying to build GCC 10.2 on my Intel MBP. As I've always done, I'm building from source and installing on /usr/local. Trouble is no matter what, the build fails on STAGE2 of bootstrapping. A careful search on all logs (including dependencies) could not point to a single fault. The only thing that stood out was the clang setup from Xcode Command Line Tools. When I run 'gcc -v' on a clean system (empty /usr/local), it outputs:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Trouble is that the target for --with-gxx-include-dir doesn't exist! There is no c++ subfolder, to begin with. Although there is one from the --prefix tree, instead of 4.2.1, there is just a v1 subfolder.
It would appear that there is something terribly wrong with Xcode Command Line Tools. But I can't be sure that this is the cause of my own troubles.
Please, don't answer this post pointing me to a package manager... there's a reason I abandoned those years ago. Also, it would be off-topic to the issue at hand.
I've finally managed to isolate the issue. GCC 10.2 depends on GMP, MPFR, MPC, and ISL libraries. I had them manually installed with the latest version available and fine tuned to my system. I didn't explore if it was a version conflict, or a fine tuning issue, but that broke the build. The solution was to let the script 'contrib/download_prerequisites' (within gcc tree) download the appropriate versions that were built along with GCC.
I also found out that the '--with-gxx-include-dir' target is a non-issue. It isn't supposed to point anywhere in my system. It is a reference to the system that built the "gcc" provided by Xcode Command Line Tools.
I'm running Centos 7 and am trying to build hipSYCL (see here)
The issue is that hipSYCL needs to have cmake info from the LLVM build (via the LLVM_DIR cmake variable).
This is problematic for me because building LLVM requires a massive 35Gb for the libraries and exes. I don't have that much memory to spare.
I did find a build of llvm-toolset-8.0 online for Centos 7 and installed it, but to my surprise, that didn't seem to work with LLVM_DIR because there's no cmake files (since I didn't build it locally).
So, my question would be, is there a way to build hipSYCL using pre-built LLVM-clang?
If I'm missing or misunderstanding something, I'd appreciate any help.
LLVM publishes the necessary cmake files, and the binary OS packages I've seen include it, generally in a directory called /usr/lib/llvm*/lib/cmake and in a package called something like llvm-*-dev.
I have some problems following the tutorial "http://wiki.ros.org/Industrial/Tutori...". I have installed ROS Melodic and i want to use an slave ethercat like the "IO rack: EtherCAT Couper, 8 DI, & 8DO (all Beckhoff)" but different brand (Omron), and when i try to follow the step 1: Install OROCOS toolchain for ROS it return a error when i follow the tutorial "http://wiki.ros.org/orocos_toolchain" and execute the command "rosdep install orocos_toolchain" the error is the next: ERROR: Rosdep cannot find all required resources to answer your query Missing resource orocos_toolchain.
I use ROS 1 Distro: melodic SO: Ubuntu 18:04
Someone can i help me, please. I was searching another ways to install OROCOS toolchain but i didn't have success.
Most of the readily available documentation for installing / using Orocos is out of date. For example, that page you were at is (at timeof writing) 6 years old, for an end-of-life distro.
The up-to-date info is on their github and website (The website, for you right now, is probably less useful, but this page still is). Respectively, you should now install that fat stack as sudo apt install ros-melodic-rtt-ros-integration, aka install from binary sources. Make sure to pay careful attention to Building ROS-Based Orocos Components, because they have their own system which changes the CMake process. There's also other packages that they/others keep from other stacks, you can see the whole list by trying to autocomplete apt install ros-melodic-rtt-
apt-get method: I'm trying to install LLVM and Clang on Ubuntu 15.10. I used the commands sudo apt-get install llvm and sudo apt-get install clang. This seemed to have worked, and it only took a few minutes.
Manual method: However, most instructions online have me manually download and build the LLVM and Clang packages (e.g. see here: http://clang.llvm.org/get_started.html). I understand this method could take some time, even a few hours for building LLVM and Clang.
What's the difference between these two methods? Are they equivalent? I just want to make sure I have everything installed correctly. (My background is in Windows, so I'm missing the probably obvious difference.)
apt-get installs already compiled packages from the repository of the distribution. It also takes care of installing all dependencies. The package maintainer has compiled the package and makes sure that it dependencies (other packages and their versions) are met.
This approach is very convenient and should, by all means, be preferred. The only major advantage – or argument in favour – of a source installation is that you get more recent packages.
Compiling from source may be necessary when you want to benefit from features that are not yet available in the distribution’s version. In the case of the compiler it may also be that a newer version produces “better” binaries than an earlier version.
Another reason for choosing to compile software yourself may be that you want to influence the building process, e.g. different compiler settings or a different configuration with less dependencies. However, such cases are quite rare – in most case, it isn’t worth the trouble.
Also, as you’ve experienced yourself, installing a pre-compiled package takes only a few minutes (or even just seconds), while compiling will take some time depending on the software to compile and your hardware.
Bottom line, unless you have a good reason, use the distribution’s package(s).
Z3's dependency on libgmp.so.3 is unresolved in the linux package, leaving the user to provide this library. However, this library is very old and is not readily available.
Does anyone know a method for getting around this issue? I am currently running x86_64 and cannot get around this missing dependency without a great deal of hassle.
Is it possible the linux packages could be fixed such they include the expected library in the distribution?
You can get GMP3 by executing sudo apt install libgmp3-dev.
I'm not a Linux expert, but this is the command I used to install GMP before I compiled Z3.
When I installed the virtual machine for running Linux 64, I think I didn't find a package for the more recent versions of GMP.
I will try again. If it doesn't work, I will download the most recent GMP tar ball and build it from scratch.
BTW, the Z3 for Linux 32 comes with two .so files. One of them has GMP statically linked.
The trick I used for building this .so file didn't work for the 64 bit version.
As I said, I'm not a Linux expert, any suggestions on how to build a better Z3 library for Linux x86_64 users are welcome.