Can Anyone Help Sanni with a Linux install of FGFS?
Originally posted by Sanni:
Up to now: 2020.4 git version
2020.4 does'nt start with the error 'unable to create a 3d window' and:
StatsHandler::StatsHandler() Setting up GL2 compatible shaders
0.04 [ALRT]:view Not creating osgViewer::CompositeViewer
Now checking for plug-in osgPlugins-3.4.1/osgdb_nvtt.so
0.06 [INFO]:OSG Error: Not able to create requested visual.
242.58 [ALRT]:event Shutdown of non-init-ed group.
When I try to compile it it says 'you need osgxr': osgxr has a bug (include <cstdint> missing). When I add that entry it is deleted when makepkg is started. Not possible to renew 2020.4!
Trying to create 2020.3 ends with:
In Datei, eingebunden von /home/sanni/downloads/flightgear/src/flightgear-2020.3.18/utils/fgelev/fgelev.cxx:30:
/usr/include/simgear/props/props.hxx:1403:18: Fehler: »shared_mutex« in Namensbereich »std« bezeichnet keinen Typ
1403 | mutable std::shared_mutex _mutex;
/usr/include/simgear/props/props.hxx:1403:13: Anmerkung: »std::shared_mutex« ist erst ab C++17 verfügbar
1403 | mutable std::shared_mutex _mutex;
make[2]: *** [utils/fgelev/CMakeFiles/fgelev.dir/build.make:76: utils/fgelev/CMakeFiles/fgelev.dir/fgelev.cxx.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:2636: utils/fgelev/CMakeFiles/fgelev.dir/all] Fehler 2
make: *** [Makefile:166: all] Fehler 2
==> FEHLER: Ein Fehler geschah in build().
Breche ab...
Don't know what to do.
Comments
Sanni, did you try over at the main forum? Surely someone over there can advise.
VooDoo
So are you placing cstdint.h into the include path somewhere? I read that cstdint.h is the apdaption of the old stdint.h in C++11.
Maybe a compiler mismatch?
shared_mutex is a language construct of C++17 so fairly new ... are you sure, you are using the right compiler version?
It looks to me as if they are using C++17 and you might be using an older version, Sanni
I read that C++17 features are fully featured from GCC version 11 on.
Also Hamza played around with the composite view and had problems. They pointed towards wrong or missing GFX card drivers?
https://groups.google.com/g/osg-users/c/N19e3uqLk9E?pli=1
At that time he was using Mesa drivers which had all sorts of problems but maybe, you know, you are maybe using old drivers for your GFX card? Or not the latest ones?
I am sorry, I dont really remember that much of the C++ I was doing back then - too much pain lol
I think dfferently about it today but my brain erased a lot of the old pathways due to too much inflicted pain by the old standards hrhrhrhrhr
Thanks for weighing in Geed! I don't understand a word of it but I'm glad yer helping.
VooDoo
I have 2020.3 installed on Fedora 38 using the package in the repos, I don’t know whether Sanni has that option on their distro or whether they need to compile (I sadly don’t have a great track record with compiling).
CJ
OrbitalMartian
Callsigns: G-ORBI
I don't know anything about it but the first thing I do when these things happen is to completely purge/uninstall the software that is screwing up, update all of the graphics and necessary drivers (if yer using a compiler then update that to the latest/greatest) and any OS updates that need to be done and then download a known good copy of the software and compile/install from scratch.
I'm curious as to what happened when the last version quit working?.....something got updated and is incompatible? Something happened as it was working and then it quit. Something changed, somewhere. Software just doesn't stop working usually unless it got corrupted.
IMO/YMMV.
VooDoo
Has Sanni tried the AppImages?
Many Thanks to all of you. It's heartwarming to see what you do for me, many thanks. Specially to Vodoo. :)
To clear what I have done up to now:
I did'nt change the graphics driver. I did'nt change anything related to Flightgear.
Only the normal updates I do with the rest of the packages that are installed.
Flightgear and Simgear are out of the AUR (I'm using ArchLinux). So I download a 'snapshot' write it into a directory ans start the download of the program text and compile it. Then the compiled package wil be installed.
My test program (gears) has no problem to create a 3D window. My graphics driver nvidia-470 works properly.
I think it is an underlying library that makes this problem. So I have to wait for the next version of this library... and try to do anything I did every day when I updated my system. Or there is an ArchLinux user who compiles FG and sends me the package.
What are AppImages? How can I use them?
I'm using gcc 13.2.1-3 and gcc-libs 13.2.1-3.
AppImages are a way of distributing software with most of it's dependencies included - in an image that you just need to run
You can grab the nightly builds from
https://download.flightgear.org/builds/nightly/
you can see FlightGear-2020.4.0-x86_64.AppImage there (the nightly is the same)
you download it, make it executable (chmod +x <filename>) then run it
it mounts a compressed filesystem image & runs flightgear from that - it will look for your existing settings & look for your fgdata as it doesn't contain the fgdata. If it can't find it, it will ask you to point it at the fgdata directory
I maintain the build script for the FlightGear AppImages
The stable releases can be found on sf.net or https://download.flightgear.org/builds/2020.3/
Thanks, I tried the Appimage. When I add my Aircraft folder the image crashes...
Do you have the output of the crash?
Is it possible there is a corrupt aircraft? I'd try pointing it an aircraft folder with only one known good aircraft in it but what do I know.
VooDoo
I'm afraid I can't reproduce - I've installed Manjaro in a vm & given it access to the folders on my machine & it hasn't crashed
I am running 2020.3.18 though as it's easier to download the fgdata tar ball from the same place as the appimage
2020.4.0 is really sensitive to having the latest up to fgdata - when I'm running 2020.4/next I always work with a git repository of fgdata, which runs upto 6G (a normal fgdata is 2.6G)
I would recommend running 2020.3.18 in any case - you can use satellite scenery with it. The only thing you would need 2020.4/next for is WS 3.0 or HDR pipeline testing
Would be great to try 2020.3. As I wrote:
/usr/include/simgear/props/props.hxx:1403:13: Anmerkung: »std::shared_mutex« ist erst ab C++17 verfügbar 1403 | mutable std::shared_mutex _mutex;
GCC supports C++17 since version 8 and libc++ since version 9. Installed is gcc 13 and libc++ 15. Why this Error??
GCC supports C++98, C++11, C++14, C++17, C++20, C++23, C++26 and shared_mutex. 8|
Is that from building 2020.3.18 on your system?
Right, I might have found a workaround to the crash on adding aircraft directory thing... at least I think I was able to trigger it once & then get it to work afterwards.... as I said there are some odd issues with 2020.4
I added an aircraft directory with a range of FGUK aircraft in it & it crashed, and then when trying to run again it wouldn't even start so I tried the following:
run from the terminal:
./FlightGear-latest-x86_64.AppImage --log-level=debug (this starts the c172)
./FlightGear-latest-x86_64.AppImage --launcher --log-level=debug (this then ran the launcher ok without crashing)
from then on I could run the appimage without options & it was fine - it may be work a try, but I would also recommend that you have an up to date fgdata for next
That helped :D
AppImage is working. One question is left: is there a help page coming with the image?
YaY!
VooDoo
Help for AppImages?
Well basic description is here: https://appimage.org or https://en.wikipedia.org/wiki/AppImage
The AppImage is precompiled binaries with lots of required libraries included - it is a squashfs image that is mounted & then a script is run that sets that path to the correct libraries so they are used instead of ones installed locally that may be incompatible. On exit the image is unmounted.
The FG AppImages don't include fgdata yet due to the way the navdata is compared between different versions of FG - I've pointed this out but no changes have been made to help this yet.
In any case not having them makes the download smaller - it's relatively easy to grab the tarball for stable (and there are update tarballs for differences between versions), and I would recommend using a git repo for nexts fgdata
No, what I mean is:
can I start the image with my .fgfsrc ? (--config= does'nt work)
can I start the image without starting the launcher (because normally I use the .fgfsrc and add the airport, time, aircraft manually in the commandline)
and other options available for the FlightGear image...
Sanni, is it working yet?
VooDoo
Yes, the image is working, my installation not... (I'm working on it :) and will report hot to solve such a problem.)
Apologies I've been away on holidays, I'll look at it now
In the mean time you can use -the --appimage-mount option to mount the image - it will print where it has mounted ( somewhere in /tmp ) - you can then cd to the mount & use the binaries - you will need to checkout the AppRun script in the root of the image to see how to set the environment variables
According to the script it should pass all additional options on to fgfs
OK, --config= is working (tested in both Manjaro & Ubuntu) but you have to specify the full path - no relative paths - as fgfs is running from within the appimage so all relative paths are relative to there
Many, many thanks to all of you:
I made the daily update (ArchLinux) and now I have three working FG-versions... :D :D :D
(2020.3.18 & nightly AppImage and my installed FG). (nightly has a graphics problems with the sky, but (only a white sky without any colors) but I can fly it.)
Glad to hear you have it working!