On Wed, Jan 27, 1999 at 08:22:09PM -0200, Alexandre Oliva wrote: > > 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.
Please start another thread under a different subject for this. It is an important but mostly unrelated topic. > > 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); So why not move the discussion in a direction where we can talk about portability, instead trying to convince each other that the own ideas are the best. We are faced here with two different ideas about library dependencies (handling them at compile/installation time on your side, or handling them at run time on our side), so we better talk about a way how to address both. IMHO, both have their positive and their negative. Now let's try to get constructive. > 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); See above. Libtools rules are not necessarily the only "true" rules. Let's try to get support for diversity in library handling. > 3) I don't want to regret having introduced a flag that caused as much > or more trouble than -rpath; and I don't understand this comment. Which "trouble" with "--rpath" do you mean? Until now, I only heard from you that rpath is the ideal solution. Maybe we can get a better understanding of each other when we outline the negative of the own solution. I'll try a beginning: No rpath makes it harder for the linker to find the library. In fact, on some systems, it may make it impossible, so rpath is essential on some systems (though not GNU/Linux or GNU/Hurd). On other systems, the linker needs some smart way to resolve dependencies and search for libraries. No rpath makes it harder for a user to determine exactly which system libraries he links with. (With rpath, though, it only works when the system administrator never changes the library file at this place, too). This is in a hurry. Could you do me tha favour and list some negative points of using rpath, too? > 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. We can find our own hacks (and do so since a long time). Now we are interested in a compatible, portable and general solution. As the libtool maintainer, you should be the ideal person to talk about such a solution. I think we understood by now that a simple disable flag does not satisfy your high ambitions wrt to portability. Let's move on to better solutions. > 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. Maybe you should not be the one to decide at all? Offer flexible solutions, where the last person can override the (possible) default given by others. This means, the package can provide a default, which can be overridden at compilation time. Finally, the installer can override both. > 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. Implement what works and provide a framework for things which should be made to work. This means, implement those flags for compilation, and leave installation possible for later. Marcus -- "Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@ Marcus Brinkmann http://www.debian.org master.debian.org [EMAIL PROTECTED] for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09