On Jan 27, 1999, Jules Bean <[EMAIL PROTECTED]> wrote: > On 27 Jan 1999, Alexandre Oliva wrote:
> Can you tell -rpath to store the rpath for libmycustomthing.so and > not for libc.so? No, but, on some systems (for example, GNU/Linux), it is possible to hard-code the full pathname of libmycustomthing.so into the shared library itself, so that -rpath isn't needed, and the library cannot ever be moved. >> And that's the very reason why I've never been able to adopt any of >> the available packaging systems: the only way to keep multiple >> working versions is to use a separate directory for each version of >> each package. > In general, it is not useful to have multiple versions of the same > package. You're probably talking about the single-user workstation model. I'm talking about a networked multi-user model, in which some users need (for reasons only they understand :-) particular versions of, say, GNU Emacs and gcc installed. > I don't think that libtool is the right vehicle for you to evangelise your > dislike of packaging systems and the FHS. But debian-devel is probably a good place to talk about these ideas. > What is available, is a distribution with well-thought (not arbitrary) > structure and standards. A distribution used by many people, although not > as many as RedHat (which has similar standards in most respects anyway). I should note that I happen to appreciate both of them. > Nonetheless, you are refusing to support it. I'm not refusing to support it. I'm just inclined to avoid having an easy-to-use flag to disable explicit hard-coding of library paths because: 1) it would be hard to make it behave correctly in a portable way (and libtool would be useless if it were not for being portable); 2) it should not be necessary if you play by libtool rules, i.e., you pre-declare where libraries are going to be installed and keep them there forever (or until they're no longer needed); 3) I don't want to regret having introduced a flag that caused as much or more trouble than -rpath; and 4) I have already suggested a (dirty and ugly, I admit) hack that is sufficient for your needs of not using -rpath at all in Debian packages. I hope you understand my position now. I should also note that I myself have already wanted flags such as -hardcode-libdir for hardcoding the full pathname of a shared library into itself (it's mentioned in libtool/TODO) and -no-implicit-rpath (which is what you happen to be asking for), but I have some trouble deciding who should be responsible for deciding which flags to use for which libraries and programs. I feel this decision should be left for the installer of the package, but such installer-customizations aren't easy to introduce in the existing installation meta-tools. I'd really appreciate if someone had a bright idea about how to do that; I'd just like to avoid providing such dangerous flags for inadvertent use. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva [EMAIL PROTECTED] [EMAIL PROTECTED],gnu.org,egcs.cygnus.com,samba.org} Universidade Estadual de Campinas, SP, Brasil