Hmm, I don't quite get the point of your message.
"Installing the dynamic library somewhere else and link it in by ... adding said library to the users LD_LIBRARY_PATH ..." is pretty much exactly the way things are designed and supposed to work (and actually do work to a large extent) in Sage. I don't think LD_PRELOAD in its various incarnations is portable enough for the Sage purposes (I haven't checked though). The problems always arise with spkgs whose build systems are complex and involved (and trying to be smart ...), so it is hard to tell them that e.g. binaries they produce, that depend on certain libraries, should look up these libraries dynamically at runtime in LD_LIBRARY_PATH (and additionally in DYLD_LIBRARY_PATH on Mac OS X 10.4 and 10.5). And nowhere else! Sometimes this could be solved only by some dirty tricks like referencing explicitly "libfoo.1.2.3.so" instead of "libfoo.so" (the "libpng case" on Mac OS X, as far as I remember). This approach comes wih a certain cost --- in order for things to work together, you are more or less forced to have the "sane" environment you get by typing "./sage -sh", or else to work completely outside of it, but you can hardly "mix". (There was a recent thread I don't remember exactly on calling exterior functionality from inside a Sage session, where you had to use some "raw" calling mechanism, forgetting these environment settings.) However, given that one might want (or need ...) to be able to work in two or more possibly incompatible Sage environments (e.g. different Sage versions rsp. installations) at the same time without installing and re-installing, this is rather a feature than a bug. In a nutshell: there has been put much effort in the dynamic libraries/ LD_LIBRARY_PATH approach already. But more hard work awaits us, e.g. w.r.t. readline and gnutls. There have been discussions of distributing "bash" itself within Sage, because bash links in readline dynamically (which is the heart of the problem on Suse) AFAIR. The same with gcc, there already exist some versions of a "gcc.spkg". >From a distance, Sage would profit from having some kind of inventory of all the dynamic libraries its parts depend on, and from a flexible mechanism to switch between using either versions of these installed already somewhere in the system, or else using a version (to be) installed under SAGE_LOCAL/lib/. The debianization has paved some way in this direction, but currently, I don't think we have the manpower to stem the inevitable complexity of introducing such an infrastrucure, let alone "only" maintaining it. OTOH, there are already now various things which could be bundled together in some kind of "Sage Registry", e.g. the "sage-location" and "sage-flags" text files, the "spkg/installed/" directory content, ... Cheers, Georg -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
