On Wed, 17 Nov 2021, Iain Sandoe via Gcc-patches wrote:
> If we are going to try and reconcile GCC’s local libtool for more
> generic Darwin use, then I fear that is going to take quite significant
> work over a period of time (since it will need much more wide testing
> than GCC).
The goal is
On Wed, 17 Nov 2021 at 21:28, Iain Sandoe via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> this refers to the libstdc++ changes (mostly a regeneration from the
> libtool
> change) but a small addition to Makefile.am to add @loader_path as a
> default for libstdc++ to find its dependent libs.
>
Th
> On 17 Nov 2021, at 22:50, Joseph Myers wrote:
>
> On Wed, 17 Nov 2021, Iain Sandoe via Gcc-patches wrote:
>
>> * libtool.m4: Add 'enable-darwin-at-runpath'. Act on the
>> enable flag to alter Darwin libraries to use @rpath names.
>
> To confirm: has this been sent to upstream l
On Wed, 17 Nov 2021, Iain Sandoe via Gcc-patches wrote:
> * libtool.m4: Add 'enable-darwin-at-runpath'. Act on the
> enable flag to alter Darwin libraries to use @rpath names.
To confirm: has this been sent to upstream libtool (which has recently
acquired a new maintainer, so hopef
Recent Darwin versions place contraints on the use of run paths
specified in environment variables. This breaks some assumptions
in the GCC build.
This change allows the user to configure a Darwin build to use
'@rpath/libraryname.dylib' in library names and then to add an
embedded runpath to exec
