> Hi Steve, > > On Sunday 18 April 2010 21:10:17 Steven Trogdon wrote: > > Christopher, > > > > > > > > I've finally gotten around to trying the changes and a clean emerge of > > everything installs as it should. Here a revdep-rebuild reveals that > > libsingular.so can't be found. The proposed resolution is to re-emerge > > sage-core which, of course, doesn't resolve the issue. What's the > > procedure to update the ld cache when libraries like libsingular.so are > > not in the "standard" location? Should something be done in > > sage-singular that doesn't compromise things? > > I noticed the same behavior and looked at /etc/ld.so.cache which pointed > to /etc/env.d/... - so the gentoo way of doing this would be to add a > file which contains LDPATH="/opt/sage/local/lib". Though I did not test > it, it should work and I will add this file tomorrow. Hi guys,
I don't like that solution at all. What will happen if you have system wide singular and sage-singular? If you add this file there is a good chance that someone wanting to use the system provided singular will end up using sage-singular. Just for the purpose of testing for side effects, I installed singular-3.1.1. revdep-rebuild didn't pick up on sage-core after that. Probably because libsingular lacks an soname and is completely unversioned. No. sage-env takes care of telling sage where to look. There is no real perfect solution so long as we have ship sage-singular. For now I would put a file in /etc/revdep-rebuild masking the offending libraries. 50sage-core: #Those files look for a version of libsingular that will be located through # LD_LIBRARY_PATH at run-time. LD_LIBRARY_MASK="lib1.so lib2.so lib3.so" ----- Of course that means that revdep-rebuild cannot pick up the fact that they are broken. Which of course it may not be able to do anyway because of the lack of versioning. On the positive side a change in sage-singular will always coincide with a change of sage-core so there shouldn't be any trouble. Francois
