[Bug 221423] gcc std::locale(LocaleName) crashes instead of throwing an exception

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Tue Aug 15 19:09:45 UTC 2017


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221423

--- Comment #6 from Mark Millard <markmi at 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 install 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=/usr/local/lib/gcc<?>

for the appropriate <?> prevents that. For 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 there is also the lack of:

       libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800b72000)

when -Wl,-rpath=/usr/local/lib/gcc<?> is used.

This can interact badly with binding to:

       libthr.so.3 => /lib/libthr.so.3 (0x8011d3000)

since libthr was built based on the context for:

       libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800b72000)

and not the implicit material in libstdc++. See
bugzilla 221423.

For reference:

g++6 -std=c++14 -Wpedantic -Wall -pthread -Wl,-rpath=/usr/local/lib/gcc6 -O2
cpp_clocks_investigation.cpp

# ldd a.out
a.out:
       libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x800844000)
       libm.so.5 => /lib/libm.so.5 (0x800bd9000)
       libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x800e06000)
       libthr.so.3 => /lib/libthr.so.3 (0x80101d000)
       libc.so.7 => /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=c++14 -Wpedantic -Wall -pthread cpp_clocks_investigation.cpp 

# ldd a.out
a.out:
       libc++.so.1 => /usr/lib/libc++.so.1 (0x8008a6000)
       libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800b72000)
       libm.so.5 => /lib/libm.so.5 (0x800d90000)
       libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800fbd000)
       libthr.so.3 => /lib/libthr.so.3 (0x8011d3000)
       libc.so.7 => /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=/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.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-toolchain mailing list