[BioC] Tiger, R, Bioconductor

[Cyrus Harmon]

Hi Robert,

Sorry for the lack of specifics. More details follow:

On May 6, 2005, at 3:06 PM, Robert Gentleman wrote:

> Please always provide information on the version of R, and the  
> package versions - it is important for us in trying to help.

All of this pertains to r-devel (2.2.0 prerelease) from today's SVN  
sources. Perhaps I'm too far out on the bleeding edge to get things  
working properly with BioC, but I'd like to help get the latest R- 
devel release and develOK versions of BioC packages working properly  
on Tiger.

>> 1. gcrma can't seem to find the R framework (granted, this is  
>> installed in a non-standard location, but other packages seem to  
>> be able to do this fine)
> Can you be a bit more precise? What is the error message exactly?

I don't have the precise error message, but the problem was that I  
had installed the R framework in a non-standard location and the - 
framework R option in LIBR wasn't sufficient to find the framework.  
I've since reported this to R-SIG-MAC as this is a general R problem,  
not a bioconductor problem. The solution is to include a -F<path to  
the directory where the framework is installed> option in the LIBR  
line in Makeconf. I've done this by hand and now I can build things  
like gcrma. Some autoconf magic that is a bit over my head is  
presumably required to do this properly.


>> 2. SparseM doesn't seem to like the gfortran compiler.
>
>   That is really an issue for the maintainer of SparseM. We don't  
> have the right to just start changing their code on them. Have you  
> reported this, with complete output, to them? In my experience they  
> are very receptive and quick to fix problems.

Thanks. It wasn't obvious to me that SparseM wasn't part of  
Bioconductor (I'm using (trying to use it) it because gostats (I  
think) wants it). I've also backed down to the f77 compiler which  
avoids the problem for the moment.


>> 3. affyPLM has a log2 function which conflicts with the defintion  
>> in math.h. In particular, the LESN.c version is declared static  
>> and the math.h one isn't. GCC 4 chokes on this.
>     This one should be fixable in the short term. We will see what  
> we can do.

Great. I'm not sure if the solution is to call the systems log2 or to  
rename the LESN.c log2 function, but it looks like this is a name  
collision in a language that doesn't have good namespace support.  
Thanks for addressing this.


>   Again, thanks for the report - we will see what we can do

Thank you for the prompt response and for pointing me in the proper  
directions!

Sincerely,

Cyrus