Use configure.ldflags-delete instead of configure.ldflags?

[Jeff Johnson]

On Mar 18, 2011, at 11:15 AM, Anders F Björklund wrote:

> Rainer Müller wrote:
> 
>> On 03/18/2011 09:58 AM, Ryan Schmidt wrote:
>>> Can you give an example of a library that would not be relocatable?
>> 
>> As Anders already said, anything that uses data files from
>> ${prefix}/share or ${prefix}/etc and has these paths hardcoded for this
>> purpose.
> 
> And that's on a *good* day. Usually it's "/usr/share" and "/etc".
> (looking at you, glib. Thanks for that $XDG_DATA_DIRS requirement)
> 
> Some of the more subtle points are the ones that get clever and
> presume that everything is installed to the *same* directory...
> So they would use the prefix of "foo", to get the prefix of "bar".
> Which of course works just fine if both are /usr, but not always.
> 
> MacPorts usually relocates everything to the same directory anyway
> (i.e. by linking to the "software" images, rather than referring)
> But other software that uses one prefix per program has problems.
> Or one prefix per program-version, even (to allow multiple installs)
> 
> I think most of the hardcoded "/opt/local" strings have been fixed.
> Making ${prefix} a run-time thing, that is definitely still TODO...
> 

One can do relative paths from argv[0] to find data directories "portably"
independent of PATH. You do have to be a bit careful hos that is done,
because you can no longer just copy an executable once argv[0]
is used to find attached data/configuration. But there's a large
class of executables (imho) that are built, installed, and seldom copied.

> 
> There was an over-engineered solution called "binreloc" for this,
> that was for Linux but also portable to Solaris/Darwin (not BSD ?).
> 
> http://www.autopackage.org/docs/binreloc/
> -> _NSGetExecutablePath(path, &path_len);
> 

Yes autopackage is/was horrendously over-engineered.

But the problem still remains, particularly with 3rd party excutables
built out of tree. NixOS has a rather straightly-forward solution
to path independence. Not quite run-time, but cleanly separated from The Build.

And the relevance to MacPorts and Mach-O is that the problem is the same
(in fact worse on MacPorts) and the engineering approaches to solving
are the same even if the implementations I just mentioned are irrelevant.

73 de Jeff