Re: git: ebbef4b5f84b - main - devel/boost*: update Boost to 1.81.0 release (+)

Ah!

Forgot to attach patch itself

https://people.freebsd.org/~fluffy/-patches/0001-Try-to-fix-Boost.URL-based-on-upstream-MRs.patch

On 18.01.2023 18:27, Dima Panov wrote:
> Moin-moin!
> 
> Just curious, will this patch fix the build on the clean -current with enabled assertions?
> 
> Boost.URL is a new lib and can be buggy :(
> 
> 
> On 17.01.2023 17:17, Guido Falsi wrote:
>> On 17/01/23 13:49, Charlie Li wrote:
>>> Guido Falsi wrote:
>>>> BTW I'm seeing similar failure in libdispatch (required by telegram desktop) which also happens on the cluster:
>>>>
>>> I originally filed PR 268019 about assertions failing on devel/libdispatch. Know that base LLVM on -CURRENT (and possibly more) have assertions enabled by default, so any setup without assertions enabled (including port LLVM) will not hit this problem.
>>>
>>
>> Good catch, now I get it.
>>
>> Not sure how this is best managed.
>>
>> I think the ports should not fail like this. I was preparing patches to force these ports on llvm 15 from ports. It would work, but would be overkill, most probably. Could also introduce other issues maybe.
>>
>> For my own use I can rebuild head without assertion, no problem with that. Is this what we should be doing and tell users to do on head?


>>
>> Are we sure such assertions are disabled on STABLE and releases?

Sure, yes. And MALLOC_PRODUCTION is set for any non-current (AFIU it force WITHOUT_LLVM_ASSERTIONS because my jails only set this one)


-- 
Sincerely,
Dima (fluffy@FreeBSD.org, https://t.me/FluffyBSD)
(desktop, kde, x11, office, ports-secteam)@FreeBSD team