Date: Tue, 15 Aug 2017 22:22:52 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 221423] gcc std::locale(LocaleName) crashes instead of throwing an exception Message-ID: <bug-221423-29464-e5TJ16wis3@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-221423-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-221423-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221423 --- Comment #8 from Mark Millard <markmi@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=3D/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=3D/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 =3D> /lib/libgcc_s.so.1 (0x800fbd000) vs. libgcc_s.so.1 =3D> /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=3D/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 =3D> /lib/libcxxrt.so.1 (0x800b72000) because a bunch of those bindings can instead be found from the likes of: libstdc++.so.6 =3D> /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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-221423-29464-e5TJ16wis3>