Nicky Dasmijn

And why did you suggest it then last night? Anyway with changing a header I can get to SLPlugin, then it's trying to link apr the first time. apr is one of the libs linked to a too recent glibc and unsurprisingly that fails and stops the build for good 39%] Linking CXX executable SLPlugin /usr/bin/ld: /source/linden/indra/../lib/release/libapr-1.so: undefined reference to `pthread_sigmask@GLIBC_2.32' collect2: error: ld returned 1 exit status make[2]: *** [llplugin/slplugin/CMakeFiles/SLPlugin.dir/build.make:102: llplugin/slplugin/SLPlugin] Error 1 make[1]: *** [CMakeFiles/Makefile2:913: llplugin/slplugin/CMakeFiles/SLPlugin.dir/all] Error 2 make: *** [Makefile:91: all] Error 2 [1] 26284 exit 2 make

Those lines are for Darwin, not for Linux. Changing c++17 to gnu++17 did not help. What helps is changing 'asm' to '__asm__' in se2neon.h:8815

The first one (about post memalign) is a warning treated as error. The next two about the inline assembly are real errors and would not go away by disabling -Werror. The resulting binary btw would not run, there is a few libraries that are compiled with a more recent GLIBC (2.32) than the official Rasperry Distribution (Debian 11/bullseye, GLIBC 2.31) ships.

I saw those two SBCs in your earlier post and bookmarked them. Will be interesting to see what will come out of them. I cannot: There a curl prebuild with a wrong md5 in install.xml (87d52583fcf2cffb7ca3a61a4d1c1623 curl-7.47.0-aarch64-20220621.tar.bz2 would be correct) After fixing that there is more severe errors: [ 9%] Building C object libopenjpeg/CMakeFiles/openjpeg.dir/jp2.c.o In file included from /source/linden/indra/libopenjpeg/dwt.c:35: /source/linden/indra/../include/sse2neon.h: In function ‘_mm_malloc’: /source/linden/indra/../include/sse2neon.h:1967:10: error: implicit declaration of function ‘posix_memalign’ [-Werror=implicit-function-declaration] 1967 | if (!posix_memalign(&ptr, align, size)) | ^~~~~~~~~~~~~~ In file included from /source/linden/indra/libopenjpeg/dwt.c:35: /source/linden/indra/../include/sse2neon.h: In function ‘_rdtsc’: /source/linden/indra/../include/sse2neon.h:8815:5: error: ‘asm’ undeclared (first use in this function) 8815 | asm volatile("mrs %0, cntvct_el0" : "=r"(val)); | ^~~ /source/linden/indra/../include/sse2neon.h:8815:5: note: each undeclared identifier is reported only once for each function it appears in /source/linden/indra/../include/sse2neon.h:8815:8: error: expected ‘;’ before ‘volatile’ 8815 | asm volatile("mrs %0, cntvct_el0" : "=r"(val)); | ^~~~~~~~~ | ; cc1: all warnings being treated as errors make[2]: *** [libopenjpeg/CMakeFiles/openjpeg.dir/build.make:104: libopenjpeg/CMakeFiles/openjpeg.dir/dwt.c.o] Error 1 make[2]: *** Waiting for unfinished jobs....

So I figured I use a rainy sunday to go down into my devil's workshop, pull out my old rpi port and see if it still works. For the authentic experience I did all the compiling on a RPI 4 that has 8GB. - Rebuilding the 3p libraries takes about 110 to 120 minutes. - Building the viewer took about 8 to 9 hours (not sure, I roughly came back home after that time it look if it was done) Time it took me to port my old changes and fix some new issues not included. But tada To answer @Monty Linden darkest and deepest hunger for knowledge: Yes, it can be done. Should it be done, lolnope. The viewer runs like a slow mess with 4 FPS as can be seen.

--skipupdatecheck is only works as an argument for the viewer indeed. It will stop the viewer from using the autoupdater. I wasn't aware that the installer does an update check without asking ... That sounds quite silly.

As much as 32 bit is on it's asthmatic last breats and should goaway, it does not help the OP uless they get a new PC or a new GPU LL is still listing 32 Bit viewers for current release, maint and project viewers here https://releasenotes.secondlife.com/viewer.html So I think calling them stopping x86 support is a bit too early. After installing the 32 bit viewer --skipupdatecheck can be used as a command line argument if the update gets in your way wanting to put an x64 bit viewer on your system

Not to forget any contribution can sit an arbitrary amount of time till it's out of date. *coughs coughs* Linux that sat there for so many month (or was it years?) that it finally got into the bit ether when hg -> git happened and Bitbucket did remove all mercurial repositories. I suppose then Oz could finally claim once again "We never get or got anything for Linux"

More of the "all that" .... @animatsI am curious if your client is open source/you are willing to share the source?

@Drakeo thank you for your report, I too had problems to reproduce that log spam on my machines. With the current changes, as mygoditsfullofstars wrote, the GPU is on again and I hope no one is getting that amount of spam.

Did that. It gave me about 10 FPS in an empty sandbox

There's an option to let the OpenCollar protocol disable the client AO (You find it in Prefs->Firestorm->Avatar) this is done via the bridge. What you see is the bridge trying to detect if there is a collar worn. When you disable that option in preferences the whisper should go away.

If someone really wanted something as close as possible to Linden Labs viewer there's a flatpak repository at: https://flatpak.firestormviewer.org/viewer.flatpakrepo It is currently at 6.4.1 (Which is 6.4.0 EEP). Of course it is all unsupported and not official from LL I try to keep this as close in sync with LLs releases a possible. It lacks: - KDU (do not have the LL sources for this and do not want to use the Firestorm version I officially got). - FMODEX, I am going to include FMODSTUDIO when LL switches to it. - Havok, again no access to the LL version, but one can still dream.