Georg S. Weber wrote: > Hmm, > > I don't quite get the point of your message.
Sorry, I was trying to get some discussion, and hopefully understanding, of why these issues arise, with a hope to trying to fix them. It's clear the present situation has 'issues' and to my knowledge, nobody has a foolproof way of building Sage without having to rely on 'hacks' on some operating systems. > "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). LD_LIBRARY_PATH tells the program where to look for libraries it can't find. I'm not aware of how it is supposed to behave if there are system libraries and libraries of the same name in LD_LIBRARY_PATH. Can we be sure that system libraries will be used in preference to those in LD_LIBRARY_PATH, or can we be sure those in LD_LIBRARY_PATH will be used in preference to those in the system? It seems to me, if the library is on the system in somewhere like /usr/lib, then it will be loaded from there, despite the fact LD_LIBRARY_PATH might specify a location where another copy resides. For Solaris at least, LD_PRELOAD can be used to force something to be loaded in preference to what exists on the system. I've no idea how portable that is. I'm not suggesting it is the way forward. > The problems always arise with spkgs whose build systems are complex which is not unusual. > 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). But from what I understand, setting LD_LIBRARY_PATH does *not* guarantee that a program will first look in the directories specified in LD_LIBRARY_PATH, then look in system directories like /usr/lib. > 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". I can't help but feel distributing bash is just a hack. It's not really solving the underlying problem. We might resolve the issues on Suse with readline by distributing bash, but it's anyones guess what will be the next problem, on the next platform. Given that some versions of gcc are far more stable than others, and that not all gcc's are built with Fortran support, I can see a more convincing argument for distributing gcc. But for very different reasons, which have nothing to do with libraries. >>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. I can't see that being very practical if a program is going to support multiple operating systems. I was wondering if something could be done with version numbers of libraries, or perhaps all libraries are built with the name 'sage' at the front, so there is libsagereadline for example. But I suspect that is the name of the functions in the library which are important, not the library name, so that would probably not work. Dave -- 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
