Date: Tue, 15 Aug 2017 19:09:45 +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-g5is0geRBW@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 #6 from Mark Millard <markmi@dsl-only.net> --- (In reply to Jan Beich from comment #5) >(In reply to Mark Millard from comment #3) >> mix of system and gcc libraries than gcc5 > >Tier1 and some Tier2 archs don't have system GCC anymore. It's enough to i= nstall more >than one lang/gcc* to get ambiguity about libstdc++ et al. There are still system libraries that are ambiguously bound to when the system has no gcc of its own. Use of: -Wl,-rpath=3D/usr/local/lib/gcc<?> for the appropriate <?> prevents that. For 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 there is also the lack of: libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x800b72000) when -Wl,-rpath=3D/usr/local/lib/gcc<?> is used. This can interact badly with binding to: libthr.so.3 =3D> /lib/libthr.so.3 (0x8011d3000) since libthr was built based on the context for: libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x800b72000) and not the implicit material in libstdc++. See bugzilla 221423. For reference: g++6 -std=3Dc++14 -Wpedantic -Wall -pthread -Wl,-rpath=3D/usr/local/lib/gcc= 6 -O2 cpp_clocks_investigation.cpp # ldd a.out a.out: libstdc++.so.6 =3D> /usr/local/lib/gcc6/libstdc++.so.6 (0x800844000) libm.so.5 =3D> /lib/libm.so.5 (0x800bd9000) libgcc_s.so.1 =3D> /usr/local/lib/gcc6/libgcc_s.so.1 (0x800e06000) libthr.so.3 =3D> /lib/libthr.so.3 (0x80101d000) libc.so.7 =3D> /lib/libc.so.7 (0x801245000) and the result has crash problems from the odd mix of libstdc++ supplying what would be used from libcxxrt inlibthr. (FYI: cpp_clocks_investigation.cpp is pure standard C++ code.) (I did not notice libthr using libgcc_s but if it did then it is the same sort of problem as for libstdc++ providing when the system libcxxrt would provide.) By contrast: clang++ -std=3Dc++14 -Wpedantic -Wall -pthread cpp_clocks_investigation.cpp= =20 # ldd a.out a.out: libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x8008a6000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x800b72000) libm.so.5 =3D> /lib/libm.so.5 (0x800d90000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x800fbd000) libthr.so.3 =3D> /lib/libthr.so.3 (0x8011d3000) libc.so.7 =3D> /lib/libc.so.7 (0x8013fb000) works fine and libthr has libcxxrt to bind to (and the system libgcc_s if libthr has any binding to there). Separately from the above: -Wl,-rpath=3D/usr/local/lib/gcc<?> also disambiguates when having multiple lang/gcc* 's installed. But this type of context is not required for there to be binding problems. --=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-g5is0geRBW>