Re: net/asterisk22: Illegal instruction

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.

-- 
Guido Falsi <mad@madpilot.net>