https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221423
--- Comment #8 from Mark Millard <mar...@dsl-only.net> ---
(In reply to Jan Beich from comment #5)
> Can you confirm the issue doesn't affect lang/gcc6 and lang/gcc7?
> The default is going to change soon per bug 219275.
I'm not sure which issue(s)/aspect(s) you are after,
so I pick the following to try to answer.
I strongly expect that an ldd on the original
context that was using std::locale(LocaleName)
would show something implying a mix of system
and gcc original definitions, where at run-time
a specific binding ends up being made. (But no
one has posted such ldd output for the failing
context(s).)
I expect that what is required is producing the
program and libraries it is bound to such that
that they avoid the mix and bind at run time to
the same implementation related materials as
they all were built with.
I expect that such applies to all lang/gcc*
examples, including gcc6 and gcc7 and the
older gcc5 (and before).
This hole area of bindings is a mess. Progressing
from gccN to gcc <N+1> is an example were if
-Wl,-rpath=/usr/local/lib/gccN
was used then it looks explicitly for files from:
/usr/local/lib/gccN/
and if lang/gccN is uninstalled they will not be
there to be found. It takes a rebuild or other
form of forced redirection to have it try looking
in:
/usr/local/lib/gcc<N+1>/
instead. Even if it looks and finds a binding in
the new place it can try to use, the behavior need
not be compatible once bound.
Some types of system have a means of leaving the
libraries around for binding even when the compiler
and such is no long around for the version in
question.
Without -Wl,-rpath=/usr/local/lib/gccN involved
there are other issues. But sometimes the binding
that results happens to work better than does with
-rpath in use (since other libraries involved
were not set up for the -rpath libraries but,
say, system ones).
I'm not sure there is a universal, fixed answer to
which binding is better for the likes of (gcc6
example):
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800fbd000)
vs.
libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x800e06000)
but as things are the run-time binding is
controlled via use or not of the:
-Wl,-rpath=/usr/local/lib/gccN
Any set of libraries that is put to use in a program
but that ends up being originally based overall on a
mix of the two bindings (build time) is likely to end
up being a problem combination when one implementation
is actually bound.
However, as I understand it, that option does not
determine the use or not of the likes of:
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800b72000)
because a bunch of those bindings can instead be
found from the likes of:
libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x800844000)
if it is involved, even without a -rpath in the link.
Again a set of libraries used in a program but
that mix the original contexts is likely to
end up being a problem combination. (The
program needs to match as well.)
It appears that avoiding mixes is generally
(but not universally?) required (both for
libgcc_s alternative and for libcxxrt vs.
implicit in libstdc++ ).
In case an example makes it clearer:
For my libthr example: It appears to me that a program
using libstdc++ itself or in libraries would need a
libthr equivalent that had also been built based on
libstdc++ as libstdc++ is now constructed. Similarly
for any libgcc_s use by the libthr equivalent.
An alternate would be a libstdc++ that was built based
on the system libgcc_s and libcxxrt and so that libstdc++
did not provide various bindings to gcc specifics that
libstdc++ now does --and there would be no gcc based
libgcc_s in use. As I understand g++ and libstdc++ is
not designed for this sort of structure.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
