> Date: Tue, 6 May 2014 09:44:16 -0700
> From: mtmor...@fhcrc.org
> To: gifi2...@hotmail.com
> Subject: Re: [Bioc-devel] libRblas and libRlapack are broken dependencies for 
> packages in R 3.1.0 on Fedora 20
> 
> On 05/06/2014 09:28 AM, E N wrote:
>>> From: mtmor...@fhcrc.org
>>> To: gifi2...@hotmail.com; bioc-devel@r-project.org
>>> Subject: Re: [Bioc-devel] libRblas and libRlapack are broken dependencies 
>>> for packages in R 3.1.0 on Fedora 20
>>>
>>> Let's focus on preprocessCore, which does not have any additional 
>>> dependencies.
>>>
>>> Also, I assume you mean that you are using R that comes with the fedora 
>>> package
>>> manager, rather than the R that is redistributed by Rstudio.
>>
>> Yes, I'm using the very R packaged by Fedora, this one to be more accurate: 
>> <https://stat.ethz.ch/pipermail/bioc-devel/2014-May/005706.html>
>>
>>
>>>
>>> If you could provide the output of
>>>
>>> R CMD config BLAS_LIBS
>>>
>>> and the full output of
>>>
>>> R -e "library(BiocInstaller); biocLite('preprocessCore')"
>>>
>>> again using the R that is installed with the fedora package manager, then 
>>> that
>>> would help to understand your problem.
>>>
>>> If your problem is only with the version of R distributed by Rstudio, then 
>>> as I
>>> understand it the solution is in the hands of Rstudio, and I am sure they 
>>> will
>>> respond promptly.
>>>
>>> Martin
>>>
>>
>> Please find provided below the commands outputs:
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> [@localhost ...]$ R CMD config BLAS_LIBS
>> -lblas
>>
>> [@localhost ...]$ R -e "library(BiocInstaller); biocLite('preprocessCore')"
>>
>> R version 3.1.0 (2014-04-10) -- "Spring Dance"
>> Copyright (C) 2014 The R Foundation for Statistical Computing
>> Platform: x86_64-redhat-linux-gnu (64-bit)
>>
>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>> You are welcome to redistribute it under certain conditions.
>> Type 'license()' or 'licence()' for distribution details.
>>
>> Natural language support but running in an English locale
>>
>> R is a collaborative project with many contributors.
>> Type 'contributors()' for more information and
>> 'citation()' on how to cite R or R packages in publications.
>>
>> Type 'demo()' for some demos, 'help()' for on-line help, or
>> 'help.start()' for an HTML browser interface to help.
>> Type 'q()' to quit R.
>>
>>> library(BiocInstaller); biocLite('preprocessCore')
>> Bioconductor version 2.14 (BiocInstaller 1.14.2), ?biocLite for help
>> BioC_mirror: http://bioconductor.org
>> Using Bioconductor version 2.14 (BiocInstaller 1.14.2), R version
>> 3.1.0.
>> Installing package(s) 'preprocessCore'
>> trying URL 
>> 'http://bioconductor.org/packages/2.14/bioc/src/contrib/preprocessCore_1.26.0.tar.gz'
>> Content type 'application/x-gzip' length 120387 bytes (117 Kb)
>> opened URL
>> ==================================================
>> downloaded 117 Kb
>>
>> * installing *source* package ‘preprocessCore’ ...
>> checking for gcc... gcc -m64 -std=gnu99
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether we are using the GNU C compiler... yes
>> checking whether gcc -m64 -std=gnu99 accepts -g... yes
>> checking for gcc -m64 -std=gnu99 option to accept ISO C89... none needed
>> checking how to run the C preprocessor... gcc -m64 -std=gnu99 -E
>> checking for library containing pthread_create... -lpthread
>> checking for grep that handles long lines and -e... /usr/bin/grep
>> checking for egrep... /usr/bin/grep -E
>> checking for ANSI C header files... yes
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking for stdlib.h... (cached) yes
>> checking if PTHREAD_STACK_MIN is defined... yes
>> configure: creating ./config.status
>> config.status: creating src/Makevars
>>
>> [...]
>>
>> gcc -m64 -std=gnu99 -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
>> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 
>> -grecord-gcc-switches -m64 -mtune=generic -flto -fpic -Wl,-z,relro -o 
>> preprocessCore.so R_colSummarize.o R_plmd_interfaces.o R_plmr_interfaces.o 
>> R_rlm_interfaces.o R_subColSummarize.o R_subrcModel_interfaces.o avg.o 
>> avg_log.o biweight.o init_package.o lm.o log_avg.o log_median.o 
>> matrix_functions.o median.o median_log.o medianpolish.o plmd.o plmr.o 
>> psi_fns.o qnorm.o rlm.o rlm_anova.o rlm_se.o rma_background4.o rma_common.o 
>> weightedkerneldensity.o -lpthread -llapack -lblas -lgfortran -lm -lquadmath 
>> -L/usr/lib64/R/lib -lR
>>
>> /usr/bin/ld: cannot find -llapack
>> /usr/bin/ld: cannot find -lblas
> 
> This is really about fedora system configuration; R has been built by linking 
> to 
> system-provided lapack and blas, but now R cannot find those libraries. Do 
> they 
> exist ?
> 
> locate liblapack
> locate libblas
> R CMD locate liblapack
> R CMD locate libblas
> 
> if not then there is somehow a missing dependency (on system-provided rather 
> than R-provided lapack and blas) in the fedora R package. Presumably you can 
> work around this by installing the lapack / blas dependency manually (i.e., 
> through the fedora package manager), and getting Tom Callaway to update the 
> dependencies in R-3.1.0-4.fc20.src.rpm (although I see there that 
> bals-devel>= 
> 3.0 is already require'd.
> 
> Partly I am 'shooting in the dark', so if I am missing something please 
> excuse 
> my errors.
> 
> Martin
> 
>>
>> collect2: error: ld returned 1 exit status
>> make: *** [preprocessCore.so] Error 1
>> ERROR: compilation failed for package ‘preprocessCore’
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>>
>> The full compilation output is the enclosed file. Errors come from the way R 
>> was builf for Fedora 20 and the previously mentioned Tom seems to be steady 
>> on the library dependencies management: "This is because we're building R 
>> with the system blas/lapack instead of their bundled copy (something we 
>> should have done a while ago)."
>> ***something we should have done a while ago***
>>
>> Regards,
>> Eric.


[@localhost ~]$ locate liblapack
/usr/lib64/atlas/liblapack.so.3
/usr/lib64/atlas/liblapack.so.3.0

[@localhost ~]$ locate libblas
/usr/lib64/libblas.so.3
/usr/lib64/libblas.so.3.4
/usr/lib64/libblas.so.3.4.2

[@localhost ~]$ R CMD locate liblapack
/usr/lib64/atlas/liblapack.so.3
/usr/lib64/atlas/liblapack.so.3.0

[@localhost ~]$ R CMD locate libblas
/usr/lib64/libblas.so.3
/usr/lib64/libblas.so.3.4
/usr/lib64/libblas.so.3.4.2

R finds its BLAS and LAPACK dependencies, but packages can't. I'm neither a 
system packager nor an R package writer, but from the Tom Callaway's message I 
understood the following:
+prior R-3.1.0 on Fedora, packages could link to BLAS & LAPACK bundled with R 
regardless the system (un)provided similar libraries;
+since that R release, packages can no more search dependencies within R shared 
lib, they ought use the system ones.

Let's reuse 'preprocessCore' as an example. When <grep -nri 'lapack'> is 
applied to its sources, there are outputs for "matrix_functions.c" and 
"matrix_functions.c". Both files carry the following includes:
#include <R_ext/Rdynload.h>
#include <R.h>
#include <Rdefines.h>
#include <Rmath.h>
#include <Rinternals.h>

I suspect the problems stem from there. If I didn't miss Tom Callaway's point 
so far, such includes should be replaced by system's (i.e. Fedora).

Eric.

P.S. I left the whole conversation history in this mail to make it visible on 
the mailing list, which I should have done in my previous messages, sorry for 
my inadvertence.

                                          
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Reply via email to