[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep.sh / env sanity patches

From: Nicola Pero
Subject: Re: GNUstep.sh / env sanity patches
Date: Fri, 20 Aug 2004 00:53:41 +0100 (BST)

> If the library knows where it is, or uses all relative paths, then 
> there is NO need to GNUsteprc.

NB: Relative paths are not a viable solution because a working solution
based on relative paths would depend on the dynamic linker library having
an API to determine the location of an object file on the disk, and this
API is not available on some systems.

I mean, say gnustep-base knows that the local domain is in
../../../../../Local/.  That's a relative path, but relative to what?  If
it's relative to the location of libgnustep-base.so, then gnustep-base
must be able to determine where libgnustep-base.so is.  That is totally
non-trivial -- almost impossible -- unless the dynamic linker gives you an
API to get the full path to object files which have been loaded into the
executable.  That API exists on linux, but not on other systems.

Anyway, I take note you don't like being able to configure things to
install in /usr/lib or such stuff.  Ok - I get that.  As a consolation, I
can say that we'll always be supporting and encouraging the GNUstep
filesystem hierarchy, we all love that and it's the default and we like
evangelizing people about how crap a name such as /usr/bin is compared to
our elegant /System/Tools. :-)

I'm still a bit confused about why you care if the paths are stored in
libgnustep-base.so/GNUstep.sh or in GNUsteprc.  Presumably it boils down
to the same issue, that you don't want people to be able to edit them too
easily and potentially configure the filesystem in non-standard ways ?

Unfortunately the only way to stop people from configuring the filesystem
in some non-standard way would be to have spyware installed in all
computing machinery to control what people do with the GNUstep source
code ... to make sure they don't put anything in a forbidden location such 
as /usr/lib. ;-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]