On Sat, 2003-07-19 at 02:54, Ralf S. Engelschall wrote: > On Sat, Jul 19, 2003, Matthias Kurz wrote: > > > > Would patches that implement (as options, turned off by default) shared > > > libraries and relocation be acceptable? > > > > > > I'm in a situation that I need those features, but dread having to fork > > > a set of package spec files etc. for my own use. > > > > I think, the shared library "problem" needs to be addressed some day, > > anyway. What are there for known problems ? I think uncontrolled > > dependencies (automatically picked up shared libs) are the greatest > > problem, aren't they ? > > Some of the reasons are mentioned in the FAQ AFAIK. > > > Instead of patching all the many spec-Files that have "disable-shared" > > set etc., wouldn't it be possible to introduce a global setting (with > > a default of "no"). > > Yes, I plan for a with_shared option which all packages can support. > The question which is still unanswered is _HOW_ the packages should > support this. At least without executable wrappers this option at > least disallows multiple OpenPKG instances on the same machine. But > that certainly has to be the price for using shared libraries. The > only workaround on ELF platforms is that we either patch all packages > to correctly supply an -rpath to hard-code the paths to the shared > libraries or write a little utility which post-adjusts installed > libxxx.so files and hard-codes their path. The whole shared library > issue is on the TODO list for OpenPKG 2.0.
The rpath solution sounds like a neat idea since it needs to be done only once, instead of with an rc script. Being able to do post-adjustment also helps for my case where I'm building relocatable packages. Cheers Conrad -- ______________________________________________________________________ The OpenPKG Project www.openpkg.org Developer Communication List [EMAIL PROTECTED]
