Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?]

From: Mark Millard via freebsd-current <freebsd-current_at_freebsd.org>
Date: Sat, 01 Jan 2022 01:46:19 UTC

On 2021-Dec-31, at 15:04, John Baldwin <jhb@freebsd.org> wrote:

> On 12/31/21 2:59 PM, Mark Millard wrote:
>> On 2021-Dec-31, at 14:28, Mark Millard <marklmi@yahoo.com> wrote:
>>> On 2021-Dec-30, at 14:04, John Baldwin <jhb@freebsd.org> wrote:
>>> 
>>>> On 12/30/21 1:09 PM, Mark Millard wrote:
>>>>> On 2021-Dec-30, at 13:05, Mark Millard <marklmi@yahoo.com> wrote:
>>>>>> This asks a question in a different direction that my prior
>>>>>> reports about my builds vs. Cy's reported build.
>>>>>> 
>>>>>> Background:
>>>>>> 
>>>>>> /usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/tmp/usr/lib/libc++.so:GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so
>>>>>> and:
>>>>>> lrwxr-xr-x  1 root  wheel        23 Dec 29 13:17:01 2021 /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1
>>>>>> 
>>>>>> Why did libc++.so.1 not get a:
>>>>>> 
>>>>>> /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1
>>>>> I forgot to remove the .1 on the left hand side:
>>>>> /usr/lib/libc++.so -> ../../lib/libc++.so.1
>>>> 
>>>> Because for libc++.so we don't just symlink to the current version of the library
>>>> (as we do for most other shared libraries) to tell the compiler what to link against
>>>> for -lc++, instead we use a linker script that tells the compiler to link against
>>>> both of those libraries when -lc++ is encountered.
>>> 
>>> A better identification of what looks odd to me is the
>>> path variations in:
>>> 
>>> # more /usr/lib/libc++.so
>> Another not great day on my part: That path alone makes
>> the mix of /lib/ and /usr/lib/ use involved, given the
>> reference to /lib/libc++.so.1 . That would still be true
>> if the other path had been /lib/libcxxrt.so .
> 
> /usr/lib/libc++.so is only used by the compiler/linker when linking a binary.
> The resulting binary has the associated paths (/lib/libc++.so.1 and
> /usr/lib/libcxxrt.so.1) in its DT_NEEDED.  So it is fine for the .so to be
> in /usr/lib.  This is the same with /usr/lib/libc.so vs /lib/libc.so.7.
> 
> However, your point about libcxxrt.so.1 is valid.  It needs to also be moved
> to /lib if libc++.so.1 is moved to /lib.  Doing so will also require yet another
> depend-clean.sh fixup (well, probably just adjusting the one I added to
> check the libcxxrt path instead of libc++ path).

Hmm. Looking (now after having updated so /lib/libc++.so.1
is in use, not that this is any different here):

# ls -Tld /lib/libcxx* /usr/lib/libcxx*
-r--r--r--  1 root  wheel  131656 Dec 31 14:19:49 2021 /lib/libcxxrt.so.1
-r--r--r--  1 root  wheel  355764 Dec 24 15:19:42 2021 /usr/lib/libcxxrt.a
lrwxr-xr-x  1 root  wheel      23 Dec 31 14:19:49 2021 /usr/lib/libcxxrt.so -> ../../lib/libcxxrt.so.1

# more /usr/lib/libc++.so 
/* $FreeBSD$ */
GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so )

So: no actual reference to /usr/lib/libcxxrt.so.1 but
a reference in the DT_NEEDED to /usr/lib/libcxxrt.so ?

May be just /usr/lib/libc++.so needs different text in order
for DT_NEEDED to have different text related to libcxxrt in
future build activities, avoiding /usr/lib/ ?


For reference:

# uname -apKU
FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #27 main-n252090-5650d340ad66-dirty: Fri Dec 31 06:00:41 PST 2021     root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG  amd64 amd64 1400046 1400046

===
Mark Millard
marklmi at yahoo.com