Difference Between Installing a Package from Source and from Compiled Binary

Difference between installing a package from source and from compiled binary

I already provided a somewhat detailed answer in response to this SO question.

As an update, these days you even have lots of packages prebuilt thanks to updated cran2deb initiaives:

• On Ubuntu you now have almost all CRAN packages prebuilt via Michael Rutter's 'cran2deb for ubuntu' ppa on Launchpad.

• For Debian, Don Armstrong now provides a similar service (also covering BioConductor and OmegaHat) at debian-r.debian.net.

What is the difference between binary install and compile and install from source? Which is better?

Source: AKA sourcecode, usually in some sort of tarball or zip file. This is RAW programming language code. You need some sort of compiler (javac for java, gcc for c++, etc.) to create the executable that your computer then runs.

Advantages:

• You can see what the source code is which means....
• You can edit the end result program to behave differently
• Depending on what you're doing, when you compile, you could enable certain optimizations that will work on your machine and ONLY your machine (or one EXACTLY like it). For instance, for some sort of gfx rendering software, you could compile it to enable GPU support, which would increase the rendering speed.
• You can create a version of an application for a different OS/Chipset (see Binary below)

Disadvantages:

• You have to have your compiler installed
• You need to manually install all required libraries, which frequently also need to be compiled (and THEIR libraries need to be installed, etc.) This can easily turn a quick 30-second command into a multi-hour project.
• There are any number of things that could go wrong, and if you're not familiar with what the various errors mean, finding support online could be quite difficult.

Binary: This is the actual program that runs. This is the executable that gets created when you compile from source. They typically have all necessary libraries built into them, or install/deploy them as necessary (depending on how the application was written).

Advantages:

• It's ready-to-run. If you have a binary designed for your processor and operating system, then chances are you can run the program and everything will work the first time.
• Less configuration. You don't have to set up a whole bunch of configuration options to use the program; it just uses a generic default configuration.
• If something goes wrong, it should be a little easier to find help online, since the binary is pre-compiled....other people may be using it, which means you are using the EXACT same program as them, not one optimized for your system.

Disadvantages:

• You can't see/edit the source code, so you can't get optimizations, or tweak it for your specific application. Additionally, you don't really know what the program is going to do, so there could be nasty surprises waiting for you (this is why Antivirus is useful....although LESS necessary on a linux system).
• Your system must be compatible with the Binary. For instance, you can't run a 64-bit application on a 32-bit operating system. You can't run an Intel binary for OS X on an older PowerPC-based G5 Mac.

In summary, which one is "better" is up to you. Only you can decide which one will be necessary for whatever it is you're trying to do. In most cases, using the binary is going to be just fine, and give you the least trouble. Sometimes, though, it is nice to have the source available, if only as documentation.

Difference between Groovy Binary and Source release?

A source release will be compiled on your own machine while a binary release must match your operating system.

source releases are more common on linux systems because linux systems can dramatically vary in cpu, installed library versions, kernelversions and nearly every linux system has a compiler installed.

binary releases are common on ms-windows systems. most windows machines do not have a compiler installed.

Installing loo package in R - source vs binary?

You were two major versions of R behind the current version, and now are only one major version behind (but very soon to again be 2 versions back). CRAN repositories compile binaries for the current version for use by Mac and Windows users in those situations where they will compile successfully on the CRAN installation of those machines. It's possible for packages to not compile on anything except Linux. Some (but not all) of the repositories will then make available older versions of the binary versions of packages. Generally the process of "binarization" is not immediate and it is not unusual for it to take a few days for binaries of updated packages to appear. Do make sure that your repo is up-to-date. The current "Version:" is 0.1.6 although earlier versions are available and appear to have been also requiring R 3.1.2 at least back to version 0.1.3: https://cran.r-project.org/src/contrib/Archive/loo/

My guess (after looking at the package website on GitHub) is that you are just getting a standard message that hints that you might need to specify needing the source package simply because your are not using the current R "major" version. Fortunately for you the 'loo'-package does not need to have any code compiled, so it should succeed even if you do not have the development tools installed for your unstated operating system. So try:

install.packages('loo', dependencies=TRUE, type="source")

Installing packages in R by using binary instead of source files: how to change the default

This question was posted by myself a while ago, but today I randomly found out the potential reason why R was installing packages from sources instead of binary.

I bought a MacBook Pro (2020) m1 apple silicon and tried to install R and RStudio. When I installed R and RStudio using brew, I realized that R tried to install R packages using sources instead of binaries again!

I spent several hours trying to figure this out and then, reinstalled R from cask instead of a Homebrew version! This seemed to solve the problem. Now all packages are installed from binaries.

brew install --cask r

I am not 100% if that was the case when posting the original question. However, I thought the might help whoever facing the same issue can solve the problem by considering this aspect.

Install.packages installs source in Rstudio console but binary when using Rscript

I tried different environment variable configurations to see if installing/compiling from source can be performed by an Rscript.exe instance running install.packages.

(It works differently (less restrictive) when working from Rstudio console. It seems that it recognizes the registry entry. It works without specifying an environment var at all).

1. Set MAKE variable (Sys.setenv(MAKE = 'C:\\Rtools\\bin\\make.exe')) (partially SUCCEEDS)
2. Set PATH variable (appending to the beginning)
   
   
   • Include all Rtools bin dirs (C:\\Rtools\\bin;C:\\Rtools\\mingw_32;C:\\Rtools\\mingw_64) (SUCCEEDS)
   • Include Rtools C:\\Rtools\\bin only (SUCCEEDS)
   • Include Rtools C:\\Rtools\\bin only (to the end of PATH variable) (SUCCEEDS)
   • Include Rtools C:\\Rtools\\mingw_32 only (FAILS)
   • Include Rtools C:\\Rtools\\mingw_64 only (FAILS)
3. Set only the PATH and not the MAKE variable.

Under the condition that the following property is set: options(install.packages.compile.from.source = "always")

Solution 1:

The install.packages function 'checks' if it should try building from source by looking for the 'MAKE' environment variable nzchar(Sys.which(Sys.getenv("MAKE", "make"))). Unfortunately, if you only specify the MAKE environment variable, which you must provide a complete path to make it (the Sys.which) work, it will still not find all required source build tools (Rtools/bin) that appear to be necessary and crash without any clarrification:

> Sys.setenv(MAKE = 'C:\\Rtools\\bin\\make.exe')
> system("Rscript.exe C:\\R_projecten\\test\\install_test.R rlang")

     There is a binary version available but the source version is later:
         binary source needs_compilation
   rlang  0.2.0  0.3.4              TRUE

   installing the *source* package 'rlang'

   Warning messages:
   1: running command '"C:/PROGRA~1/R/R-33~1.1/bin/x64/R" CMD INSTALL -l "C:\R_projecten\test\test4" C:\Users\SB947~1.FRO\AppData\Local\Temp\RtmpwbEcl6/downloaded_packages/rlang_0.3.4.tar.gz' had status 1 
   2: In install.packages(packageName, lib = "C:\\R_projecten\\test\\test4",  :
     installation of package 'rlang' had non-zero exit status

So solution 1 is not sufficient, and can even be replaced by solution 3:

   PATH : C:\Program Files\R\R-3.3.1\bin\x64; ....  ;C:\Rtools\bin; 
   MAKE : 

     There is a binary version available but the source version is later:
         binary source needs_compilation
   rlang  0.2.0  0.3.4              TRUE

   installing the source package 'rlang'

As shown, only providing C:/Rtools/bin in PATH, and no MAKE variable is sufficient.

The check decribed earlier checks if the MAKE variable exists, and use that value, or it will look for make, the program name (provided as default to Sys.getenv). When specifying the PATH only, the make(.exe) file can be found and no MAKE env var is required. With the added benefit of already pointing to the Rtools/bin directory from which apparently more files are needed.

Which files I am still wondering though...

NOTE: The check nzchar(Sys.which(Sys.getenv("MAKE", "make"))) is NOT sufficient to prove that your environment is ready for building from source.

R, install package from source vs. use install.package() and CRAN mirror

You hit an important overall question -- "should I install from a binary repository (where available) or should I install from source" -- but I fear you are a little confused about other aspects:

• You rightly point to the Debian and Ubuntu READMEs. Ubuntu is particularly useful as Michael's (off-CRAN) PPA repos provide about 3200 package that are directly installable as binaries. Nothing is faster.

• But that is for Ubuntu and you run CentOS. No soup for you.

• So source installation it is.

• And source installation is always from a .tar.gz and the various methods you list (command-line, install.packages(), ...) and alternative (Package tab in RStudio, say) are all equivalent as the all call the same underlying function.

It is really just different veneer for convenience.

What is the difference between source and binary distributions of mysql

http://en.wikipedia.org/wiki/MySQL

MySQL is written in C/C++ which are reasonably platform independent - it means a version of MySQL is available for different platforms (versions of operating systems). Binaries are build for different platforms, and you need to download binary version for the platform you have. Windows binary would not work on BSD Unix, etc.

You can see available platforms here: http://dev.mysql.com/downloads/mysql/

Likely with some skills you can build MySQL from sources on many other platforms. Not sure what exactly you want.

If you download source version, you need to have build tools. For example on Windows, you need to install C and C++ compilers and other tools as necessary.

Or you can just download both binaries and sources, and read source for learning experience.

Wikipedia article above has links explaining many more terms, to clear many more of your doubts. :-)

Edit:

C and C++ are considered "platform-independent": they are part of Gnu compiler collection : which provides compilers for many languages ("The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these languages") for many platforms/operating systems. And of course they power all distributions of Linux. See http://en.wikipedia.org/wiki/GNU_Compiler_Collection and http://en.wikipedia.org/wiki/GNU_Project

---

Related Topics