Язык — это средство общения, когда один человек пишет: "Роса тем и хороша, что на ней что не собирай все будет работать везде", — а второй отвечает: "теперь вот сделали на Росе сборку под шлангом C++17, так что вообще лафа пошла - и все собирается, и везде работает", — то могу порадоваться, что они друг друга поняли, а значит язык, как средство общения, выполнил свою задачу. Мне остается предполагать, что Jaam понимает, что "везде" ограничено достаточно новыми ОС на базе GNU/Linux и glibc, в которых как минимум libc.so.6 сможет удовлетворить зависимости всех ELF, которые будут положены Jaam'ом в AppImage, в т.ч. зависимости libstdc++-gcc10.so.6, а системная libstdc++.so.6 сможет удовлетворить зависимости всех ELF из AppImage, учитывая то, что требуются одновременно и libstdc++.so.6, и libstdc++-gcc10.so.6. На свой страх и риск упаковщик переносимой сборки может _попробовать_ вырезать зависимости от libstdc++.so.6, оставив только libstdc++-gcc10.so.6, например, с помощью patchelf(1). На большинстве дистрибутивов GNU/Linux, выпущенных в 2016 году и позже, этот LibreOffice, грамотно упакованный в AppImage, наверняка будет работать, но лично я бы постарался избежать слова "везде", в т.ч. поскольку до сих пор используется не мало более старых ОС. Также могут возникнуть, но маловероятны нюансы с другими библиотеками, которые не попадут в AppImage.

При этом я специально пишу "сможет удовлетворить зависимости", а не "окажется достаточно новой", поскольку бывают нюансы, например, несмотря на удовлетворение критерия достаточной новизны библиотеки, некоторые символы могут быть версионированы по-разному, что сделает невозможным удовлетворение зависимостей. Пример: https://lists.altlinux.org/pipermail/devel/2020-April/210682... Тыкнув пальцем в небо, могу предположить, что с большой вероятностью при упаковке AppImage на базе библиотек из rosa2016.1 таких проблем не возникнет с подавляющим большинством других дистрибутивов, имеющих такую же или более новую версию glibc, но это лишь тык пальцем в небо.

Похожие проблемы могут возникнуть, если в какую-либо из используемых по обе стороны (где собирали AppImage и где его запускают) бекпортировали новый функционал и своеобразно версионировали новые символы. Когда я бекпортировал в systemd-243 исправление CVE-2020-1712 (коммиты 5d5eb55931, c4dcaa6c90 и e3162da96f в abf.io/import/systemd), то сначала версионировал бекпортированный из systemd 245 символ как 243, затем включил голову, собрал тестовую программу, требующую этот символ, не смог ее запустить на другом дистрибутиве и убрал новую функцию из публичного API и ABI, а затем узнал, что существует systemd-stable, в котором сделали так же. Из-за подобных нюансов при бекпортировании чего-либо и в системе, где компилируют содержимое AppImage, и в системе, где его запускают, могут возникнуть проблемы, что является лишним аргументов за избегание использования слова "везде" для описания того, где будут работать собранные AppImage.

Надеюсь, что, отвечая на провокационный комментарий, смог подкинуть хотя бы какую-то пищу для ума.