Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

P4: AppImage launcher adds the current folder to the library search path

Open Beginner friendly
  • Is something wrong?
#7,924 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cmake, linux, shell
Domain
build-system, devops

Research direction

Read freespace2/cmake/AppRun.in, focusing on how it builds LD_LIBRARY_PATH and passes arguments to exec. Reproduce the issue with LD_DEBUG=libs and LD_LIBRARY_PATH unset, then verify the launcher searches the AppImage library directory and system paths without searching the starting folder.

Written by the indexing model from the issue text.

Description

Minor: this only matters if a file with a library's name ends up in the folder FSO is started from, and a normal Knossos install never puts one there.

Problem
The Linux AppImage's launcher (freespace2/cmake/AppRun.in) sets the library search path to the AppImage's own lib folder followed by the user's LD_LIBRARY_PATH. When LD_LIBRARY_PATH isn't set, which is the default on most systems, the line ends with a colon and leaves an empty entry. Linux reads an empty entry as "the current folder", so for every library the AppImage doesn't bundle, the loader also looks in whatever folder FSO was started from. Knossos starts FSO in the game's root folder.

Steps to reproduce

  1. On Linux, with LD_LIBRARY_PATH not set, open a terminal in any empty folder.
  2. Run the official 26.0.1 build with loader logging: LD_DEBUG=libs ./fs2_open_26_0_1_x64_SSE2.AppImage (I ran it under xvfb-run and stopped it after a few seconds).
  3. Look at the search path= lines in the output.

Expected vs. actual behavior

  • Expected: the search path is the AppImage's lib folder, then the system's usual folders.
  • Actual: the search path ends with relative entries (glibc-hwcaps/x86-64-v4, ..., and an empty one), and the loader tries files such as libpthread.so.0 in the starting folder: 268 lookups there in my run.

Proposed fixes

  1. In AppRun.in, only add the colon when the variable is set: export LD_LIBRARY_PATH="${HERE}"/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}.
  2. The same, plus quoting the arguments on the exec line ("$@"), so an argument with a space is passed as one argument. I found this one by reading the script, not by running into it.
  3. Give the executables a RUNPATH of $ORIGIN/../lib and drop the LD_LIBRARY_PATH export entirely, which also keeps the AppImage's library folder out of the environment of anything FSO starts.
Dominant language
C++
Stars
488
Forks
184
Avg merge
1d 19h
Merged PRs (30d)
33

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from scp-fs2open/fs2open.github.com

All issues in scp-fs2open/fs2open.github.com

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.