<br><br>On Thursday, January 13, 2022, mat <<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"><div><div>On Thu, 2022-01-13 at 15:50 +0300, Andrew Randrianasulu wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div><br><br>On Thursday, January 13, 2022, mat <<a href="mailto:mnieuw@zap.a2000.nl" target="_blank">mnieuw@zap.a2000.nl</a>> wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div><div>On Thu, 2022-01-13 at 14:38 +0300, Andrew Randrianasulu wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div><br><br>On Wednesday, January 12, 2022, Phyllis Smith <<a href="mailto:phylsmith2017@gmail.com" target="_blank">phylsmith2017@gmail.com</a>> wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex;border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small">MatN and Andrew,</div><div class="gmail_default" style="font-size:small">I need clarification please.</div><div class="gmail_default" style="font-size:small">1) Thirdparty-Makefile-giflib.pat<wbr>ch that Mat attached is definitely needed and should be checked into GIT? probably yes?<br></div><div class="gmail_default" style="font-size:small">2) libaom-v3.2.0.patch1 that Andrew provided on Jan. 08; is this needed? probably not?<br></div><div class="gmail_default" style="font-size:small">3) have I missed some other changes? probably not?<br></div></div><div><br></div></blockquote><div><br></div><div>I can't comment much on libgif patch (Cingg worked dor me without it), but my patch only should have effect on Linux/arm, I do not have suitable chroot for testing, but from stackoverflow answers it seems __linux__ is right define, even if ANDROID and TERMUX are all-caps, and *BSD spelled with capitalization too, see example: <a href="https://www.boost.org/doc/libs/1_63_0/boost/config/platform/bsd.hpp" target="_blank">https://www.boost.org/doc/libs<wbr>/1_63_0/boost/config/platform/<wbr>bsd.hpp</a>) </div></blockquote><div><br></div><div><snip></div><div>I tested both again to make sure.</div><div>=== giflib ===</div><div>Without the giflib change:</div><div>Makefile:</div><div> giflib.cfg_params=echo "exec true" > ./configure; chmod +x ./configure;</div><div>log:</div><div> CONFIGURING giflib</div><div> cd giflib* && ./configure echo "exec true" > ./configure; chmod +x ./configure; </div><div>and the configure file is 0 bytes.</div><div><br></div><div>With the giflib change:</div><div>Makefile:</div><div> giflib.cfg_vars=echo "exec true" > ./configure; chmod +x ./configure;</div><div>log:</div><div> CONFIGURING giflib</div><div> cd giflib* && echo "exec true" > ./configure; chmod +x ./configure; ./configure </div><div>and the configure file is 10 bytes.</div><div><br></div><div>So, it builds without the fix because the last cmd is a chmod which return OK.</div><div>But it is by accident. So the fix should be in the git.</div><div><br></div><div>There are two more with bad configure files, I will look at them. The Makefile always</div><div>calls ./configure in the root of the unpacked source directory, so there should be </div><div>a configure script, which in case of unused, should return true.</div><div><br></div><div>== libaom patch====</div><div>The 20220108_Andrew patch for libaom, which changes __LINUX__ to __linux__ is not</div><div>needed for X86_64 builds, it builds fine with either.</div><div>However, it fails building on Debian_11/aarch64 compiling</div><div>libaom_v3.2.0/aom_ports/arm_cp<wbr>udetect.c .</div><div><br></div><div>With the patch, which lowercases __linux__, it builds fine.</div><div><br></div><div>So this fix should be in the git too.</div></div><br></blockquote><div><br></div><div>thanks a lot for time-consuming aarch64 testing! </div><div><br></div><div>and yeah, more consistent Makefile always better even for our own future reference! </div></blockquote><div><br></div><div>I hope to get it to compile on macOS too, because one programmer wanted to do that</div><div>and he has Apple only. Another programmer would be good.</div><div><br></div><div>I am also trying to have migrate the VMs to the system environment, but is is a steep learning curve,</div><div>and any web-found instructions are out of date.</div><div>If it runs as system, it might actually be faster. Plus, it might expose host hardware features,</div><div>like vaapi (not on arm, I think).</div></div></blockquote><div><br></div><div>there was patchset aimed at improved 3d/sound in qemu-user, back in 2016. But I guess it never landed fully</div><div><br></div><div><a href="https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05334.html">https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg05334.html</a></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"><div><div><br></div><div>MatN</div><div><br></div><div><span></span></div></div>
</blockquote>