Линковка к символическим ссылкам

Лол, ты оказывается не отличаешь компилятор от линковщика, а я ещё тут надрываюсь и шляпой даю подтереться…

О, знакомая либа. Я её когда-то компилировал для майнера Etherium, когда он был ещё на Питоне. Потом они переписали код.

Советую распространять либу вместе с прогой. Создаёшь скрипт run_appname.sh, даёшь ему параметр исполняемости, и содержимое:

[code] #!/bin/sh

export LD_LIBRARY_PATH=lib ./appname [/code]

Это ты не отличаешь, иначе знал хотя бы что через голый ld никто не линкует и написал хотя бы -Wl,. Вот тогда бы я ткнул тебя во-первых, в это:

       -P AUDITLIB
           Adds AUDITLIB to the "DT_DEPAUDIT" entry of the dynamic section.  AUDITLIB is not checked for existence, nor will it use the DT_SONAME specified in the library.  If specified multiple times "DT_DEPAUDIT" will contain a colon separated list of
           audit interfaces to use.  This option is only meaningful on ELF platforms supporting the rtld-audit interface.  The -P option is provided for Solaris compatibility.

и заставил рассказать что такое rtld-audit и как его использовать, а во-вторых, в то что этой опции нет ни в gold ни в lld. Но ты радуйся - тыкать не буду, ибо понятно что тебе до этого уровня далеко.

Возьми RapidJSON и не парься. Зачем тебе какое-то ненужно?

Во-первых, для тестирования переносимости кода совсем не фу, потому что вместо ещё одного gcc можно собираться третьим компилятором. Во-вторых, кроссовые бинарники без нативной винды ты никак не протестируешь. Нет, вайном нельзя тестировать бинарники под винду.

Я не поддерживаю сборку на MSVC и не буду поддерживать.

Тестировать бинари это одно, а писать скрипты на виндовый батч без нормального unix-like окружения это другое. Ну а запускать с нативной винды какой-нить msys2 мне показалось дико костыльно.

Интересное чтиво, почему-то глаз отфильтровал про солярку изначально, но кейсов кроме безопасности(и то такое себе) и отладки динамического линкера как-то не видать.

В любом случае при чём тут вообще мог быть компилятор в разговоре о линковке? Не использовать то ld не используют а вот всякие LD_FLAGS практически везде, кроме сборочных велосипедов от васяна, можно вписать в том или ином виде.

Ну а в vcpkg вроде пакетов нифига нет.

Там есть практически все что нужно.

Я не поддерживаю сборку на MSVC и не буду поддерживать.

Мне импонируют ваши убеждения, среди молодёжи такое не часто встретишь, однако это узкий взгляд. Но одно дело когда MSVC не может собрать корректный код, тогда конечно он идёт лесом. Другое - когда он указывает на реальные проблемы в вашем коде которые пропустили gcc/clang. Несмотря на убогость микрософтовского компилятора, второе намного более вероятно. А уж коли вы против мсячей экосистемы, логичнее не выпускать под неё бинарники.

Тестировать бинари это одно, а писать скрипты на виндовый батч без нормального unix-like окружения это другое.

Это чистая правда, не могу передать как я натрахался когда настраивал сборку в appveyor. Но там можно писать на powershell, он есть под linux, можно хотя бы синтаксис проверить, и он, думается мне, более вменяемый чем .bat. Но, справедливости ради, и травис приходится часто отлаживать методом тыка. Поэтому и сборка должка быть из 2 строчек, их не важно на чём писать.

В любом случае при чём тут вообще мог быть компилятор в разговоре о линковке?

Потому что и компилируют и линкуют через один бинарник. gcc/g++/clang/clang++.

Не использовать то ld не используют а вот всякие LD_FLAGS практически везде, кроме сборочных велосипедов от васяна, можно вписать в том или ином виде.

Да, но LDFLAGS передаётся в упомянутый бинарник, поэтому если вы туда напишете -P то получите первое определение которое я привёл про linemarkers. Чтобы передать его в линкер, нужно -Wl,-P....

Используй что-нибудь типа CPack, чтобы избавить себя от рутины, и опакечивание под дистрибутив сведётся к выставлению пары переменных

Другое - когда MSVC указывает на реальные проблемы в вашем коде которые пропустили gcc/clang

Для этого лучше наверное анализаторы кода какие-нибудь использовать.
Мне больше не нравится то, что помимо отличий API линукса и винды, и отличий API на разных виндах мне нужно будет ещё и думать о отличиях API между окружением с MSVC и mingw, при этом конечный пользователь никак не заметит результат этой проделанной работы.

А уж коли вы против мсячей экосистемы, логичнее не выпускать под неё бинарники.

Поддерживать только свою любимую ОС это как-то узколобо, особенно если нет каких-то технических ограничений, а их нет. Мне важно чтоб игра работала почти у всех (поэтому там кстати использованы древние версии opengl). Юзеру насрать на каком компиляторе собран бинарь, ему нужно чтоб он работал, он работает.

Но там можно писать на powershell

Учить новый скриптовый язык для каждой ОС как-то не особо хочется.

Для этого лучше наверное анализаторы кода какие-нибудь использовать.

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

Мне больше не нравится то, что помимо отличий API линукса и винды, и отличий API на разных виндах мне нужно будет ещё и думать о отличиях API между окружением с MSVC и mingw, при этом конечный пользователь никак не заметит результат этой проделанной работы.

Об этом не надо думать, вы же используете кросс-платформенные API и библиотеки.

Поддерживать только свою любимую ОС это как-то узколобо, особенно если нет каких-то технических ограничений, а их нет.

Поэтому я и предложил собирать ещё и msvc. Проблема которую так можно обнаружить может починить сборку ещё и на какой-нибудь netbsd или haiku. Для которых с CI сложнее.

Учить новый скриптовый язык для каждой ОС как-то не особо хочется.

Я бы не пренебрегал возможностью выучить что-либо новое. Тем более что «выучить» слишком сильное слово для того чтобы посмотреть базовый синтаксис и разобратся как выполнить пару команд.

Об этом не надо думать, вы же используете кросс-платформенные API и библиотеки.

Там есть платформозависимый код, в этом файлике в основном, определение языка системы, папки с конфигом и сохранением (в линуксе XDG_DATA_HOME, в винде %LOCALAPPDATA%), всё такое, делала это всё по феншую (старалась).

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

Поддерживать ещё одно окружение ради нахождения недочётов в коде это как-то странно, соотношение результат/работа будет слишком низким.

Да и хватит об этом спорить, оно и так прекрасно работает на винде, даже лучше чем на линуксе.

Поддерживать ещё одно окружение ради нахождения недочётов в коде это как-то странно, соотношение результат/работа будет слишком низким.

Не вижу ничего странного. Более того, если бы вы его настраивали вместо кросс-компиляции, вы потратили бы столько же времени.

Да и хватит об этом спорить, оно и так прекрасно работает на винде, даже лучше чем на линуксе.

Я не спорю, я делюсь опытом. Но не надо - так не надо.

Игра написана на недоязыках, а иногда ещё и нескольких. Типа hedgewars с игрой на Qt, ланчером на fpc (или наоборот) и сервером на haskell. Или spring с куском AI на жаве.

«Недо-» они с т.з. опакечивания или…