I have an RPM that requires TBB >= 4, however on aws linux I only have tbb 2.x. I have compiled tbb 4.3 from source and places the files in /usr/include/tbb & /usr/include/serial/tbb.
If I now manually try to install with rpm -ivh, the install fails with a message
error: Failed dependencies:
tbb >= 4 is needed by xxx.rpm
So how can I tell the install that the new version is available in /usr/include/tbb?
thx Art
If you are installing an RPM that requires TTB >= 4, then presumably there exists in the same source a necessary version of TBB. Otherwise, it sounds like you are trying to mix and match RPMs from different sources in ways that are almost guaranteed to cause problems.
You need to either (a) install a package that contains the necessary dependency information to satisfy TBB version requirement, or (b) you need to install everything from source instead of a single dependency.
While you could build a package yourself satisfying (a), the fact that you have an rpm with this requirement suggests that such a package already exists.
Trying to combine the two practices (install from package vs. install from source) is only going to cause sadness and doom.
Related
I'm trying to install the accelerate library from hackage, but it keeps giving me an error saying that my version of base package (4.15.1.0) is too new. Is there a way to force it to ignore the base package that's installed as a system-wide package, and instead download the correct version of the base package?
I'm using Manjaro Linux, ghc version 9.0.2, and cabal version 3.4.0.0. I can't seem to find any documentation on how to force it to ignore a system package. I've tried searching on https://cabal.readthedocs.io/en/3.6/ , but it doesn't seem to mention it anywhere.
The base package is always hard-fixed to the compiler version. The only way to switch base is to switch to a different GHC. That's easier with Stack than it is with Cabal-install – just select a snapshot that has a suitable base version (lts-18.24 would do), and Stack will automatically install the corresponding compiler.
But it could well be that you can actually use base-4.15, and just accelerate has conservative dependency bounds. Try installing it with --allow-newer=base. If that works, give the maintainers a PR that the version bounds can be relaxed.
In Debian Jessie/8 there is GCC 4.9.2.
I need the latest version, GCC 6.x.
Is it possible to install it through Synaptic from the testing repository (i.e. the binary, not the source), in parallel with the old version?
Is there a risk of conflicts among libraries/headers/... Are they going to be stored in separate directories like gcc-4.9/ gcc-6.0/ ...?
So far, I have only been able to install a second compiler building it from source, in its own directory.
Yes sure.
If two packages conflict (e.g. because they contain the same file), then he package manager (apt, aptitude, synaptics, ...) will refuse to install both at the same time.
So you can install any packages in parallel, as long as the package manager allows you to.
E.g. on my system, I have installed both gcc-5 and gcc-6.
Technically, the Conflict is expressed explicitely by the maintainer of a package.
Obviously they cannot track all possible packages in the world, but instead really concentrate on the target release (e.g. packages from jessie properly conflict with other packages from jessie, but not necessarily with packages from woody (aka Debian GNU/Linux 3.0)).
Since upgrading between consecutive releases (e.g. jessie -> stretch) is considered crucial, you can also rely on proper Conflicts when installing testing (aka next-to-be-stable) packages on stable systems.
OTOH, there might of course be bugs in the packaging, where the Conflicts are not properly expressed (if you find one, don't hesitate to report it).
If this happens to happen, the installation will fail, and you can revert the change.
So it's pretty safe to try to install whatever packages are available in Debian.
(However, I wouldn't put that much trust into 3rd party repositories)
I am in the process of moving my programming from mac to the linux distrubution OpenSuse Leap.
therefor i want to install the c++ libraries which i used on my mac on my new machine, this is done through YaST (yet another setup tool)'s software manager, through which i have succesfully been able to install multiple libraries.
I am having problems installing GLFW3, i would prefer to install the latest version (3.2), but at the very least the version must be greater than 3
under YaST's software manager i can however only find something named GLFW2 - however it claims to be version 2.7.6-3.2-x86_64 and to have the build time Fri 11 Sep 2015, and i am not sure if i should regard the fact that it is quite recently build and that the current version (3.2) is in the supposed version of this as a proof that it is indeed GLFW version 3.2 - with some backward compatibillity, or if i should regard the fact that the library is named GLFW2 as a proof that is is not GLFW3.
I have attempted to make and compile dummy programs (which are totally empty programs which tries to include GLFW3) but they fail to compile, claiming that library GLFW3 doesn't exist, but i can not know wether or not they fail because GLFW3 is not installed, or because it is installed but I don't know how to include it.
My question is therefor: if i install the library named GLFW2 through YaST, can i then safely assume that i have GLFW 3.2 installed and that i therefor only need learn to include and compile the library; if no, does that mean i can't install a version of GLFW higher than 3
I have just the same problem today using OpenSUSE, and ended up installing GLFW3.2 from source. In order to get the glfw compiled from sources on OpenSUSE, I also needed to install the following dependencies (using zypper install package_name_to_install):
1) libXrandr-devel
2) libXinerama-devel
3) libXcursor-devel
After the dependencies are installed, I just followed standard cmake flow:
1) git clone git#github.com:glfw/glfw.git
2) cd glfw && mkdir build && cd build && cmake ..
3) make
4) sudo make install
1) What is the difference between installing apache from "yum install httpd" and "source" ?
2) Why both installation methods create different path for httpd.conf file?
3) Are we doing source installations for specific requirements?
Installation from Source:
tar xvfz httpd-2.2.17.tar.gz --> ./configure --enable-ssl --enable-so --> make --> make install
Installation using YUM:
yum instll httpd
Please help me.
Thanks in advance
-Shishir
1) What is the differnce between installing apache from "yum install
httpd" and "source" ?
Installing distributor-provided package (eg. by yum) means installing precompiled, almost-ready-to-use binary version of application, whereas installation by source means building application from source, which involves compiling program source code into binary code.
Most notable differences are:
Building from source provides more flexibility - often applications can be configured to be built with different features. For example, you can decide whether you want to build Apache with support for SSL and whether you want to include support for PHP scripting and so on. On the other hand, binary packages are sometimes split into several packages, for example Apache modules (such as mod_php) can be installed as separate modules.
Installing from source is usually much more time consuming while installing binary package involves mainly copying files and running installation scripts.
Most often, latest versions of applications are provided in source form only - there is time gap before application is packaged and made available in repositories. On the other hand, application installed from repository will be automatically updated by package manager, while applications installed from source will have to be updated manually.
Installing binary packages need only package manager, whareas installing from source required working toolchain, mostly make, compilers (eg. gcc) and development version of third-party libraries.
Package manager handles dependencies for you. For example, Apache needs libapr, Apache Portable Runtime. When you install Apache using package manager, it installs libapr automatically for you. When you build from source, you have to install libapr first.
2) Why both installation methods create different path for httpd.conf
file?
Because different distributions have different guidelines for filesystem layout. RedHat packages follow RedHat guidelines, Debian packages follow Debian guidelines.
Source packages follow some "generic" guidelines.
3) Are we doing source installations for specific requirements?
That may be one reason for doing so. See point 1.
I have a project that runs on Debian and uses many packages provided from the Debian repositories.
Because of demand, I've looked into porting the project to CentOS, but found that many of the packages I require are completely missing - at least 10 dependencies would have to be compiled manually at install time on the users machine.
My question is, what is the best way to create an installer for the user's machine? Should I use automake tools (with the standard ./configure, make, make install), to compile the required libraries, or is this a non-standard approach. Note that my app doesn't actually need to be compiled since it is written in Python, so is it weird to do a "make", when you're not compiling your own app?
Should the configure script just warn the user that package X is missing, and let them handle the rest?
Should I roll my own dependency checker by runng pkg-config manually a few times for each library required, and exit if something is missing?
I'm quite new to this, so any tips to get me moving in the right direction are appreciated.
Edit: I am familiar with RPM and yum for red hat base distros, but CentOS is missing many multimedia packages that I require. An example of one of my package dependencies is "liquidsoap" which is a programmable audio engine: http://savonet.sourceforge.net/
This is available on Debian, but not Redhat/Centos
See this link on CentOS package management.
http://wiki.centos.org/PackageManagement/Yum
CentOS is redhat based and does not use .deb packages by default. However apt package management has been ported to tons of platforms, you may be able to use a port for centOS
If you use YUM whatever packages you need will be there for your application as redhat distros need all the same things that any other distro does.
EDIT: To get the details out of comments
Packages not available on the target platform either have to be built (possibly as a port) on the target platform and then shipped in the ported package (in this case YUM), or code needs to be modified and forked to use packages which already are available on the target platform. The choice depends on which is worse, or which is even possible given your constraints.