when libgcc multilibs are built the Makefile forces two vars to be
empty during the build phase viz:
slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)
unfortunately, "libsubdir" is used in configure.ac like this.
AC_ARG_WITH(slibdir,
[ --with-slibdir=DIR shared libraries in DIR [LIBDIR]],
slibdir="$with_slibdir",
if test "${version_specific_libs}" = yes; then
slibdir='$(libsubdir)'
elif test -n "$with_cross_host" && test x"$with_cross_host" != x"no";
then
slibdir='$(exec_prefix)/$(host_noncanonical)/lib'
else
slibdir='$(libdir)'
fi)
AC_SUBST(slibdir)
and slibdir :
shlib_slibdir = @slibdir@
and shlib_slibdir ends up as the path for the instal_name (via
shlib_slibdir expansion in the LINK fragment).
== the upshot is that (at least on dawin) when building with "--
enable-version-specific-runtime-libs"
libgcc gets built with
/libgcc_s.1.dylib
as the embedded rpath
This then gets referenced by the other libs (e.g. libgfortran.dylib)
[ because the stub libs 10.X refer to it].
Whilst the libgcc path is corrected in the install phase; the
references in the other libraries are not.
====
libsubdir is expanded
libsubdir = $(libdir)/gcc/$(host_noncanonical)/$(version)
in Makefile.in.
If this expansion is applied in configure.ac, all works OK on darwin.
i.e.
if test "${version_specific_libs}" = yes; then
slibdir='$(libdir)/gcc/$(host_noncanonical)/$(version)'
Would that change cause a problem on any other target?
Iain
