<br><br>On Monday, November 22, 2021,  <<a href="mailto:mnieuw@zap.a2000.nl">mnieuw@zap.a2000.nl</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Building CinGG for aarch64.<br>
<br>
In multiple places in the build tree, ./configure reports that it cannot<br>
guess the build type. This is because "uname -p" returns unknown. I just<br>
found out that this is quite common. On arm, only a few distributions<br>
patch uname to return the same value as "uname -m" . Debian does not,<br>
but Fedora does. So I am ditching the Debian VM, and create a Fedora<br>
aarch64 VM instead. That will hopefully fix the "cannot build" error.</blockquote><div><br></div><div>try to study attached patch I made as part of effort to build Cin on elbrus machine. </div><div><br></div><div>there was plenty of places where autoreconf fixes things... </div><div><br></div><div>BUT i have not tested those modifications on more standard and older x86 distros.... (you hopefully can ignore nasm pieces, this was part of another patch) </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A second point is that any nasm call is obviously for the wrong<br>
CPU, so any product build that uses nasm should be disabled with a<br>
configure options.</blockquote><div><br></div><div>well, at least libopus as configured by cingg was building fine here ... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
MatN<br>
</blockquote>