[Bug 288404] devel/boost-libs building problems to upgrade to boost-libs-1.88.0_2 on various FreeBSD versions 14.3, 13.5, 14/Stable and with pythons 3.11 to 3.13.7

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

--- Comment #14 from John Hein <jcfyecrayz@liamekaens.com> ---
(In reply to Jordan Ostreff from comment #13)
Your original post says that it fails with python 3.11.  Is that still true? 
There is no python313 nor python314 port in the FreeBSD ports tree yet.  See
the comment below about picking one environment to target.

You didn't answer the question from comment 11 (Can you reproduce the failure
with a clean environment like poudriere? Ideally with stock options to start
with).

That said, I tried devel/boost-libs in poudriere with the the options shown in
comment 11. It used devel/llvm21 this time instead of the default llvm. And I
went to the effort to manually created lang/python314 (from bug 282176) and
used that as the default python.  devel/llvm21 was built WITHOUT=DOCS to avoid
pulling in all the py-sphinx dependencies.  devel/boost-libs built without any
problem.  I used stable/13.5 on amd64 for this build.  I did not define the
CPUTYPE as you did in your make.conf.  I also did not define some of the
DEFAULT_VERSIONS you defined that seem unlikely to be related to the problem
(like gcc=14).

As noted in comment 4 and comment 11, I still cannot reproduce a build failure.

I suggest you try to reproduce it starting from a clean environment (again,
poudriere would be a good option or a fresh install from no ports) and provide
exactly what steps you took to reproduce it, document your environment, and
save logs of the build.  Even though you say it fails for you in multiple
environments, pick one environment for other people to investigate (exact base
OS version, list of dependent port versions, cpu info, and any optimization
settings). I understand you say you can reproduce this in multiple
environments, but picking one environment to focus one is most useful for
people trying to help you instead of dealing with a moving target.

It seems like you have some difference in your environment that only you have
visibility into.  Or perhaps the CPUTYPE optimization you're using makes a
difference, but you or someone else with that CPU will have to identify if that
is the case.  For example, maybe try building all your ports without that
setting.  Try starting with all the stock default settings and options and add
options one at a time until you can narrow down things to find a critical
condition that reproduces your failure and might help identify a root cause.

-- 
You are receiving this mail because:
You are the assignee for the bug.