I have downloaded openmpi from
http://pkgs.org/centos-6-rhel-6/centos-rhel-x86_64/openmpi-1.5.4-1.el6.x86_64.rpm.html
And I have installed using rpm -i openmpi-1.5.4-1.el6.x86_64.rpm.
mpicc & mpif77 are not generated. How to generate those binaries.
Can anyone help me.
Thank you
openmpi-1.5.4-1.el6.x86_64.rpm is the run-time portion of Open MPI. The compiler wrappers are part of the development package openmpi-devel-1.5.4-1.el6.x86_64.rpm. This is also true for most libraries with RPM- and Debian-based Linux distributions (e.g. RHEL, CentOS, SuSE, Ubuntu, etc.) - the libraries are distributed as separate run-time and development versions. With Debian-based distributions the development package usually has the -dev suffix in its name.
The reason for that is that one often doesn't need all the development files if the library is only needed so that executables, linked against it, are to be run.
Related
We have established a simple local CRAN-like repository for R packages. There are many users, all of which use the same version of Linux.
Is there a way of convincing R to provide pre-compiled Linux packages instead just source ones? The compilation step takes a considerable amount of time for anyone using our repository. It should be possible to precompile and reuse the same binaries, since we can guarantee that the Linux version is consistent for all users.
How could one hack something like this together?
In the very narrow sense of "all of which use the same version of Linux" you actually have an option (that happens to be relatively littler known). Create binary packages using e.g.
R CMD INSTALL --build nameOfDirectoryWithSources
As R CMD INSTALL --help says it
--build build binaries of the installed package(s)
and these are not .deb or .rpm alike packages: no dependency information or alike is added. But they do exactly what you ask for: save on compilation time.
I am not aware of a repository structure one can build of this though.
When I install.package() in R on a Windows machine, the package downloads from CRAN and installs. When I do the same on a Linux box, the package usually has to compile (at least, I assume that's what going with all those g++ lines that scroll past).
Why is the package installation method different on Windows?
Other questions and their answers make it clear that using different methods and repositories for Linux particularly, enables users to get more/different packages (particularly using the cran2deb repository). My question is more theoretical in nature: why is the default choice in Windows to download precompiled (binary?) packages whereas the default in Linux seems to be to compile packages from source?
Or to put it another way (based on Dirk's assertion in the second link above), why doesn't CRAN offer binary packages for Unix-type operating systems?
In general, Windows binaries will work on all versions of Windows.
Ditto for the key / current versions of MacOS: the provided binaries work.
Linux, sadly, is more complicated because the different distros lay things out differently. Something I build on Ubuntu or Debian (or, more specifically, a particular release version thereof) may not even work on other releases of the same distro, let alone other distro. In some cases you can get binaries. At some point I (co-)owned a build service for all of CRAN, but it died/broke. All doable with effort, but ... some effort.
So from source it is. That use to be the standard anyway which "Unix" was a catch-all phrase covering SunOS/Solaris, AIX, *BSD, SGI and on and on. Often even with different processors. So source.
There have been attempts to provide 'universal binaries': flatpack and snap are two more recent examples. And then there is of course Docker.
I want to convert certain R packages (which have been installed under windows) for linux usage, then I can simply upload these R package to the linux server, and therefore it is not necessary to install these R packages again under linux environment.
I wonder that is it doable?
Most likely not. Many are precompiled binaries for windows, but need to be compiled in linux. Especially those packages that contain compiled code (such as C or C++), these need to be compiled on the target platform so that they are linked to that platform's libraries.
If the issue is the time it takes to maintain a set of packages, one thing you can do is create your own utilities package, which imports all of the packages you would want. Then, if you install your utilities package, it will automatically install all of the others.
I want to deploy my app cross platform for linux i am confused,
Should i build separate packages for Redhat and Debian or use an installer script like Qt Installer Framework
It depends on your exact desire, but ideally, you could do both.
Rpms, debs, and similar packages for other distributions are easier to obtain and install.
However, sometimes it takes the distrubtion a while to get your software into their package repositories. In those cases, having an installer like Qt does comes handy.
I am developing a framework for reproducible computing with R. One problem that I am struggling with is that some R code might run perfectly in version X.Y-Z of a package, but then why you try to reproduce it 3 years later, the packages have updated, some functions are changed, and the code doesn't run anymore. This problem affects also for example Sweave documents that use packages.
The only way to confidently reproduce the results is by installing the R version and version of the packages that were used by the original author. If this was a single case, one could pull stuff from the CRAN archives and install appropriate versions. But for my framework this is impractical, and I need to have the package versions preinstalled.
Assume for now that I restrict myself to a single version of R, e.g. 2.14. What would be a practical way to install many versions of R packages, so that I can load them on the fly? I suppose I can do something like creating separate library directories for every version of every package and then using custom lib.loc arguments while loading them. This is going to be messy though. Any tips or previous attempts to do something similar?
My framework runs on Ubuntu server.
You could install packages with versions (e.g. rename to foo_1.0 directory instead of foo) and softlink the versions you want to re-create a given R + packages snapshot into one library. Obviously, the packages could actually live in a separate tree, so you could have library.projectX/foo -> library.all/foo/1.0.
The operating system gives you even more handles for complete separation, and the Debian / Ubuntu stack as a ton of those available. Two I have played with are
chroot environments: We use this to complete separate build environments from host machines. For example, all Debian uploads I produced are built in a i386 pbuilder chroot hosted on my amd64 Ubuntu server. Chroot is a very powerful Unix system call. Chroots, and particularly the pbuilder system built on top of it (for Debian package building) are meant to operate headless.
Virtual machines: This gives you full generality. My not-so-powerful box easily handles three virtual machines: Debian i386, Ubuntu i386 as well as Windoze XP. For this, I currently use KVM along with libvirt; this is Linux specific. I have also used VirtualBox and VMware in the past.
I would try to modify the DESCRIPTION file, and change the field "Package" there by adding the version number.
For example, you download the package source a from CRAN page (http://cran.r-project.org/web/packages/pls/). Unpack the compressed file (pls_2.3-0.zip) to a directory ("pls/"). The following steps are to change the package name in DESCRIPTION ("pls/DESCRIPTION") and installation with R command 'R CMD INSTALL pls/', where 'pls/' is a path to the package source with modified DESCRIPTION file.
Playing with R library paths seems a dangerous thing to me.