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