search

AresValley / Artemis

Radio Signals Recognition Manual
https://aresvalley.github.io/Artemis/
GNU General Public License v3.0
390 stars 43 forks source link

Official Linux EXE's don't work on Raspberry Pi 3B+/4B. Building on Pi does work though #18

Closed WheezyE closed 4 years ago

WheezyE commented 4 years ago

I just added a post to the Artemis forums about how the official Linux binaries won't run on the Raspberry Pi 3B+ or 4B, but wanted to post my bash script here too in order to outline the problem and show that I was able to run Artemis 3.2.0 on my Pi by building on the Pi.

I'm curious if an executable built on the Pi might work on other non-ARM Linux systems, or if the Artemis website might consider providing a RPi binary in addition to the Linux one.

Bash code here: Build Artemis 3 2 0 from source for RPi3-4.txt [Edit:] Also providing my compiled binaries here in case anybody just wants to use those (219.25MB).

WheezyE commented 4 years ago

Thank you MarcoDT for adding compiled Pi binaries to the main download page! I'll continue refining the bash script I posted above so that it's more automatic. I'll make a pull request to include the script in the git soon, as requested :)

AresValley commented 4 years ago

Thanks to you! We're looking forward to it. In the meantime, I will do some tests with your script to verify the repeatability with my "new" raspberry pi 2 (not so new actually, but it is better than nothing and should work as well)

WheezyE commented 4 years ago

I’m nearly done getting the script to run without needing user input. I’m just trying to figure out how to put some error correction into it (I’m going to have it detect if the system already has pyenv installed, and skip pyenv installation if so)

Here’s a revised version so you can just let it run for three hours unattended if you like (or in the background - Netflix or dishes were what I did lol)

https://pastebin.com/CCYrJXkz

Edit: I downloaded the file from pastebin to the spec_files/Linux directory, then had to use dos2unix to make it work on the pi. (Then chmod +x ... and ./... to execute it)

AresValley commented 4 years ago

Excellent, thanks Eric! I successfully configured my RPI2 with raspian, and right now, your script it's up and running well. I followed your instructions and it's still compiling...as your suggestion, I'll check again in few hours

AresValley commented 4 years ago

Here we are! I'm here with some news: to be honest, I didn't expect to succeed with the hardware of Raspberry Pi 2 (you correctly pointed out that the minimum requirement is the RPi 3), but I was wrong. Your script apparently finishes without critical error, but when I tried to launch the Artemis executable, an error due to a missing PyQt5 library popped up. I rechecked your script and I discovered an error during pyinstaller compilation about a hook related to PyQt5, so I scrolled up to the PyQt5 compilation from source and what I discovered is a problem with qmake (the available version is too old and PyQt cannot be compiled successfully). Everything else seems to work flawlessly. Right now I'm following this guide (https://www.tal.org/tutorials/building-qt-512-raspberry-pi) because, as far as I know, the compilation from the source of PyQt 5 is not only architecture dependant but also machine dependant (different compiler flags for different versions of RPi). I'll let you know as soon as I have new results 👍 (and I'll reopen this issue as well in order to facilitate the problem resolution)

WheezyE commented 4 years ago

Ah man. Does the pre-compiled exe work on Pi 2? I’m currently trying to build on a RPi 0W running Raspbian Buster to see what will happen and will report in too when I know more.

If we can use apt-get to install PyQt5 instead of compiling, maybe we can get around the qmake issue. I’ll try to modify my script just for testing so it installs other PyQt5 versions with other pythons each in their own virtual environment to see if an apt-get PyQt5 might work ok

AresValley commented 4 years ago

Well, PyQt 5 compilation (version 5.12.2) is taking over 12 hours now following the tutorial (mentioned in the previous post). It's a really slow process: I think it's going to run smoothly after all because the only little problem of your script (at least for me, with a fresh raspian on RPi2) was about PyQt and the executable works flawlessly. The problem is only about PyQt compilation, so your solution could be valid: as your suggestion, we can try to use an ARM precompiled version available on the official repo (I saw some older version...something around 5.11.x). Everything else seems to work correctly. I'm pretty curious about RPi 0 because it is even smaller compared to an RPi2... it should be quite a challenge

WheezyE commented 4 years ago

I successfully ran the pre-compiled binary (the one I compiled on RPi 3B+ with the script) on my RPi 0W (Raspbian Buster) today at work. Artemis takes about three and a half minutes to open on the RPi 0W, but once it's open it runs great without any slowdowns. I haven't tested audio since I don't have a soundcard for the RPi0W, but I'll report in on that maybe next week when I'm back in my office.

When I tried to use my compile script on the RPi0W, I got the same qmake error you got on the RPi2 when trying to compile PyQt5 5.12.2:

Error: Use the --qmake argument to explicitly specify a working Qt qmake.
qmake not compatible for building PyQt5

I got a similar qmake error when trying to use "python -m pip install pyqt5" too. I'll try apt-get or try finding a workaround for qmake if I can. Maybe we'll just have to compile on a 3B+ and distribute the pre-made binary to older Pi's.

As a separate issue: I also tried the pre-compiled binary (made on RPi 3B+ Buster) on an RPi 3B(not plus) running Raspbian Stretch, but got the glibc out of date error

[1449] Error loading Python lib '/tmp/_MEIATNM1X/libpython3.7m.so.1.0': dlopen: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/_MEIATNM1X/libpython3.7m.so.1.0)

I was not able to resolve it with "sudo apt-get install libc6". But, reading through your guys' other threads here on GLIBC, I'll try compiling Artemis on RPi3B(not plus) with Raspbian Jessie and see if that exe runs on all my RPi's (0W, 3B, 3B+, 4B) running Raspbian Buster. I'll give it a shot on 3B running Stretch again too.

WheezyE commented 4 years ago

Minor updates:

EDIT 4/17/20: The total Artemis build on the 0W took almost exactly 12 hours. I also built on the 4B, which only took 1 hour and 26 minutes.

AresValley commented 4 years ago

Cool! Regarding what you wrote yesterday: yeah, the only way that I was able to find in order to avoid the qmake error (that you were able to reproduce on your RPi0W) is to follow the tutorial on tal.org. The compilation was successful after almost 24h (yeah, almost an entire day. For a 'production' built is completely unfeasible but I read that you found a nice workaround!). I quickly fixed the essential environmental variable to link the new PyQt, and, in the end, I successfully compiled Artemis with your script (skipping the PyQt and SIP part, of course). The software is running smoothly, and the startup requires less than a minute. So, as I thought, as soon as the qmake trouble is solved, your script works perfectly. It's really interesting to hear that you found another way to solve this annoying issue. Tomorrow I'll try your solution installing the qt5-default library. Anyway, regarding the GLIBC problem: yes, you got it right. In principle, if you are able to create a built on an old system, there should be no problems with running these executables on a new one. Yeah, basically GLIBC is backward compatible, but not forward compatible, and I think there are no easy/safe ways to change the system libc package since it's directly used/linked to the system resources. Don't worry, I'll wait for your news and I'll post any update as well. When you have time, of course! :)

WheezyE commented 4 years ago

Nice job! I had tried to build Qt in a previous attempt to build Artemis and wasn't able to get it to compile. I also had heard that it takes a very long time.

Thanks for the info that GLIBC is integral and can't be changed. That info will save me a lot of time (I was going to try to get an old GLIBC on Buster). I'll get to work trying to build on Raspbian Jessie on my 3B, which is as far back in software as I can go with any of my Pi's. Maybe you could try installing Raspbian Wheezy on your Pi 2 and building from that first operating system version?

I have some good news: The 0W completed its build and Artemis ran just fine. I also compiled on the 4B. [EDIT:] Oh my goodness, the 0W and the 4B did not produce files with the same hashes - I reported that incorrectly on this post and am correcting it now. I'll test the binaries on each platform to make sure each binary is able to run on every Pi.

RPi 4B

Get size and sha256

File name: Artemis_linux.tar.gz
Size (KB): 98493.112
Hash code: 1aae4bc38c43fd9be6dbcb88d9f1acff701f77cfe1fe41650a1d93ac427f66ad
--------------------------------------------------------------------------------
File name: _ArtemisUpdater_linux.tar.gz
Size (KB): 46681.898
Hash code: d532c5c102ec89215005bf52adb4fbfb469b8c3b55c227fede5bbfc35f1f1bd2
--------------------------------------------------------------------------------
File name: ArtemisWebDownlaod_linux.tar.gz
Size (KB): 145187.807
Hash code: 3d3981c6ba10f56becac876b0e2a81f426291091613761d26dcbd3ddd8a57a98
--------------------------------------------------------------------------------

RPi 0W

Get size and sha256

File name: Artemis_linux.tar.gz
Size (KB): 98493.459
Hash code: e3d6604f5452b4e99dc97a3988745278110800b48719b7481b0af1babcc58af4
--------------------------------------------------------------------------------
File name: _ArtemisUpdater_linux.tar.gz
Size (KB): 46676.36
Hash code: c01dda7b2f8760521ee84fc164a5d77501f7ba25695b6a5d48c6c4f4f157afc1
--------------------------------------------------------------------------------
File name: ArtemisWebDownlaod_linux.tar.gz
Size (KB): 145182.302
Hash code: a7827866e71f4274fb47d4d769311b4dc5e7af1129a6c784cd4e701e5248c2d5
--------------------------------------------------------------------------------

I'll just include another pastebin with my current script here. I still want to add a few things to this script, like better user interface, a warning to Pi0W users that building will take 12 hours, and instructions to recommend building on older Raspbian versions to avoid GLIBC errors when distributing the exe to other users. Script v1c: https://pastebin.com/yj5DUWGm (this 'RaspberryPi_requirements.sh' file goes into '.../Artemis/spec_files/Linux/' ) (This version includes if/then statements so that PyQt5 won't be re-build and re-installed into your Pyenv virtual environment if PyQt5 has already been installed).

AresValley commented 4 years ago

Thanks for the script v1c: at a glance, it seems way cleaner, and I really appreciated the echo notifications to the user and the conditional statements to speed up a little bit the overall process. Outstanding job and good to know that RPi 0W is working as well. Your idea sounds great: using Raspian Wheezy could ensure complete backward compatibility for all raspberries. Tomorrow I'll try to create the executables, and then I can send them to you and, if you have time, you can confirm if they are able to run without issues on RPi3 and RPi4. I wouldn't worry about the different hash: even a different bit can completely change the checksum, so, for instance, even a small change in the version of a library can make dramatic changes on the sha256. As long as the executables work normally, I would not worry about it :) We have some news as well: Alessandro fixed several bugs in the space weather module due to a data change to a different NOAA format. He also fixed the automatic update for ARM architecture: today, we tried to test the automatic update for a dummy version and every test was successful. For this reason, I suggest you downloading the last master because it is a virtual 3.2.1 release. After few other tests with RPi I think we are almost ready to publish the new version...

AresValley commented 4 years ago

btw: after the release of the new version, I'll take a closer look at your thread about Auto-ID functions, and we can discuss/think about it...the problem here seems to be the intrinsic reliability of the method it self

WheezyE commented 4 years ago

That sounds awesome, I'll look forward to testing some executables for you tomorrow (or by Monday 3pm PST if I need my monitors and keyboards at work to test other Raspbian versions). And I wish you the best of luck compiling on RPi 2B with Wheezy.

As a side-note: I found that PyQt5 can be compiled with some extra arguments to tell it to exclude compiling some parts of PyQt5 and speed up the process a little bit. The Artemis binaries that are created don't seem to have much different in file size (maybe a few kb) and seem to work fine for now. I'm not sure that we should do this (since I would worry a little that we might get errors in future builds of Artemis), but I just thought it was interesting: python3.7 configure.py --confirm-license --sip-incdir="$DIR/Downloads/sip-4.19.17/siplib" can be changed to python3.7 configure.py --confirm-license --sip-incdir="$DIR/Downloads/sip-4.19.17/siplib" --no-designer-plugin --no-qml-plugin --no-tools to compile PyQt5 about maybe 15% faster (but might cause errors in future versions?)

I'm enticed by Auto-ID but also completely understand if it's just not quite reliable enough to be put into a build yet.

I'm very excited to hear about the new version of Artemis with bug fixes and Raspberry Pi code. Nice job, guys

AresValley commented 4 years ago

Thank you for your suggestions and your availability! Unfortunately, I'm not able to provide right now the executables because I faced several problems during the compilation. I thought about it and I decided, in the end, to use raspian Stretch to create the executables. The choice is justified by the fact that Wheezy has already passed the EOL date two years ago for the Long Term Release (LTS). There's no point in supporting something that's no longer in use. So I tried using Debian 8 (Jessie) but without success. I enclose here the whole log using your script (v1c version, https://we.tl/t-4Dq9JWgCcd) but the error is due to the lack of the OpenSSL library and this is a well know problem with debian 8:

...
Could not build the ssl module!
Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with X509_VERIFY_PARAM_set1_host().
LibreSSL 2.6.4 and earlier do not provide the necessary APIs
...

The problem could be easily solved with this solution (https://jameskiefer.com/posts/installing-python-3.7-on-debian-8/) but again, the LTM of debian 8 is almost reaching the EOL date as well (in few months) and the normal release has already lost official support. Debian 9 (Stretch) will be supported from 2020 to 2022 so it seems to be a good starting point. This release is based on gcc 6.3. Unfortunately, something went wrong here too (full log here https://we.tl/t-B3TdKjrQdD):

...
168241 INFO: Loading module hook "hook-numpy.core.py"...
Traceback (most recent call last):
  File "/root/.pyenv/versions/artemis3_py370_pyqt5122/lib/python3.7/site-packages/numpy/core/__init__.py", line 17, in <module>
    from . import multiarray
  File "/root/.pyenv/versions/artemis3_py370_pyqt5122/lib/python3.7/site-packages/numpy/core/multiarray.py", line 14, in <module>
    from . import overrides
...

This time, it seems to be something related to numpy...I'm trying to fix the problem

WheezyE commented 4 years ago

Nice work! And thank you for the logs.

This numpy problem looks like another GLIBC out of date error (from line 14043 in your log): ImportError: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.27' not found (required by /root/.pyenv/versions/artemis3_py370_pyqt5122/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-arm-linux-gnueabihf.so) But this time, maybe it's from numpy. I'll install Stretch on my Pi3B and try older numpy versions to see how far back I can go without breaking Artemis.

AresValley commented 4 years ago

No problem, thanks to you for your hint about the similar error. Anyway, your script is almost bullet-proof (for Buster and Stretch at least). No need to assure compatibility for older OSs: we are almost ready. I was able to successfully compile Artemis with your script (v1f) after few manual tricks: first I tried to install a different version of numpy because the version specified in the requirements is no working properly with the raspberry+pyinstaller combination. After that, I fixed a hidden import...this is quite mysterious but the module PyQt5.sip was not included by default. I suspect this depends on pyinstaller's ability to successfully identify dependencies and hook them. Anyway, I was able again to generate the executables: https://aresvalley.com/Storage/Artemis/Package/ARM/Artemis.3.2.1.tar.gz When you have some free time, can you give it a try? I remain curious to see the results you have obtained with a configuration similar to my one...

WheezyE commented 4 years ago

Nicely done again! Ok, I tested the binaries. The bad news is, they don't work on Buster (Pi 0W, 3B+, 4B)

pi@raspberrypi:~/Downloads/artemis $ ./Artemis 
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Reinstalling the application may fix this problem.
Aborted

But the good news is, they do work perfectly on Stretch with themes and everything! Database downloaded and displayed fine. (RPi 3B not plus).

pi@raspberrypi:~/Downloads/artemis $ ./Artemis
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
libEGL warning: DRI2: failed to authenticate

I'm going to try searching around for that "xcb" error. Just curious, did you build and install the PyQt5 from source without using any of the '--no-tools' or other exclusionary flags? (i.e. Did you run python3.7 configure.py --confirm-license --sip-incdir="$DIR/Downloads/sip-4.19.17/siplib" and not run python3.7 configure.py --confirm-license --sip-incdir="$DIR/Downloads/sip-4.19.17/siplib" --no-designer-plugin --no-qml-plugin --no-tools ?)

I'm still trying to get my v1F script to run and am curious what you did to get it to build correctly:

I was also getting that ModuleNotFoundError: No module named 'PyQt5.sip' error on compile with the build4pi_v1F script. Thank you for letting me know you were getting that error too - and for your idea that it might be a pyinstaller error (I had worried maybe I had messed something up on my Stretch install with all my installing and uninstalling of different numpy modules). [EDIT: 4/23/2020 I think this might have happened due to my changing the Python installation to have --enable-shared . I did this to get around an error message installing Python into Pyenv on Stretch. I'm currently testing this too]

I can't seem to get the .sip module to be found with python3.7 -O -m PyInstaller --clean Artemis.spec --hidden-import=PyQt5.sip or any variation of that (or even with python3.7 -O -m PyInstaller --clean Artemis.spec --hidden-import="PyQt5.sip" --hidden-import=sip.so --hidden-import=sip.pyi --hidden-import=sip --hidden-import=sip.h), even when I export the /home/pi/.pyenv/versions/3.7.0/envs/artemis3_py370_pyqt5122/lib/python3.7/site-packages/PyQt5 folder into my path or even if I updated PyInstaller to its 4.0 dev build (pip install https://github.com/pyinstaller/pyinstaller/archive/develop.zip)

[EDIT2: 4/23/2020 A forum suggested this may be a bug in older versions of PyQt5-sip. I think I installed older PyQt5 and PyQt5-sip since they were recommended by requirements.txt, though the other requirements.txt in "unused_installation_scripts/Linux" suggests newer PyQt5's might work] Others suggested this might be a setuptools problem. I'll try more combinations of PyQt5 versions and setuptools tomorrow.

AresValley commented 4 years ago

Thanks for the feedback. For installing PyQt5, I followed the instructions in your script (the complete procedure, without speeding up the process with plugins/tools exclusion):

  cd $DIR/Downloads
  cd PyQt5_gpl-5.12.2
  python3.7 configure.py --confirm-license --sip-incdir="$DIR/Downloads/sip-4.19.17/siplib"
  sudo make # Configuring and making PyQt5 takes about 2 hours
  sudo make install

This time I didn't try to manually compile PyQt5 following the guidelines on tal.org because I found no problem in the PyQt compilation or any imports used by Pyinstaller.

Sorry for the late reply but yes, I tried to change pyinstaller version as well (switching from the 3.6 to the 4.0dev) but with no significant effects: PyQt5.sip is not properly detected during the pyinstaller packing and the only solution seems to add the explicitly hidden import...this is weird because we had no issue with buster compilation and the version of pyinstaller is always the same. The dependencies are frozen only because we wanted to ensure a working combination of libraries. However, this combination may even no longer be valid. I don't think it's a big issue after running some tests.

WheezyE commented 4 years ago

Just writing a quick update. I've been working on this off-and-on this week and have been doing a lot of head scratching. I think I'm gonna maybe take a break from getting Stretch to run Artemis. I think I'm just gonna make a commit for the Buster version of the build_for_raspbian.sh script (after testing it again on Pi's 0-4), then update that commit later if I can figure out Stretch.

I suspect that the PyQt5.sip module not found problem may be related to this other following behavior somehow: - On Buster, `pyenv install -v 3.7.0` installed Python within Pyenv with no problems. But on Stretch, I needed `CONFIGURE_OPTS=--enable-shared pyenv install -v 3.7.0` in order to avoid ... "OSError: Python library not found: libpython3.7m.so, libpython3.7mu.so.1.0, libpython3.7.so.1.0, libpython3.7m.so.1.0". - On Buster, `pip install 'numpy==1.17.2'` works with no problems. But on Stretch, I needed `pip install 'numpy==1.17.2' --no-cache-dir --no-binary :all:` in order to avoid ... "Original error was: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.27' not found (required by /home/pi/.pyenv/versions/artemis3_py370_pyqt5122/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-arm-linux-gnueabihf.so)" I think it's interesting that Raspbian Buster already has System Python 3.7 pre-installed, while Stretch does not have System Python 3.7 pre-installed. I'm wondering if maybe Buster's System Python3.7 was pre-set-up with some configuration options on Buster that I'm not aware of or not using when I try to install Python into Pyenv on Stretch. I know that doesn't make a lot of sense, since the Pyenv's virtual Python should be totally separate from the operating system's System Python. With all that info, I'm suspecting that my paths must be messed up somewhere with Stretch's Pyenv Python 3.7.0 installation. But I am still stumped after experimenting with `PYTHONPATH`, `PATH`, and `pyinstaller --path=`. I also tried editing `/home/pi/.pyenv/versions/3.7.1/envs/artemis3_pyqt5122/lib/python3.7/site-packages/PyInstaller/hooks/hook-PyQt5.py` to include sip.so and sip*.so, installing different PyQt5-sip's through pip or by compiling, renaming sip.so to PyQt5.sip, doing `pyinstaller --hidden-import=PyQt5.sip Artemis.spec`, trying `--onedir`, and also trying other --hidden-imports with no luck.

I'm at least relieved that the Buster version is working. And I'm encouraged that you got a Stretch version to work, even if that version doesn't work on Buster for some reason. Since the older Raspbian OS doesn't work, it does make me a little concerned that future Raspbian versions might break our install script. But I suppose we can just 'cross that bridge when we come to it' as they say.

And all the tinkering did at least pay off a bit. I learned a few things about improving the script:

WheezyE commented 4 years ago

I made some progress.

Some bad news though: The cleanest option might be to just distribute a Buster-compiled version that only works on Buster but runs cleanly. I'm worried all the minor errors in the terminal would spook some users - or even maybe cause errors in future versions of Artemis.

Some good news too though: If we decided to just let Buster users ignore the many minor error messages in the terminal, the Jessie-built Artemis binary might run ok on both Jessie and Buster.

I'm wondering if maybe the best option would be to make the Raspberry Pi binary on the website run on just Buster without error messages, but put a note in the readme that Jessie users can compile their own binary that will run on Jessie if they want. I can then make the script (current work in progress v1f3) have conditional options that compile one way on Jessie and another way on Buster.

Here are some things I discovered:

wget https://download.savannah.gnu.org/releases/freetype/freetype-2.10.1.tar.gz tar -xvf freetype-2.10.1.tar.gz cd freetype-2.10.1 sed -ri "s:.(AUX_MODULES.valid):\1:" modules.cfg &&

sed -r "s:.(#.SUBPIXEL_RENDERING) .*:\1:" \ -i include/freetype/config/ftoption.h && ./configure --prefix=/usr --enable-freetype-config --disable-static && make -j4 sudo make install

sudo su

make install

exit

wget http://sourceforge.mirrorservice.org/l/li/libuuid/libuuid-1.0.3.tar.gz tar -xvf libuuid-1.0.3.tar.gz cd libuuid-1.0.3 ./configure && make sudo make install

sudo apt-get install gperf

cd ~/Downloads wget https://www.freedesktop.org/software/fontconfig/release/fontconfig-2.13.1.tar.bz2 tar -xvf fontconfig-2.13.1.tar.bz2 cd fontconfig-2.13.1 rm -f src/fcobjshash.h export PKG_CONFIG_PATH=/usr/share/pkgconfig export FREETYPE_LIBS="-L/usr/lib -lfreetype" export FREETYPE_CFLAGS="-I/usr/include/freetype2" ./configure --prefix=/usr \ --sysconfdir=/etc \ --localstatedir=/var \ --disable-docs \ --docdir=/usr/share/doc/fontconfig-2.13.1 && make -j4

sudo mv /usr/lib/arm-linux-gnueabihf/libfreetype.so.6.12.3 /usr/lib/arm-linux-gnueabihf/xxxx-libfreetype.so.6.12.3 sudo cp /etc/fonts -L -r /etc/fonts.old sudo make install

References

http://www.linuxfromscratch.org/blfs/view/svn/general/fontconfig.html

https://www.freetype.org/download.html

http://www.linuxfromscratch.org/blfs/view/svn/general/freetype2.html

https://sourceforge.net/projects/libuuid/

Maybe the Jessie system fonts could be imported or hooked into the Artemis binary with PyInstaller?  I'm not really sure how to do this, but all of Buster's font files total 98.5KiB (not just symbolic links, but the actual files) so it wouldn't add much to the file size of the binary if it were possible.

 - Finally, minor GLIB incompatibilities between Jessie and Buster: As a separate issue, though still not really affecting performance, I'm getting other error messages too when a Jessie-compiled Artemis binary is run on Buster: It appears that the old Jessie GLIB tries to run incorrect symbols from the newer Buster GLIB.  Again, Artemis seems to run fine, but the errors are annoying and I also don't know how they'll affect performance for future updates.

[Run Jessie-compiled Artemis binary on Buster] pi@raspberrypi:~/Desktop/dist $ ./Artemis pygame 1.9.6 Hello from the pygame community. https://www.pygame.org/contribute.html /usr/lib/arm-linux-gnueabihf/gio/modules/libdconfsettings.so: undefined symbol: g_log_structured_standard Failed to load module: /usr/lib/arm-linux-gnueabihf/gio/modules/libdconfsettings.so /usr/lib/arm-linux-gnueabihf/gio/modules/libgioremote-volume-monitor.so: undefined symbol: g_mount_operation_get_is_tcrypt_system_volume Failed to load module: /usr/lib/arm-linux-gnueabihf/gio/modules/libgioremote-volume-monitor.so 'g_io_module_load': /usr/lib/arm-linux-gnueabihf/gio/modules/libgiognomeproxy.so: undefined symbol: g_io_module_load Failed to load module: /usr/lib/arm-linux-gnueabihf/gio/modules/libgiognomeproxy.so 'g_io_module_load': /usr/lib/arm-linux-gnueabihf/gio/modules/libgiognutls.so: undefined symbol: g_io_module_load Failed to load module: /usr/lib/arm-linux-gnueabihf/gio/modules/libgiognutls.so 'g_io_module_load': /usr/lib/arm-linux-gnueabihf/gio/modules/libgiolibproxy.so: undefined symbol: g_io_module_load Failed to load module: /usr/lib/arm-linux-gnueabihf/gio/modules/libgiolibproxy.so

AresValley commented 4 years ago

Hey Eric, first of all: sorry for the late reply. I'm impressed regarding the progress you did. In the end, I decided to public the buster version for the Raspian OS because I noticed as well that it is really challenging to compile a version that is capable of running smoothly on both the OSs. Right now it's relatively easy to obtain a working version for stretch or buster but not a pseudo cross-compiled one (compiled on stretch and running on buster, for instance). For this reason, I agree with your last solution: the most feasible way seems to let the user choose the preferred configuration and OS on the script. In the future, I'll add OS versions of Raspian. Excellent for the make parallelization (I think we can use the j4 argument on RPI 2 as well since the ARM Cortex-A7 is a quad-core CPU) and the pip installs wheel tricks! I'm not super worried about the spooky errors that pop up when you run Artemis: to be honest, these types of errors are not new because I encountered them few times when I tried to create executables for Linux. The issue seems to be not critical and the software runs flawlessly and doesn't affect in any way the used font (which remains customizable from the drop-down menu). Conversely, the incorrect symbols error is completely new for me. I have no clue about the possible origin...I'll try to see what it can be but, anyway, I think that the most elegant solution is to have a configuration in the script that leaves the user the freedom to choose to compile for a specific operating system

WheezyE commented 4 years ago

Thanks :) And no worries at all about the reply speed - I'm also getting back kinda slow. I've updated the script to auto-detect OS version (Stretch vs Buster) and choose different install parameters based on that. I'm testing it out right now on my Buster Pi's (0W, 3B+, 4B). The script builds fine on my Stretch Pi (3B) so far, but I won't get to test other Pi models with Stretch until Monday or Tuesday.

WheezyE commented 4 years ago

Just submitted a pull request :)