Re: net/asterisk22: Illegal instruction

Am Tage des Herren Sun, 22 Jun 2025 15:35:27 +0200
Daniel Engberg <diizzy@FreeBSD.org> schrieb:

> On 2025-06-22 15:14, Guido Falsi wrote:
> > On 6/22/25 14:52, A FreeBSD User wrote:  
> >> Am Tage des Herren Sat, 21 Jun 2025 15:16:40 +0200
> >> Guido Falsi <mad@madpilot.net> schrieb:
> >>  
> >>> On 6/21/25 14:17, A FreeBSD User wrote:  
> >>>> Hello,
> >>>>
> >>>> After a recent upgrade of a 14-STABLE (14.3-STABLE #0 
> >>>> n271755-ef360183df81: Sat Jun 21
> >>>> 11:23:41 CEST 2025 amd64) appliance and net/asterisk22 (poudriere 
> >>>> build, builder host is
> >>>> also 14-STABLE, just for the record) the asteriks binzry quits with
> >>>>
> >>>> Illegal instruction (platform: PCEngine APU4C2, hw.model: AMD 
> >>>> GX-412TC SOC).
> >>>>
> >>>> Does anybody see this issue, too?
> >>>>  
> >>>
> >>> If I understand correctly you are building binaries yourself.  
> >>
> >> That is correct.
> >>  
> >>>
> >>> Do you use any optimization options, especially -march and similar 
> >>> ones?  
> >>
> >> I;m not aware of using optimizations on net/asterisk* ports themselfs 
> >> but I have made a "make
> >> rmconfig config" recently due to the same thought as of yours. On 
> >> net/asterisk, I haven't
> >> changed anything within the past few months, but I also do not track 
> >> versions, my fault - so
> >> the statement is a kind of useless. I also have no clue about faulty 
> >> optimizations in
> >> adjacent/required ports like those mutually transcribing codecs which 
> >> are candidates for
> >> vectore unit optimizations, I guess. What happened is: I exchanged my 
> >> builder platform from
> >> Intel based, much outdated Xeon Ivybridge to recent AMD Zen 5 based 
> >> equipment. While  in the
> >> bureau an older dual socket Intel Xeon performs the same task without 
> >> problems, first guess is
> >> a problem with compiling AMD Zen5 code.  
> >
> > The change in build CPU could definitely be relat4ed to what you're 
> > seeing.
> >  
> >>>
> >>> The error could be caused by a binary optimized for a newer arch
> >>> supporting features (so instructions) not supported by the actual CPU
> >>> you're using.
> >>>
> >>> It is quite possible that with the same optimizations the previous
> >>> version used to work and the newer one does not. Maybe the code in the
> >>> old version did not cause the compiler to output any instructions not
> >>> compatible with your CPU, while some code in the new version does.
> >>>
> >>>
> >>> This is just one possibility though, maybe there are more possible 
> >>> causes.
> >>>  
> >> That possibility sounds reasonable, see my comment on the hardware 
> >> vendor change of the CPU. I
> >> disabled all optimization flags as far I got a handle on them and/or 
> >> being aware of, so the
> >> host is just right now a complete new repository for 14-STABLE. It 
> >> did not help just disabling
> >> the optimization flag on both net/asterisk20 and net/asterisk22 (both 
> >> suffer from the same
> >> issue). Will report back.  
> >
> > Check make.conf for any options. Also, build logs usually have 
> > compiler command lines, check those for any "-m" options, like 
> > "-mnative". If you have anything similar you should make them go away, 
> > but discovering what is adding those to the command line could be 
> > challenging.
> >
> > But I forgot asterisk has an "OPTIMIZED_CFLAGS" option.
> >
> > Looking at the Makefile that is most probably your problem, with that 
> > flag asterisk is adding the "-mnative" option (or something equivalent 
> > and will optimize for the CPU it is building on, taking advantage of 
> > all its features, so the resulting binary could fail like yours on 
> > another machine with a "simpler"(less featureful) CPU.
> >  
> Hi,
> 
> We should never set -march=native even using options for a number of 
> reasons as it is fragile and can be unpredictable, it also breaks builds 
> on some non x86 platforms. Ideally all ports should adhere to what 
> CPUTYPE is set to and not override it by adding for example -mavx and so 
> on. Unfortunately that can be a bit hard as some projects relies on 
> custom variables to be defined rather than the generic compiler ones.
> 
> Best regards,
> 
> Daniel
> 
> 
> 

Well, as long as one stays in the same "architectural realm" for both the OS and the binaries,
I have no problems with setting "-mnative" - at least, I do this now for a couple of years
with FreeBSD. But when it comes to the point one wishes to compile binaries he doesn't know
exactly the target architecture, this is a source of neverending pain - aggreed on that.

So, my poudriere environment runs on binaries (self compiled from sources) with the
"official/neutral" settings and I had no problems so far with that.

Best regards
oh

-- 

A FreeBSD user