Re: net/asterisk22: Illegal instruction

Am Tage des Herren Sun, 22 Jun 2025 15:14:08 +0200
Guido Falsi <mad@madpilot.net> schrieb:

> 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.
> 

Just an update on the matter: disabling (explicitely) the "OPTIMIZED_CFLAGS" option on both
net/asterisk20 and net/asterisk/22 solved the problem for me. But simply disabling and
recompiling didn't do the trick alone, I also "cleaned" up the whole repo and started from
scratch - it took its time. Maybe also a small change in the 14-STABLE environment also did
the salvation, I do not know. Lesson learned. Next time I take away all optimizations before
complaining ... ;-)

Kind regards and thanks,
Oliver

-- 

A FreeBSD user