| Summary: | build error on 0.3.6 cannot find -lRlapack | ||
|---|---|---|---|
| Product: | [Applications] rkward | Reporter: | RKWard Team <rkward-devel> |
| Component: | general | Assignee: | RKWard Team <rkward-devel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | All | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
RKWard Team
2006-05-05 12:11:56 UTC
-- Originally posted by (AT sourceforge.net): braverock -- - **assigned_to**: nobody --> tfry -- Originally posted by (AT sourceforge.net): braverock -- - **assigned_to**: tfry --> ecoch Logged In: YES user\_id=300591 Thanks for your bug-report, and of course thanks for your packaging efforts\! In RKWard 0.3.6 I added the -lRlapack switch, as otherwise, with R 2.3.0, sometimes some base packages could not be loaded due to unresolved symbols. RKWard itself does not use the library, but this way it loads it for R packages to use. I have not fully investigated, why exactly this happens. In fact, ATM, I do not seem to be able to reproduce this. Maybe it was a temporary bug in one of the pre-release versions of R 2.3.0 I tested, and has since been fixed. I do not know, and would appreciate any insight. Ok, how to work around this? Probably the most straightforward way would be to edit rkward/Makefile.am and remove the -lRlapack switch there \(I do not know, whether this is possible in gentoo packaging, but I hope so\). If everything works fine, then \(remember to test with R 2.3.0, too\), that should be the best way, and I'll probably remove the switch in the next release of RKWard \(after some more testing\). You might also try some other things first: 1\) ln -s /usr/lib/R/modules/lapack.so /usr/lib/R/lib/libRlapack.so \(that is the location ldd will be searching for -lRlapack\) 2\) Upgrade to R 2.3.0. Maybe some configuration options changed there. Please keep me up-to-date on whether or not this works. Regards Thomas P.S.: Please don't set the "Assigned to" field, when submitting bug reports. We don't really use this field ATM, but it's rather intended to be an internal way of signalling "I'm taking care of this" among the developers, not a setting intended to be made by the submitter. - **assigned_to**: ecoch --> nobody -- Originally posted by (AT sourceforge.net): braverock -- Logged In: YES user\_id=204919 Sorry about the Assigned To field. I just know that Sourceforge, by default, won't notify developers of new Tracker items like it does for Forum posts. Also, many projects make extensive use of the Assigned To field for triage and coordination. \(I run or contribute to a couple of SF's top 100 projects\). Creating the symbolic link resolved the problem. I suggest that you may want to check and see if R was built with lapack support before making a requirement like this. I also got a couple of build sandbox errors which I was able to work around in the ebuild script. I'm going to test on a few more machines, and then I'll submit the ebuild both to Gentoo for inclusion and to the RKWard project via the Patches tracker. I'll mark this as closed, but I think you still want to consider how to make the rkward build process more resilient, and continue to support R 2.2.x, since R 2.3.0 was only released on 2006-04-24, and is not yet widely deployed \(or packaged with any distro that I'm aware of yet\). Regards, \- Brian -- Originally posted by (AT sourceforge.net): braverock -- - **status**: open --> closed Logged In: YES user\_id=300591 Hi Brian, we receive automatic messages on tracker activity in a dedicated mailing list \(but yes, it took a long time until I finally found at about this extremely useful feature\). Again, we don't really use the "Assigned To"-field ATM, since we're still a small project, and rarely need much formal coordination. So nothing to worry about. I suppose the symbolic link thing does not really do anything meaningful, but satisfies the linker. I'll add a check to ./configure to only link against -lRlapack, if that exists. Maybe you could drop us a mail with details about the sandbox violations on rkward-devel? I think I have an idea, where at least some of this comes from, but details would be helpful. Note that RKWard continues to support R releases starting with R 2.1.0. The -lRlapack problem should be unrelated to R releases \(only to R build options\). The only thing to note is that between R 2.2.x and R 2.3.0 a rebuild of rkward is needed \(i.e. RKWard compiled with R < 2.3.0 will not work with R >= 2.3.0 and vice versa\), and unfortunately, there is nothing we can do about this. Regards Thomas |