<p><br>
On Jun 6, 2011 4:17 AM, "baptiste auguie" <<a href="mailto:baptiste.auguie@googlemail.com" target="_blank">baptiste.auguie@googlemail.com</a>> wrote:<br>
><br>
> Thank you for the explanations below.<br>
><br>
> On 5 June 2011 10:40, Dirk Eddelbuettel <<a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a>> wrote:<br>
> ><br>
> > On 5 June 2011 at 10:12, baptiste auguie wrote:<br>
> > | Hi Dirk and all,<br>
> > |<br>
> > | On 4 June 2011 12:04, Dirk Eddelbuettel <<a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a>> wrote:<br>
> > | ><br>
> > | > Baptiste,<br>
> > | ><br>
> > | > On 4 June 2011 at 11:45, baptiste auguie wrote:<br>
> > | > | Dear list,<br>
> > | > |<br>
> > | > | My package cda, which I was hoping to release on CRAN, fails to<br>
> > | > | compile on R-forge with error,<br>
> > | > |<br>
> > | > | ** testing if installed package can be loaded<br>
> > | > | Error in dyn.load(file, DLLpath = DLLpath, ...) :<br>
> > | > | unable to load shared object '/tmp/RtmpbztUMm/Rinst1829c04c/cda/libs/cda.so':<br>
> > | > | /tmp/RtmpbztUMm/Rinst1829c04c/cda/libs/cda.so: undefined symbol: zgetri_<br>
> > | > |<br>
> > | > | It builds fine on my local machines (Mac OS 10.5, 10.6).<br>
> > | > |<br>
> > | > | >From an older discussion on this list <<br>
> > | > | <a href="http://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg00678.html" target="_blank">http://www.mail-archive.com/rcpp-devel@lists.r-forge.r-project.org/msg00678.html</a>><br>
> > | > | the issue seems to be that Armadillo's inv() relies on a function that<br>
> > | > | is not provided by R, only by LAPACK. I have just replaced inv() by<br>
> > | > | pinv() and solve() in my code; merely to see what happens, but chances<br>
> > | > | are they also require a full LAPACK.<br>
> > |<br>
> > | Indeed, the error on R-forge is now with zgels_, required to solve<br>
> > | linear systems. It seems one cannot solve Armadillo linear systems<br>
> > | without LAPACK in the current situation.<br>
> ><br>
> > Yes. Doug, Romain and myself should address that, or at least make it clear<br>
> > what feature of the full Armadillo are lacking in RcppArmadillo.<br>
> ><br>
> > | > Sometime relatively early in the RcppArmadillo development process, Doug<br>
> > | > convinced Romain and myself to go for a pure template solution with Armadillo<br>
> > | > as all / most things found during the configure (or in this case, cmake)<br>
> > | > stage can be assumed 'found' given that we have around us by design. So no<br>
> > | > testing, no local library and full reliance and what R gives us.<br>
> > | ><br>
> > | > That was a brilliant idea, and has freed us from having to rely on building<br>
> > | > and shipping a library, having to tell users how to set PKG_LIBS etc pp and I<br>
> > | > firmly believe that this helped tremendously in getting RcppArmadillo more<br>
> > | > widely used. So I would not want to revert this.<br>
> > |<br>
> > | It sounds like a good choice, I agree. Yet solving a linear system is<br>
> > | quite a crucial task in linear algebra; it would be nice if we could<br>
> > | come up with a tutorial recipe for dummies like me.<br>
> > |<br>
> > | ><br>
> > | > In any event, it seems that you need more LAPACK than R has for you. That is<br>
> > | > likely to be a dicey situation as you per se do not know whether R was built<br>
> > | > and linked with its own (subset) copy of LAPACK, or whether it uses system<br>
> > | > LAPACK libraries (as e.g. the Debian / Ubuntu systems do). So you may be in<br>
> > | > a spot bother and I not sure what I can recommend --- other than trying your<br>
> > | > luck at some short configure snippets that will run at package build time to<br>
> > | > determine whether the system you want to build cda on it 'rich' enough to<br>
> > | > support it. I can help you off list with some configure snippets as some of<br>
> > | > my packages have configure code; adding a test for zgetri should be feasible.<br>
> > | ><br>
> > | > | Does anybody have any experience<br>
> > | > | dealing with such issues w.r.t releasing a package on R-forge / CRAN?<br>
> > | > | Is there any chance they would consider installing LAPACK on those<br>
> > | > | servers, or is there no point in asking such things?<br>
> > | ><br>
> > | > I don't think it is a matter of fixing the R-Forge server. I think it is a<br>
> > | > matter of making your package installable on the largest number of user<br>
> > | > systems. Also try <a href="http://win-builder.r-project.org" target="_blank">win-builder.r-project.org</a> to see how it fares on that<br>
> > | > platform.<br>
><br>
> Unsurprisingly, it fails, with the same complaint as R-forge.<br>
><br>
> > |<br>
> > | I was under the impression that R-forge or CRAN, if it had LAPACK<br>
> > | installed, could produce binaries for the relevant platforms, and<br>
> > | users would not have to build the package themselves and would not be<br>
> > | required of having LAPACK on their machine. That's probably a<br>
> > | misconception, isn't it?<br>
> ><br>
> > If and only statically linked binaries or libraries where produced, which is<br>
> > generally not the case. Many OSs (Linux incl) ship source only and otherwise<br>
> > link dynamically, others (Windoze) use dynamic linking and OS X is for all I<br>
> > know somewhere in the middle (as you can get prebuild packages with dynamic<br>
> > linking or build from source).<br>
><br>
> I see; so basically the user will always need to have a full LAPACK<br>
> installed. Here's one question then, if R-core didn't consider<br>
> necessary to include those particular functions from LAPACK,<br>
> presumably that means that R defines its own routines to solve linear<br>
> systems and invert matrices. Is there any possibility to use those<br>
> routines with Armadillo?<br><br></p><p>One important point has been missed in this discussion, which is that the particular Lapack subroutine that is not found in the subset of Lapack shipped with R is for general, complex-valued matrices (just google the name zgetri). The way that Armadillo is structured it is either all-in or all-out with respect to complex-valued matrices If you allow for complex matrices then you must have all the supporting subroutines for whatever you are calling. If you call inv() you need to allow for all the [sdcz]getri routines to be available.</p>
<p>So one possibility is to check the Armadillo sources to see if you can suppress the use of complex-valued matrices when compiling your package. A quick glance indicates that this might now be easy.</p><p>Otherwise, remember the first rule of numerical linear algebra which is, "If your algorithm involves computing the inverse of a matrix you should rethink the algorithm because there is a better way of doing it". So why do you need inv()? If the answer is to solve a linear system of equations then you use solve(), you do not use inv(). If, for some truly unusual reason you actually need the inverse (and, remember in 99.99% of the cases where people think they need the inverse, they don't) then you use a combination of solve() and eye().</p>
<p>> > | Sorry for being dense, I don't know anything about linking R to</p><p>
> > | external dependencies.<br>
> ><br>
> > It can be done; there are many examples -- for example every package using<br>
> > the GSL.<br>
><br>
> I just checked how RcppGSL does it, and well, this configure magic is<br>
> way above my head.<br>
><br>
> Best,<br>
><br>
> baptiste<br>
> _______________________________________________<br>
> Rcpp-devel mailing list<br>
> <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org" target="_blank">Rcpp-devel@lists.r-forge.r-project.org</a><br>
> <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</a><br>
</p>