Red Hat Bugzilla – Bug 189734
netcdf packaging with netcdf-3 subdirectory blocks use of netcdf
Last modified: 2007-11-30 17:11:31 EST
Description of problem: The netcdf spec file inserts "netcdf-3" into the install path, claiming this will allow peaceful co-existance with netcdf version 4. However, the programs we have that want to use netcdf cannot compile because the netcdf headers and libraries are not under /usr/include and /usr/lib in the way that programs expect. Version-Release number of selected component (if applicable): How reproducible: Install R, and then run "install.packages("RNetCDF") and you will see the compile fail because it cannot understand the way you have packaged the netcdf files. Steps to Reproduce: 1. yum install R 2. Open terminal, su to root, then type R 3. At the prompt, type > install.packages("RNetCDF") In X, it will ask you to choose a web server from a list. In console, it will ask you to type in a number of a web server. I like 57, personally. Actual results: Compile fails: > install.packages("RNetCDF") --- Please select a CRAN mirror for use in this session --- Loading Tcl/Tk interface ... done trying URL 'http://lib.stat.cmu.edu/R/CRAN/src/contrib/RNetCDF_1.1-3.tar.gz' Content type 'application/x-gzip' length 50504 bytes opened URL ================================================== downloaded 49Kb * Installing *source* package 'RNetCDF' ... checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for executable suffix... checking for object suffix... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for main in -lnetcdf... no configure: error: netcdf library not found ERROR: configuration failed for package 'RNetCDF' ** Removing '/usr/lib/R/library/RNetCDF' Expected results: I've rebuilt the netcdf RPM after changing the spec file to remove the "special" re-location of the files and after that the compile works fine. Additional info:
Executive Summary: This is not a netCDF bug. Its either a failure of the build system for this particular software or its a symptom of your failure to properly build it (eg. specify the necessary include and/or library paths). Please find someone who can help you with the configuration. Longer Explanation: There are literally *dozens* of -devel packages that install their headers in subdirs such as /usr/include/${SOME_PKG}/ and/or their development libraries (esp. static libs) in /usr/lib/${SOME_PKG}/. But please don't take my word for it--go *look* for yourself. Install a number of -devel packages on one of your systems and then take a peek in /usr/include and /usr/lib and see what you come across. So, why are things done this way? We don't we just dump everything in /usr/include and /usr/lib and not have any subdirectories whatsoever? It turns out that there are good reasons. And most of these reasons boil down to namespace pollution. By separating the files into sub- directories we can have a system with side-by-side installs of, for instance, multiple packages that export the same API using identically- named headers. And thats just one example. What is lost by having these subdirectories? In practical terms we loose nothing. This is so because almost every build system on this planet supports one (and typically multiple) mechanisms that allow for the specification of additional include and/or library paths. And the very few build systems that don't allow for user-selectable additional paths are rare indeed (and, by definition, are poorly written). In those unlikely circumstances, the offending build systems can be either be worked around or fixed (patched). Now, instead of trying to un-do the work that has already gone into packaging netcdf (and, because of the dependencies, nco, ncview, cdo, hdf5, etc.), please direct your effort towards the config/build system for your R package. If you contact me personally, I'll be happy to help you with it. Or, you could ask for packaging help on the Fedora Extras list: https://www.redhat.com/mailman/listinfo/fedora-extras-list where some folks already maintain R and various R add-on packages. Looking at the R-RScaLAPACK spec-file in Extras I see that its easy to set additional paths within the R configuration and build system. Heres the corresponding command for R-RScaLAPACK: %{_bindir}/R CMD INSTALL --configure-args="CFLAGS='$RPM_OPT_FLAGS -I%{_includedir}/lam/ -L%{lamdir} -lutil -lmpiblacsCinit -lmpiblacs -llam -llamf77mpi -lmpi -llapack' FFLAGS='$RPM_OPT_FLAGS -I%{_includedir}/lam/ -L%{lamdir} -lutil -llapack'" -l $RPM_BUILD_ROOT%{_libdir}/R/library %{packname} and notice how it sets include/library paths, library names, etc.