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

In reply to: Mark Millard via freebsd-current : "Re: git: 5e6a2d6eb220 - main - Reapply: move libc++ from /usr/lib to /lib [add /usr/lib/libc++.so.1 -> ../../lib/libc++.so.1 ?]"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard via freebsd-current <freebsd-current_at_freebsd.org>
Date: Sat, 01 Jan 2022 02:20:46 UTC

On 2021-Dec-31, at 18:18, Mark Millard <marklmi@yahoo.com> wrote:

> On 2021-Dec-31, at 17:46, Mark Millard <marklmi@yahoo.com> wrote:
> 
>> 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
>> 
> 
> In a aarch64 context I looked at an old executable via ldd -a :
> 
> # ldd -a bt
> /usr/home/root/c_tests/bt:
> 	libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x41c19000)
> 	libc++.so.1 => /lib/libc++.so.1 (0x42484000)
> 	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x43038000)
> 	libm.so.5 => /lib/libm.so.5 (0x44a4c000)
> 	libc.so.7 => /lib/libc.so.7 (0x439ce000)
> /usr/lib/libexecinfo.so.1:
> 	libelf.so.2 => /lib/libelf.so.2 (0x4581e000)
> 	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x46e4f000)
> 	libc.so.7 => /lib/libc.so.7 (0x439ce000)
> /lib/libc++.so.1:
> 	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x43038000)
> 	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x46e4f000)
> 	libc.so.7 => /lib/libc.so.7 (0x439ce000)
> /lib/libcxxrt.so.1:
> 	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x46e4f000)
> 	libc.so.7 => /lib/libc.so.7 (0x439ce000)
> /lib/libm.so.5:
> 	libc.so.7 => /lib/libc.so.7 (0x439ce000)
> /lib/libelf.so.2:
> 	libc.so.7 => /lib/libc.so.7 (0x439ce000)
> /lib/libgcc_s.so.1:
> 	libc.so.7 => /lib/libc.so.7 (0x439ce000)
> 
> Looks like something already deals with finding
> /lib/libcxxrt.so.1 . But it is not obvious what
> path it started with and how much processing was
> done (or when) to end up with /lib/libc++.so.1
> showing.
> 
> But there is still a /usr/lib/ reference overall:
> 
> /usr/lib/libexecinfo.so.1
> 
> But this is because the old program turned out to
> be an old experiment:
> 
> # more bt.c 
> // bt.c
> // from releng/12 (12.2?) context (pre-llvm12), but not releng/13 :
> // # cc -o bt bt.c -lexecinfo
> // # ./bt
> // Rerun in llvm12 context, such as main after the switch: crash.
> 
> #include <execinfo.h>
> int main() {
>       void *addrlist[100];
>       backtrace(addrlist, 100);
> }
> 
> Although, for some reason, the executable was dated
> 2021-Jul-15, not that I remember why I'd rebuilt it
> then.
> 
> # file bt
> bt: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.0 (1400025), FreeBSD-style, with debug_info, not stripped
> 
> nm -a bt shows:

That should have referenced: elfdump -a bt | more

> entry: 0
>        d_tag: DT_NEEDED
>        d_val: libexecinfo.so.1
> 
> None of the DT_NEEDED entries had paths shown.
> 
> The only /usr/lib/ reference was:
> 
> entry: 65
>        st_name: /usr/lib/crti.o
>        st_value: 0
>        st_size: 0
>        st_info: STT_FILE STB_LOCAL
>        st_shndx: 65521
> 
> Overall: backtrace requires /usr/lib/ accessibility
> for main-n252090-5650d340ad66 in order to access
> /usr/lib/libexecinfo.so.1 .
> 
> For reference:
> 
> # uname -apKU
> FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #34 main-n252090-5650d340ad66-dirty: Fri Dec 31 06:30:22 PST 2021     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1400046 1400046



===
Mark Millard
marklmi at yahoo.com