Re: Darwin: Replace environment runpath with embedded [PR88590]

[Iain Sandoe <iains.gcc@gmail.com>]

Hi Joseph,

> On 18 Aug 2023, at 21:17, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Tue, 15 Aug 2023, FX Coudert via Gcc-patches wrote:
> 
>> I am currently retesting the patches on various archs (Linux and Darwin) 
>> after a final rebase, but various previous versions were 
>> regression-tested, and have been shipped for a long time in Homebrew.
>> 
>> OK to commit?
> 
> The driver changes are OK.
> 
> I think the new configure options and the new -nodefaultrpaths compiler 
> option need documenting (I suppose there might be a case for the configure 
> option defined in libtool code being documented somewhere in libtool, if 
> there's somewhere appropriate, but I don't see that in the libtool patch 
> submission).
> 
> The help text for --enable-darwin-at-rpath refers to it as 
> --enable-darwin-at-path.

OK, we need to fix those things.

> Somewhere the documentation ought to discuss the considerations around 
> embedding such paths in binaries, and what's appropriate for building a 
> binary on the system where it's going to be used, versus using the 
> compiler to build redistributed binaries that will be run on a system that 
> doesn't have the compiler installed (and so shouldn't have hardcoded paths 
> that were only applicable on the system with the compiler, but will need 
> to be able to find shared libraries - probably shipped with the binary - 
> somehow).

Actually, the changes are not so dramatic as they seem (for Darwin) since we
already have less flexibility than other unix-like systems.

The status quo is that installed libraries embed their runpath e.g:
/path/to/compiler/install/lib/libgfortran.dylib

When executables are built, they embed the full library names for dependent
libraries (this "two-level" namespacing has some useful and not-so-useful
sides to it).

However, Darwin compiler installations are not relocatable without re-writing the
library names and,  because of the vendor’s decision to neuter
DYLD_LIBRARY_PATH, (the Darwin equivalent of LD_LIBRARY_PATH) it makes
it quite involved to do such a move.

===

After the change:
libraries are identified as  @rpath/libgfortran.dylib (for example)

and any executable built by the compiler has a runpath /path/to/compiler/install/lib.

Actually, after this change the compiler is initially relocatable (that is you can choose to
install it anywhere) but once installed, if you move it, that would break executables already
built because they embed the path to the installation.

So, in practice, for the “out of the tin” self-use of GCC, there is no practical difference between
the existing fixed installation and a “placed once” installation.

[however, the change means that we can correctly configure the compiler, since the runpaths
 at build time can be made to point to the uninstalled libraries, which is the underlying problem
 we are solving].

— on the topic of building applications for distribution:

The expectation for Darwin platforms is that dependent libraries are shipped along with
applications (it is not desirable to require that end users have to have elevated privs to
install them in some Well Known Place, and [other than OSS distributions like macports
and homebrew] there is no common place to expect to find OSS libraries).

There is quite extensive Apple Developer documentation on delivering packages with
co-installed libraries using @rpath (that is the intended mechanism for delivery since it
allows drag-and-drop installation and moving of built applications).

The revised compiler has libraries already built in a suitable manner for that distribution
model.

I would not propose that we repeated such information - but we could refer to it?

Generally, I’d prefer we suggested searching for such documentation, rather than linking
to it, since links can expire - does that seem reasonable?

thanks for the reviews
Iain

> -- 
> Joseph S. Myers
> joseph@codesourcery.com