Board index FlightGear Support Compiling

Building on Debian - .bashrc and .profile env variables

Building FlightGear from source, and in the need for help?

Building on Debian - .bashrc and .profile env variables

Postby japreja » Wed Aug 26, 2020 4:41 pm

I am building FG according to the Wiki Instructions. I am using a dinosaur PC, an old Sony Vaio with a Pentium 4 and 512MB of memory. Allot of Disk-Swapping! and two crashes trying to compile from XFCE. I have had to enter in the environment variables after every reboot. I have a few questions on setting up the variables in ".profile" and ".bashrc".

I am using "version/2018.3.6" so I added the following to both the files:

Code: Select all
export FG_VERSION=version/2018.3.6
export FG_SRC_DIR=$HOME/src/                           # Trailing slash
export FG_INSTALL_DIR=$HOME/FlightGear                 # NO Trailing slash


While putting these commands at the end of the files I though it would be appropriate to stop and ask 2 questions here:

  1. if this would have any adverse effects on the build steps
  2. Should the version info be pulled in from a file using an if/fi statement and how to script this

For question two, when I was editing the "$HOME/.bashrc" and "$HOME/.profile" files I noticed how everything that was already in it was nice and tidy and checking if variables, files, and/or directories existed. In the plib build section of the instructions a version file is created so it should function in the same way, shouldn't it?

I am also turning off booting into any type of X environment:

Code: Select all
systemctl set-default multi-user.target


and if I need to use X again I can just:

Code: Select all
systemctl set-default graphical.target


Thanks to this StackExchange answer. Thanks in advance for any help with this, I hope to be more active with FlightGear again and hopefully building all available tools for FG as well.

Jorge P.
japreja
 
Posts: 334
Joined: Fri May 08, 2015 12:05 am
Location: MT, USA
OS: Windows 10 Pro 64bit

Re: Building on Debian - .bashrc and .profile env variables

Postby Hooray » Wed Aug 26, 2020 5:31 pm

I've previously built FG on similar low-end systems, including a fairly recent version. In my opinion you should not have to set any environment variables, let alone reboot the system.
Obviously, running fgfs is a totally different matter - at that point, you'll surely want to take a look at this: http://wiki.flightgear.org/Minimal_Startup_Profile

Apart from that, I'd free up all resources that you can - i.e. run outside XFCE.
You can still start everything via XFCE e.g. by using screen, and then quit the window manager to keep it running overnight.

It would also make sense to use a compiler cache like ccache.

It goes without saying that upgrading your RAM or your HD (SSD) can still make a ton of difference when building FlightGear - likewise, cross-compiling on another machine for your laptop would be another option.

You can also reduce overall build time by installing dependencies like plib, osg etc via the system's package manager.

Then again, actually being able to run/fly or "play" fgfs will require quite a bit of work, and possibly also patching to get rid of hard-coded defaults, or even entire subsystems.

Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Building on Debian - .bashrc and .profile env variables

Postby japreja » Thu Aug 27, 2020 7:14 am

Well all seems to work OK with the build, testing it is another story. Running with the --launcher option opens the launcher, but no fonts loading and no images loading, i did set the fg data dir. Not to mention that the Video Card has a whopping 128MB memory. Still quite surprising that it is trying to run.

I think I will redo the compile, since I haven't rebuilt anything from when the PC crashed during the SimGear and FlightGear builds when I was in XFCE. Then see if I can actually get FG running on a Pentium 4, 512MB Memory, and 128MB Video memory. I am trying to get some screen shots but I am unsure if I have to screenshot apps installed.
japreja
 
Posts: 334
Joined: Fri May 08, 2015 12:05 am
Location: MT, USA
OS: Windows 10 Pro 64bit

Re: Building on Debian - .bashrc and .profile env variables

Postby FlugHund » Thu Aug 27, 2020 10:49 am

Hi Jorge,

japreja wrote in Wed Aug 26, 2020 4:41 pm:[...] a Pentium 4 and 512MB of memory. Allot of Disk-Swapping! and two crashes trying to compile from XFCE.

Said crashes might have occurred due to insufficient RAM. In case your Pentium 4 CPU supports SMP these crashes possibly can be avoided by removing the -j$(nproc) part of the make -j$(nproc) commands.


japreja wrote in Wed Aug 26, 2020 4:41 pm: I have had to enter in the environment variables after every reboot. I have a few questions on setting up the variables in ".profile" and ".bashrc".

I am using "version/2018.3.6" so I added the following to both the files:

Code: Select all
export FG_VERSION=version/2018.3.6
export FG_SRC_DIR=$HOME/src/                           # Trailing slash
export FG_INSTALL_DIR=$HOME/FlightGear                 # NO Trailing slash

Thanks for reporting the missing slash, it's corrected in the wiki now.
You do NOT need these variables to run FG, they're only helpers for the build process. See section Trial run and finishing process for what's actually required.

japreja wrote in Wed Aug 26, 2020 4:41 pm:For question two, when I was editing the "$HOME/.bashrc" and "$HOME/.profile" files I noticed how everything that was already in it was nice and tidy and checking if variables, files, and/or directories existed. In the plib build section of the instructions a version file is created so it should function in the same way, shouldn't it?

This version file is not being created but overwritten with a new version string. 1.8.5 --> 1.8.6
For unknown reason the maintainer of the forked and altered plib sources did not increase the version number. To distinguish our self build plib from the one available in debian's repos the wiki instructs the user to up that version string manually.

FG has a build in Screenshot feature: F3 (feature might have to be enabled somewhere in the in-sim menu).
User avatar
FlugHund
 
Posts: 568
Joined: Thu Mar 01, 2007 4:27 pm
Location: Inside ground effect
Callsign: D-HUND
IRC name: D-HUND / debdog
Version: next
OS: Devuan

Re: Building on Debian - .bashrc and .profile env variables

Postby FlugHund » Thu Aug 27, 2020 3:06 pm

japreja wrote in Wed Aug 26, 2020 4:41 pm:I am using "version/2018.3.6" so I added the following to both the files:

Code: Select all
export FG_VERSION=version/2018.3.6
export FG_SRC_DIR=$HOME/src/                           # Trailing slash
export FG_INSTALL_DIR=$HOME/FlightGear                 # NO Trailing slash

In case you've done that so you have the variables ready for your compilation attempts then you're good. Except you most likely do not need them in .profile, that is just for login shells. In any case, you only need them once, either in .bashrc or in .profile.
User avatar
FlugHund
 
Posts: 568
Joined: Thu Mar 01, 2007 4:27 pm
Location: Inside ground effect
Callsign: D-HUND
IRC name: D-HUND / debdog
Version: next
OS: Devuan

Re: Building on Debian - .bashrc and .profile env variables

Postby Hooray » Thu Aug 27, 2020 4:00 pm

if this isn't already being done by the script, you can run cat /proc/cpuinfo to determine the number of CPUs/threads and use that for nproc
equally, the amount of RAM can be queried via free/vmstat respectively
Depending on the amount of free RAM, it might make sense to ensure that a swap space is properly set up first.

Given the constraints of the system I would definitely suggest to build an optimized binary (at least OSG, SG + FG), and disable all unneeded/optional features - as has been said, you won't need a dedicated screen shot app, there are several ways to capture a screen shot in-sim.
With a custom-built binary and some startup/runtime tweaks, you can certainly expect to get 30+ fps using the minimal startup profile - that will obviously change drastrically when using a proper aircraft, let alone real scenery - in fact, a number of users with similar hardware have been tinkering with custom scenery for such systems. For testing purposes, you'll almost certainly want to use the ufo and an ocean-based location (basically no scenery)

However, I do believe with some patching, you should be able to get an IFR simulator working, in conjunction with a 2D panel - that should work even on such a system. Even though it will require a fair amount of work.

PS: You don't need to use the built-in QT launcher - in fact, using any other external launcher (or in fact none at all) may also help free up resources at runtime - while also reducing compilation times considerably.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Building on Debian - .bashrc and .profile env variables

Postby FlugHund » Thu Aug 27, 2020 4:28 pm

Hooray wrote in Thu Aug 27, 2020 4:00 pm:[...] to determine the number of CPUs/threads and use that for nproc equally, [...]

That is exactly what I thought should be avoided. By not passing the -j option it only does one job at a time. Each job requires RAM so it would be best in this case to have only one job going on. The time saved by running more than one job is probably void if the system has to swap.
User avatar
FlugHund
 
Posts: 568
Joined: Thu Mar 01, 2007 4:27 pm
Location: Inside ground effect
Callsign: D-HUND
IRC name: D-HUND / debdog
Version: next
OS: Devuan

Re: Building on Debian - .bashrc and .profile env variables

Postby japreja » Fri Aug 28, 2020 3:48 am

I have noticed that on the cmake lines in the Wiki page may have a few more typos in simgear and the flightgear build steps. If entered as is, the part

Code: Select all
CMAKE_BUILD_TYPE=Release


should be

Code: Select all
CMAKE_BUILD_TYPE="Release"


missing quotes. The command, as is, sets the default build type of Dev and not Release. Its hard to catch unless you read the first few lines of output after pressing enter. Otherwise it just seems to be OK.

In the FlightGear build step, when running "make test", even though it is not listed in the instructions, it fails with

Could not find executable $HOME/src/build-fg/test_suite/run_test_suite


I manually searched for the files in midnight commander and couldn't find them in the git sources, it may be that I need to configure that step with CMake?
japreja
 
Posts: 334
Joined: Fri May 08, 2015 12:05 am
Location: MT, USA
OS: Windows 10 Pro 64bit

Re: Building on Debian - .bashrc and .profile env variables

Postby Johan G » Fri Aug 28, 2020 8:53 am

japreja wrote in Fri Aug 28, 2020 3:48 am:[...] on the cmake lines in the Wiki page may have a few more typos in simgear and the flightgear build steps.

Please consider registering to the wiki and correct some of the mistakes you find. Many of these kinds of fixes is simple, and for the more complicated stuff there is documentation. :wink:
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Building on Debian - .bashrc and .profile env variables

Postby FlugHund » Fri Aug 28, 2020 11:21 am

japreja wrote in Fri Aug 28, 2020 3:48 am:should be

Code: Select all
CMAKE_BUILD_TYPE="Release"


missing quotes. The command, as is, sets the default build type of Dev and not Release. Its hard to catch unless you read the first few lines of output after pressing enter. Otherwise it just seems to be OK.

This certainly is not a typo. I've just confirmed for FG and SG on branch next, works just fine. Plus I am not aware "Dev" is a viable option for CMAKE_BUILD_TYPE. This should be Release, Debug, RelWithDebInfo or such. Please, can you paste what exactly you're seeing, maybe we can sort that out.


For the FlightGear sources you'll need to run "make test_suite" this should build and run the tests. For the SimGear sources just "make test" is fine.
User avatar
FlugHund
 
Posts: 568
Joined: Thu Mar 01, 2007 4:27 pm
Location: Inside ground effect
Callsign: D-HUND
IRC name: D-HUND / debdog
Version: next
OS: Devuan

Re: Building on Debian - .bashrc and .profile env variables

Postby wkitty42 » Fri Aug 28, 2020 4:23 pm

"Dev" is definitely a different one...

from my dnc script...
Code: Select all
  echo "  -f BUILD_TYPE                                                                       default=Release"
  echo "                set FG build type to BUILD_TYPE (Dev|Nightly|Release)"
  echo "  -b RELEASE_TYPE                                                                     default=RelWithDebInfo"
  echo "                set release type to RELEASE_TYPE (Release|RelWithDebInfo|Debug)"
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Building on Debian - .bashrc and .profile env variables

Postby xcvb » Fri Aug 28, 2020 5:05 pm

I prefer ccmake. It is a ncurses based GUI for cmake, where you can see and change all build options in a convenient way.
xcvb
 
Posts: 132
Joined: Sat Mar 14, 2015 3:08 pm
Version: Next
OS: Fedora Kinoite

Re: Building on Debian - .bashrc and .profile env variables

Postby Hooray » Sat Aug 29, 2020 2:51 pm

FlugHund wrote in Thu Aug 27, 2020 4:28 pm:
Hooray wrote in Thu Aug 27, 2020 4:00 pm:[...] to determine the number of CPUs/threads and use that for nproc equally, [...]

That is exactly what I thought should be avoided. By not passing the -j option it only does one job at a time. Each job requires RAM so it would be best in this case to have only one job going on. The time saved by running more than one job is probably void if the system has to swap.



Sorry, you're right - I missed the point of your comment. What you say is true, on such a low-spec system, even just the overhead of doing context switches / multi-tasking on a single CPU may already be too much.
In fact, it might be best to run make "dynamically", i.e. based on free system resources. I do know that there are job servers that watch CPU/RAM and SWAP utlization in the the background and scale processes up/down as needed.

Overall, depending on whether's it's possible/feasible to upgrade the amount of RAM installed on the system in question or not, it may still be best to build on a separate system i .e. cross-compile fgfs. Alternatively, install all dependencies of SG/FG via the package manager first, then install ccache and build SG/FG respectively. That way, the amount of work will be significantly reduced, certainly after the first build has succeeded.

If the OP is seriously interested in actually RUNNING fgfs, it would still be a good idea to compile native code that is heavily optimized, and then start with the ufo/no scenery and take it from there step by step.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Building on Debian - .bashrc and .profile env variables

Postby cgdae » Sat Aug 29, 2020 3:49 pm

Hooray wrote in Sat Aug 29, 2020 2:51 pm:Sorry, you're right - I missed the point of your comment. What you say is true, on such a low-spec system, even just the overhead of doing context switches / multi-tasking on a single CPU may already be too much.
In fact, it might be best to run make "dynamically", i.e. based on free system resources. I do know that there are job servers that watch CPU/RAM and SWAP utlization in the the background and scale processes up/down as needed.


It's by no means a compete solution, but make's -l option (lower-case L) can also be used to reduce overloading of the OS when doing a -j build - it limits creation of new jobs based on the current load average.
cgdae
 
Posts: 117
Joined: Tue May 31, 2016 8:35 pm

Re: Building on Debian - .bashrc and .profile env variables

Postby Hooray » Sat Aug 29, 2020 3:58 pm

indeed, that would seem like a good idea to add as an option to the corresponding script in fgmeta - and while we're at it, apt-get could probably also fetch ccache at the same time to ensure that people don't have to spend too much time waiting for sg/fg to rebuild :wink:

And who knows, maybe someone will even create a corresponding docker container to get people going much faster


http://wiki.flightgear.org/Howto:Buildi ... via_Docker
Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU


Return to Compiling

Who is online

Users browsing this forum: No registered users and 1 guest