Re: Base libc++ missing symbol

I've updated to commit c11f71789d7d8f741243c21add8d7c5f0ecea03e
and the problem is still present.

> So far I've never reproduced your problem or anything like it.
> 
> (I prefer testing official builds for problem isolation. If
> only my personal builds fail, then it is likely my build's
> problem.)

Yeah, I couldn't reproduce this either. I have no clue what is
going on here.

I'm honestly a bit lost on this one. I have not encountered
anything like this before. None of my other machines are 
displaying this problem wile running on the same stable/13
branch (and one machine even on the exact same commit).

Current system info:

# uname -apKU
FreeBSD beefy02 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256520-c11f71789d7d GENERIC amd64 amd64 1302508 1302508

# freebsd-version -kru
13.2-STABLE
13.2-STABLE
13.2-STABLE

# c++ --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

------- Original Message -------
On Monday, October 9th, 2023 at 08:35, Mark Millard <marklmi@yahoo.com> wrote:


> 
> 
> <jbo_at_insane.engineer> wrote on
> 
> Date: Sun, 08 Oct 2023 18:13:16 UTC :
> 
> > > 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
> 
> 
> Well, for stable/13 's recent snapshot, freshly dd'd to USB3 media,
> so an official build, not a personal one that might be odd in some way:
> 
> # uname -apKU
> FreeBSD generic 13.2-STABLE FreeBSD 13.2-STABLE stable/13-n256505-2464d8c5e296 GENERIC arm64 aarch64 1302508 1302508
> 
> (So, after 2023-Oct-01's ef295f69abbf that you originally referenced: 2023-Oct-04's 2464d8c5e296.)
> 
> # c++ -v
> FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152)
> Target: aarch64-unknown-freebsd13.2
> Thread model: posix
> InstalledDir: /usr/bin
> 
> # c++ -std=c++17 -pedantic -O2 monotonic_buffer_resource.cpp
> 
> # ./a.out
> t1 (default std alloc): 1.827 sec; t1/t1: 1.000
> t2 (default pmr alloc): 1.818 sec; t1/t2: 1.005
> t3 (pmr alloc no buf): 0.920 sec; t1/t3: 1.986
> t4 (pmr alloc and buf): 0.606 sec; t1/t4: 3.015
> 
> The example is from in an aarch64 context. It does not
> agree with your report.
> 
> > I made no progress on this.
> 
> 
> So far I've never reproduced your problem or anything like it.
> 
> (I prefer testing official builds for problem isolation. If
> only my personal builds fail, then it is likely my build's
> problem.)
> 
> > I have reinstalled world twice (from different
> > commits) and I re-installed all packages multiple times (also from different
> > ports tree commits).
> 
> 
> I suggest trying the most recent stable/13 snapshot build at
> the time of the experiment.
> 
> No packages are used/needed for the monotonic_buffer_resource.cpp
> test. This fits well with using a snapshot context for such a
> test.
> 
> > Any other wild ideas on how to fix this?
> 
> 
> I've no evidence about your stable/13 build/install. But the
> official snapshot that I tried worked just fine.
> 
> > None of my other machines have any
> > issues whatsoever running on the same or similar stable/13 commit and using
> > the same poudriere repository.
> 
> 
> That, with my results, tends to suggest you have one odd ball
> context that has a problematical FreeBSD build/install. Again,
> I've no evidence to work with relative to that build/install.
> 
> > 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.
> 
> 
> 
> There was no problem for my testing of monotonic_buffer_resource.cpp
> via the recent official snapshot build of stable/13 .
> 
> I've not tried to test Qt5 or Qt6, sticking with the simpler/smaller
> context that you also report as failing in the odd context. I suggest
> avoiding Qt5/Qt6 testing until you have a context with the
> monotonic_buffer_resource.cpp test working.
> 
> ===
> Mark Millard
> marklmi at yahoo.com