[Bug 237208] java/openjdk11: port to powerpc64

[bugzilla-noreply at freebsd.org]

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

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

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

--- Comment #55 from Mark Millard <marklmi26-fbsd at yahoo.com> ---
Comment on attachment 204682
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=204682
Changes for openjdk11/Makefile

(In reply to Greg Lewis from comment #54)

If powerpc64 FreeBSD is constructed such that base/binutils and
base/gcc supply the system compiler, it will still be using
the system libc++ / libcxxrt instead of libstdc++ , despite a
gcc compiler type.

That will not mix well with, say, lang/gcc8 based materials
that are based on its libstdc++ when some involved libraries
from ports are built by the system cc/c++ and involve c++
library code.

It is the same sort of mix occurs for system-clang-8 as the
system cc/c++ when some ports libraries involving c++ library
code are built by clang and others are built byt the likes of
lang/gcc8 via USE_GCC is use. A recent example was (note the
use of both libstdc++ and libc++ / libcxxrt in the first two):

# ldd /usr/local/lib/qt5/bin/qlalr
/usr/local/lib/qt5/bin/qlalr:
        libQt5Core.so.5 => /usr/local/lib/qt5/libQt5Core.so.5 (0x8100b1000)
        libstdc++.so.6 => /usr/local/lib/gcc8/libstdc++.so.6 (0x81085e000)
        libc.so.7 => /lib/libc.so.7 (0x810ab7000)
        libkvm.so.7 => /lib/libkvm.so.7 (0x810e1c000)
        libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x810e41000)
        libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x810e5e000)
        libz.so.6 => /lib/libz.so.6 (0x810e71000)
        libicui18n.so.64 => /usr/local/lib/libicui18n.so.64 (0x810e9d000)
        libicuuc.so.64 => /usr/local/lib/libicuuc.so.64 (0x8112ac000)
        libpcre2-16.so.0 => /usr/local/lib/libpcre2-16.so.0 (0x81151e000)
        libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x8115ce000)
        libm.so.5 => /lib/libm.so.5 (0x81172e000)
        libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x811765000)
        libthr.so.3 => /lib/libthr.so.3 (0x81178e000)
        libelf.so.2 => /lib/libelf.so.2 (0x8117d7000)
        libutil.so.9 => /lib/libutil.so.9 (0x811804000)
        libicudata.so.64 => /usr/local/lib/libicudata.so.64 (0x81182e000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x81183f000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x811958000)
        libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x81198a000)
        libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x811a9c000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x811b45000)

# ldd /usr/local/lib/qt5/libQt5Core.so.5
/usr/local/lib/qt5/libQt5Core.so.5:
        libkvm.so.7 => /lib/libkvm.so.7 (0x8113ad000)
        libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8113d2000)
        libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8113ef000)
        libz.so.6 => /lib/libz.so.6 (0x811402000)
        libicui18n.so.64 => /usr/local/lib/libicui18n.so.64 (0x81142e000)
        libicuuc.so.64 => /usr/local/lib/libicuuc.so.64 (0x81183d000)
        libpcre2-16.so.0 => /usr/local/lib/libpcre2-16.so.0 (0x811aaf000)
        libglib-2.0.so.0 => /usr/local/lib/libglib-2.0.so.0 (0x811b5f000)
        libstdc++.so.6 => /usr/local/lib/gcc8/libstdc++.so.6 (0x811cbf000)
        libm.so.5 => /lib/libm.so.5 (0x811f18000)
        libgcc_s.so.1 => /usr/local/lib/gcc8/libgcc_s.so.1 (0x811f4f000)
        libthr.so.3 => /lib/libthr.so.3 (0x811f78000)
        libc.so.7 => /lib/libc.so.7 (0x810071000)
        libelf.so.2 => /lib/libelf.so.2 (0x811fc1000)
        libutil.so.9 => /lib/libutil.so.9 (0x811fee000)
        libicudata.so.64 => /usr/local/lib/libicudata.so.64 (0x812018000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x812029000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x812142000)
        libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x812174000)
        libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x812286000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x81232f000)

The libc++/libcxxrt use comes from libraries built with the
system c++ compiler toolchain instead of a lang/gcc* via
USE_GCC:

# ldd /usr/local/lib/libicui18n.so.64
/usr/local/lib/libicui18n.so.64:
        libicuuc.so.64 => /usr/local/lib/libicuuc.so.64 (0x81100f000)
        libicudata.so.64 => /usr/local/lib/libicudata.so.64 (0x811281000)
        libthr.so.3 => /lib/libthr.so.3 (0x811292000)
        libm.so.5 => /lib/libm.so.5 (0x8112db000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x811312000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x81142b000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x81145d000)
        libc.so.7 => /lib/libc.so.7 (0x810071000)

# ldd /usr/local/lib/libicuuc.so.64
/usr/local/lib/libicuuc.so.64:
        libicudata.so.64 => /usr/local/lib/libicudata.so.64 (0x810e72000)
        libthr.so.3 => /lib/libthr.so.3 (0x810e83000)
        libm.so.5 => /lib/libm.so.5 (0x810ecc000)
        libc++.so.1 => /usr/lib/libc++.so.1 (0x810f03000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x81101c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x81104e000)
        libc.so.7 => /lib/libc.so.7 (0x810071000)

By contrast, /usr/local/lib/qt5/libQt5Core.so.5 were built
via a lang/gcc* . As was /usr/local/lib/qt5/bin/qlalr .

The end result was that /usr/local/lib/qt5/bin/qlalr crashed
very early in its startup.

However, even the gcc 4.2.1 based system toolchain has the issue
of the version mismatch of its libstdc++ vs. one from the likes
of a lang/gcc* . This type of mismatch might lead to problems as
well.

All the involved libraries that in turn involve a c++ standard
library need to have been built by the same toolchain (including
an appropriate vintage match). This is so they are all using the
same c++ standard library. (Messy.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.