[R] RODBC installation: error message

[Marc Schwartz]

Hi Gregory,

See below.

On Jan 5, 2012, at 4:20 PM, gregory benison wrote:

>> As Duncan noted, the message is pretty clear in that the ODBC header files are missing, which are required to compile RODBC from source. On RH based Linuxen, this requires the installation of the unixODBC-devel RPM, much as one would need to have other *-devel RPMs (eg. readline-devel) installed for compiling many applications from source.
>> 
> 
> Since a lot of R users may not be familiar with these header files, I
> think the configure script could go a step further in explaining why
> it was looking for these headers (to find an installed ODBC driver
> manager), and that it didn't find one.  To illustrate what I mean,
> here is the result of running R CMD INSTALL on a system lacking an
> installed dsm where I swapped the order of the tests in configure.ac
> (see patch below) such that the library tests come before the header
> tests:
> 
>> * installing *source* package 'RODBC' ...
>> checking for library containing SQLTables... no
>> configure: error: "no ODBC driver manager found"
>> ERROR: configuration failed for package 'RODBC'
> 
> To me, that is a more helpful error message, because it makes it clear
> that you need to install an ODBC driver manager.

<snipped other content>

To split hairs, there are two issues at play here, irrespective of the ordering of the tests:

1. If you do not have unixODBC installed, you will get an error message regarding a missing ODBC driver manager, if as you have done here, that test is first rather than second.

2. If you have unixODBC installed (so you pass the first test in your scenario), but do not have the 'devel' part, which is a separate install on most Linuxen with package managers (RHEL/CentOS, Fedora, Debian and derivatives like Ubuntu and Mint, etc.), you will still get the error message regarding the missing header files. That is an entirely different error than missing the actual ODBC driver manager.

So you can argue about the ordering of the tests, but the end result is the same. Only if you have some knowledge about compiling source code (on ANY operating system), will you understand the meaning of missing header files AND only if you have some lower level knowledge of development on Linuxen specifically, will you know that the header files are contained in a separate binary package that needs to be installed as well, the details of which will be specific to the Linux distribution that you have chosen to install.

On top of that, if as with most Linuxen today, you don't have the software development packages installed (you are a naive user of Linux and only did a default install of the distribution), you won't have compilers and other associated tools (eg. make, etc.) installed either. At some point, the user has to be responsible for obtaining the requisite knowledge of their operating system, independent of the use of R. Despite the protestations by some on the web that their grandmothers are running Linux, it is still largely a geek's platform (with a 1% to 1.5% marketshare on the desktop) and due to the marketplace fragmentation of the plethora of distributions and desktop environments, further requires distribution and even version specific knowledge as well.

As I noted earlier, if you are going to use Linux, you are generally going to be expected to have a more technical level of knowledge than somebody who is running Windows or OSX, where for the most part, one can install pre-compiled binary packages from CRAN, thanks in large measure to folks like Kurt, Uwe, Duncan, Simon and Prof. Ripley (I may be missing others) who have taken the time over the years to put the testing and build infrastructure in place to automate much of that process.

Since there are over 3,500 packages on CRAN and some proportion (I don't know the number) have C/C++ and/or FORTRAN code in them, which will require compilation when installing source packages using either install.packages() or R CMD INSTALL on Linuxen, addressing RODBC in isolation is ultimately not helpful, since like most CRAN packages, it has a finite audience of users (me being very thankful to Prof. Ripley to be one of them).

I cannot speak for Prof. Ripley here, but since you seem to have the requisite skills, he may be open to accepting a patch against his package that would narrowly address the issue that you raise.

However, that does not change the defacto behavior for all of the other CRAN packages that will have similar requirements when being installed from source and will, as is the case with Linux generally, output relatively terse error messages when faced with these kinds of issues.

Also as Duncan noted, perhaps there may be a better mechanism in gaining access to install time requirements for CRAN packages. In the case of RODBC, Prof. Ripley has taken the time to create a vignette which covers much of this material. That is directly available from the CRAN page for the package, without having to successfully install or download the source package itself:

  http://cran.r-project.org/web/packages/RODBC/vignettes/RODBC.pdf

In other cases, such as with my WriteXLS package, I included an INSTALL file, which is also available separately from the CRAN page for the package:

  http://cran.r-project.org/web/packages/WriteXLS/INSTALL

In both cases, useRs need to know to look for that information, albeit not every CRAN package has such supplemental materials available. That is up to the package authors/maintainers.

The R Installation and Administration manual, which you initially referenced, can provide only very generic guidance for the installation of CRAN packages, since each of the over 3,500 packages may have very specific requirements beyond just the basic installation of a package that only contains R code and has no dependencies on third party tools. Some of the packages may even be OS specific (for example, BRugs, which is going to be problematic on Linux and OSX without a Windows VM or Wine, due to the requirements of OpenBUGS). This is why you are directed in the R Posting Guide to contact the package maintainer when faced with issues pertaining to a specific package alone or perhaps to one of the special interest lists, which in this case, for example, would be r-sig-db.

Regards,

Marc Schwartz