Re: Base libc++ missing symbol

> The procedure of seeing if the a.out is produced without complaint
> might still be useful.

The program compiles & links fine, but then also fails to run:

ld-elf.so.1: Undefined symbol "_ZTVNSt3__13pmr25monotonic_buffer_resourceE" referenced from COPY relocation in /usr/home/jbo/junk/a.out

I made no progress on this. I have reinstalled world twice (from different
commits) and I re-installed all packages multiple times (also from different
ports tree commits).

Any other wild ideas on how to fix this? None of my other machines have any
issues whatsoever running on the same or similar stable/13 commit and using
the same poudriere repository.

This is certainly not Qt5 related. I run into the exact same issue with
anything that uses Qt6. Furthermore, the test program we built experiences
the same issue without any involvement of the Qt libraries.


Best regards,
~ jbo



------- Original Message -------
On Tuesday, October 3rd, 2023 at 02:48, Mark Millard <marklmi@yahoo.com> wrote:


> 
> 
> On Oct 2, 2023, at 15:56, Mark Millard marklmi@yahoo.com wrote:
> 
> > Joel Bodenmann <jbo_at_FreeBSD.org> wrote on
> > Date: Mon, 02 Oct 2023 20:00:29 UTC :
> > 
> > > It seems like I finally managed to hose a FreeBSD system.
> > > The machine in question is my workstation at home. It has been running
> > > stable/13 without any problems. Yesterday I've updated to
> > > ef295f69abbffb3447771a30df6906ca56a5d0c0 and since then I'm getting an
> > > undefined symbol on anything using Qt:
> > > 
> > > ld-elf.so.1: /usr/local/lib/qt5/libQt5Widgets.so.5: Undefined symbol
> > > "_ZTVNSt3__13pmr25monotonic_buffer_resourceE"
> > > 
> > > Unless I'm missing something, it would seem like my base libc++
> > > is missing the pmr::monotonic_buffer_resource symbol.
> > 
> > I do not have a 13.2 context, so you may want to run the
> > analogous steps in your context for confirming/denying
> > the below applies.
> > 
> > # llvm-cxxfilt _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> > vtable for std::__1::pmr::monotonic_buffer_resource
> > 
> > Using the example "Run this code" source from:
> > 
> > https://en.cppreference.com/w/cpp/memory/monotonic_buffer_resource
> > 
> > # c++ -std=c++17 -pedantic -O2 monotonic_buffer_resource.cpp
> > 
> > # objdump -x a.out | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> > 0000000000204160 g O .bss.rel.ro 0000000000000038 _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> > 
> > # nm a.out | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> > 0000000000204160 B _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> > 
> > # ./a.out
> > t1 (default std alloc): 0.491 sec; t1/t1: 1.000
> > t2 (default pmr alloc): 0.541 sec; t1/t2: 0.906
> > t3 (pmr alloc no buf): 0.188 sec; t1/t3: 2.616
> > t4 (pmr alloc and buf): 0.155 sec; t1/t4: 3.172
> > 
> > Note that the vtable is in the a.out instead of being from
> > a library. It is global but is in the a.out .bss.rel.ro http://bss.rel.ro/ in
> > the example and is defined.
> > 
> > > At first I thought I might have messed up on installworld but rolling
> > > back to the previous boot environment and then performing the same
> > > procedure again lead to the same outcome.
> > 
> > If the above works similarly in your context, then I expect
> > that the issue is on the qt5 or port side of things, not the
> > system libraries/headers.
> > 
> > As I understand, clang++ 16 is the first vintage with this
> > directly supported, instead of being just in the experimental
> > category/area for libc++. May be tracking that transition is
> > at issue.
> > 
> > For reference:
> > 
> > # c++ -v
> > FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152)
> > Target: x86_64-unknown-freebsd15.0
> > Thread model: posix
> > InstalledDir: /usr/bin
> > 
> > # uname -apKU
> > FreeBSD amd64-ZFS 15.0-CURRENT FreeBSD 15.0-CURRENT #124 main-n265447-e5236d25f2c0-dirty: Thu Sep 21 09:06:08 PDT 2023 root@amd64-ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1500001 1500001
> > 
> > > Any ideas or wild guesses? Anything obvious I'm missing here?
> > > 
> > > uname -a
> > > FreeBSD beefy02 13.2-STABLE FreeBSD 13.2-STABLE
> > > stable/13-n256443-ef295f69abbf GENERIC amd64
> > > 
> > > freebsd-version -kru
> > > 13.2-STABLE
> > > 13.2-STABLE
> > > 13.2-STABLE
> > > 
> > > clang --version
> > > FreeBSD clang version 16.0.6
> > > (https://github.com/llvm/llvm-project.git
> > > llvmorg-16.0.6-0-g7cbf1a259152) Target: x86_64-unknown-freebsd13.2
> > > Thread model: posix
> > > InstalledDir: /usr/bin
> 
> 
> Given Dimitry Andric's notes:
> 
> # objdump -x /lib/libc++.so.1 | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> 00000000001006d8 g O .data.rel.ro 0000000000000038 _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> 
> # nm /lib/libc++.so.1 | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> 00000000001006d8 D _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> 
> So /lib/libc++.so.1 has a global symbol naming initialized data
> for this in my context.
> 
> Reminder for the a.out:
> 
> # objdump -x a.out | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> 0000000000204160 g O .bss.rel.ro 0000000000000038 _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> 
> # nm a.out | grep _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> 0000000000204160 B _ZTVNSt3__13pmr25monotonic_buffer_resourceE
> 
> My original thinking makes no sense for this. Sorry for the noise.
> 
> The procedure of seeing if the a.out is produced without complaint
> might still be useful.
> 
> ===
> Mark Millard
> marklmi at yahoo.com