Re: RFC: Framework support in -make

[Nicola Pero]

> > Good point - but you need those in LD_LIBRARY_PATH only if you install
> > libraries/frameworks in there; in which case, yes, you need to set your
> > LD_LIBRARY_PATH. :-)
> > 
> 
> I cannot, because some shells (bash or csh for example) are destroying 
> LD_LIBRARY_PATH
> variable.

Not shells ... Really, what you are reporting is more of an xterm issue
than a GNUstep problem.

Your xterm is setuid root.  Why does xterm needs to be setuid root ?  No
idea, probably to perform some root action - logging or similar.  If I
could choose, I'd rather have my xterm not setuid root, but that's how it
is by default. :-)

Anyway, setuid executables strip off the LD_LIBRARY_PATH.

The default solution is to source GNUstep.sh in your login script, then
firing a login xterm will execute the login script, and so will set the
LD_LIBRARY_PATH automatically.

That does indeed work, I mean most GNUstep users are doing it, and it 
works for them, so it could as well work for you. :-)


> LD_LIBRARY_PATH is also lost when you source GNUstep.sh in .xinitrc.

Yes, it should be sourced in your profile script, not inside .xinitrc.

Btw, GNUstep.sh used to be very slow, I've speeded it up, so it should be
more acceptable to execute it at every login.
 

> > But normally RPM do not install stuff in your own home directory - they
> > install systemwide! :-)
> > 
> 
> Ok, that is the case for RPM, but gnustep has the ability to install
> frameworks and applications anywhere. Users can install frameworks just 
> by dragging them into apropriate folder in their home directory,

Of course they can't.  I'm afraid there is no way to make that work.  
Frameworks require manual setup when installed - be it creating symlinks,
or be it, in alternative schemes which have been proposed, adjusting
hardcoded search paths in the object files.  Without some setup, the
linker will not find them.

I suppose building a .tgz from a framework (including the symlinks) could
make a package which is very easily installed - you unpack the .tgz in
your ~/GNUstep/Library/, and it then works out of the box.  That's not
exactly "dragging the framework into the appropriate folder", but it's
somewhat similar.


> as they can do with apps.

Yes, they can drag apps into their home directories, and that works (it
wouldn't necessarily work with -rpath, but it does with the current
scheme).

I agree this can be a great improvement over other installation
procedures.  You download your .app binary, save it in your hard disk,
double click on it, and it runs.


> It is an advantage of GNUstep that users can install their own software.

Yes.

 
> > If you compare with other binary packages, they never install a library in
> > your own home directory.  They install it in /usr/lib.  If - very unlikely
> > - but if you install a shared library in your home directory, they would
> > ask you to set LD_LIBRARY_PATH so that it can be found, exactly as GNUstep
> > does.
> > 
> 
> Yes, they are other packages, but this is GNUstep. GNUstep can do things 
> better.

GNUstep is built on top of the underlying system, so we do what we can,
but we can't do things that the underlying system can't do.  The linker
needs help to find shared libraries installed in non-standard locations
such as user directories.  You can help it by using LD_LIBRARY_PATH or by
other linker machinery.  Maybe future linkers can do better than the
current one, but I guess it can't be made much easier than setting an
environment variable.  Maybe the linker could have an additional per-user
ld.so.conf, that would help :-)


> LD_LIBRARY_PATH does not work (see above) and this is the reason why many
> people are using ld.so.conf with gnustep (including me).

At the end of the day, I'm not quite sure what your problem is.  Using
ld.so.conf is great (and I encourage you to use it) for System/Local dirs.  
LD_LIBRARY_PATH is better for User dirs (and might be good for Network as
well).

Your problem with LD_LIBRARY_PATH can be fixed by using the default
documented procedure for setting up GNUstep - that is, sourcing your
GNUstep.sh in your profile.  Alternatively, use an X terminal which is not
setuid root.