On 6/22/25 14:52, A FreeBSD User wrote:
Am Tage des Herren Sat, 21 Jun 2025 15:16:40 +0200
Guido Falsi <[email protected]> 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 <[email protected]>
