[Bug 260364] Toolchain creates the shared library that SEGVs on load: Invalid permissions for mapped object.

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 12 Dec 2021 19:13:03 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260364

Mark Millard <marklmi26-fbsd@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marklmi26-fbsd@yahoo.com

--- Comment #5 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
(In reply to Yuri Victorovich from comment #0)

The backtrace shows an incoherent mix of system C++ libraries
and gcc10 C++ libraries:

/lib/libcxxrt.so.1
and:
/usr/local/lib/gcc10/libstdc++.so.6

in use. Can show report the output of using ldd on the program
that you built and also for work/stage/usr/local/lib/calf/libcalf.so ?

gcc's /usr/local/lib/gcc10/libstdc++.so.6 is not designed to be
used with non-gcc c++ infrastructure libraries like: /lib/libcxxrt.so.1 .

Absent the ldd outputs I will show some examples of what to expect
in ldd output:

Because of what compilers I happen to have around I'll use gcc11 for
illustration --without involving a use of dlopen.

# more trivial.cpp
// # c++ -v -o trival trivial.cpp

int main() {
}

Correctly built with gcc11:

# g++11 -Wl,-rpath=/usr/local/lib/gcc11 trivial.cpp
# ldd a.out
a.out:
        libstdc++.so.6 => /usr/local/lib/gcc11/libstdc++.so.6 (0x42400000)
        libm.so.5 => /lib/libm.so.5 (0x409a9000)
        libgcc_s.so.1 => /usr/local/lib/gcc11/libgcc_s.so.1 (0x41072000)
        libc.so.7 => /lib/libc.so.7 (0x43f5a000)

Correctly built with system clang (main [so: 14] context):

# c++ trivial.cpp
# ldd a.out
a.out:
        libc++.so.1 => /usr/lib/libc++.so.1 (0x419b3000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x41c4d000)
        libm.so.5 => /lib/libm.so.5 (0x428aa000)
        libc.so.7 => /lib/libc.so.7 (0x43af3000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x42d20000)


Note the /lib/libcxxrt.so.1 is only there for the system c++
build that uses /usr/lib/libc++.so.1 instead of using
/usr/local/lib/gcc11/libstdc++.so.6.

Comparing/contrasting the two there is also:

/usr/local/lib/gcc11/libgcc_s.so.1 for gcc11 use
vs.:
/lib/libgcc_s.so.1 for system c++ use.

An odd mix happens for the following incorrect build:

# g++11 trivial.cpp
# ldd a.out
a.out:
        libstdc++.so.6 => /usr/local/lib/gcc11/libstdc++.so.6 (0x42600000)
        libm.so.5 => /lib/libm.so.5 (0x40c8a000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x419b2000)
        libc.so.7 => /lib/libc.so.7 (0x430fe000)

/usr/local/lib/gcc11/libgcc_s.so.1 should be in use when
/usr/local/lib/gcc11/libstdc++.so.6 is in use. But that
does not happen without the use of:

-Wl,-rpath=/usr/local/lib/gcc11

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