Можно ли использовать wxWidgets без установки? (т.е. просто положить so в папку с программой)

Нельзя.

А собрать статически не вариант?

«подключением» занимается wx-config. можешь посмотреть ее хелп и что она делает. в принципе она не делает ничего особенного, выдает нужные инклуды и дефайны (–cflags), нужные для компиляции и линка, и проч инфу. вот если скопировать то ,что она выдаст, и вписать ручками это в вызов gcc например, то можно делать без нее.

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

то есть если разобраться, где ее либы (это знание имеет описание пакета для смаке), который ты используешь в строке

find_package(wxWidgets REQUIRED COMPONENTS gl core base)

и какие ключи нужны компилятору - «wx-config –cflags», то ты отвяжешься и от пакета смаке и от wx-config

про «просто положить в папку» сказать не могу, она использует другие системные либы, типа гномовских, если у тебя в варианте wxwidgets c гном-беком.

Не надо гладить кошку против шерсти. Сначала делай так, как предписывают системные гайдлайны: они не от балды написаны. Потом, набив собственных шишек и поняв как всё это устроено, ты можешь сказать: «это плохо сделано, я знаю как сделать лучше»… (и не сделать).

Возвращаясь к твоему вопросу: В чём проблема поставить wxWidgets? С помощью системного пакетного медеджера ты легко можешь поставить, снести или обновить wxWidgets. wsWidgets — популярная либа, я не думаю что есть дистры, в которых эта либа не опакечена в штатных репозиториях. Штатные майнтейнеры более-менее оперативно реагируют и выпускают апдейты при появлении новых версий или секурных патчей. Какой смысл отказываться от всех этих услуг, которые тебе ничего не стоят? Что ты выиграешь, если будешь «просто таскать этот wxWidgets с собой»? Пока что у тебя просто не получается. Наоборот, ты имеешь проблему с cmake, с которой сам не можешь справиться. Это говорит: твой первоначальный вывод о том, что таскать wxWidgets с собой просто, был неверен: таскать wsWidgets собой непросто. Не гладь кошку против шерсти.

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

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

вот если скопировать то ,что она выдаст, и вписать ручками это в вызов gcc например, то можно делать без нее.

Вот я просто тупо попробовал в терминале набрать:wx-config --cflags Он выдал в ответ:

bash: -I/usr/local/lib/wx/include/gtk3-unicode-3.1: No such file or directory

А каким ещё способом можно увидеть результат работы этой wx-config ? Просто это явно не то, ну, или тут мало информации.

А собрать статически не вариант?

Я бы сказал, что это «крайний случай» из-за специфики проекта.

Сначала делай так, как предписывают системные гайдлайны: они не от балды написаны.

Если бы мне не нужно было сделать иначе, то я бы не задавал этот вопрос. У меня очень специфическая задача, поэтому я и ищу как тут вывернуться из этой ситуации.

вот что оно выдает у меня, после нормальной инсталляции:

-I/usr/local/lib/wx/include/gtk3-unicode-3.2 -I/usr/local/include/wx-3.2 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread

то бишь показывает где лежат хидеры моего варианта wxwidgets и несколько дефайнов нужных для компиляции.

инклуды у тебя будут другие, дефайны те же.

Кстати, может это и всё:

bash: -I/usr/local/lib/wx/include/gtk3-unicode-3.1: No such file or directory

потому что по указанному пути действительно лежит тот самый setup.h. Я чуть позже попробую тут поэксперементировать

А можете ещё дать результат для строки wx-config --libs std,gl ? У меня почему-то мало данных выдается

Большое спасибо за помощь!

эти дефайны(или вроде того, не знаю какая у вам модель памяти и все такое) нужны по любому, для компиляции, иначе она с ума сойдет

-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread

Дубров, Д. В. Система построения проектов CMake : учебник для вузов

После прочтения много вопросов отпадут сами собой.

сборочная конфигурация ?

WxWidgets довольно взрослая система (мягко говоря) и вполне конфигурится на разные версии.

man wx-config

можно указать --prefix=где_лежит_версия --exec-prefix=куда_ты_перетащил_so_шки

там с деплоем потом могут сложности, но опять-же «читайте маны они рулят».

Если бы мне не нужно было сделать иначе, то я бы не задавал этот вопрос.

Ты не поверишь, как много людей делают всё через жопу, оправдывая это тем, что им «так надо». Один мой коллега всегда задавал вопрос: «А что ты хочешь получить?», потому что люди часто задают совсем не тот вопрос, который стоило бы задать. Ну да ладно.

Ты не ответил на простой вопрос: В чём проблема поставить wxWidgets? Не хочешь — не говори, твоё дело. Но дальше без меня.

В чём проблема поставить wxWidgets?

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

И где гарантия что системный пакет с wx не изломают при очередном глобальном и надёжном обновлении?

Тут по сути 3 уровня сложности отвязки от абсолютных путей:

1. сделать чтоб приложение искало .so-шки по относительному пути через пути $ORIGIN/../lib в RPATH
2. если wxwidgets ищет не только .so-шки, а какие-то ресурсы в файлах - то тут больше всгео вопросов, как реализован их поиск
3. и максимальный - в исходном посте описан именно он - ещё и сборку так сделать.

Решения по этим уровням сложности чуть разные, и НЕ стоит начинать решение с третьего

1. как правило делается, через манипуляции с путями поиска .so-библиотек. Или на уровне cmake или на уровне постобрабтки готовых бинарников
2. Тут специфика библиотеки. Иногда где-то в районе начальной функции приложения приходится определять свой абсолютный путь и зарегистрировать в библиотеке путь к хранилищу. К слову получить путь где лежит бинарник довольно сложно - если в agrv[0] относитеьлный путь, а пользователь в процессе работы через диалог открытия файла изменил текущую директорию - получать уже поздно. Есть всякие утилиты из буста для этого
3. Имхо в таком виде нереально. Скорее организовать процесс сборки так, чтоб релиз собирался не на машине разработчиска с некоей версией, а в фиксированном окружении с желаемой версией. И потом добавлять эту самую версию в релиз. Часто выбирают достаточно старое, чтоб не прилинковалось к слишком новому libc. Способ выбора окружения - разный: можно контейнеры (самое простое), можно виртуалку, можно вообще эмуляцию окружения линковки через С++-кросс-линковщик zig сс

Пока удалось добиться немногого, но всё же… На debian собрал динамические либы, нашел после сборки файл setup.h, либы засунул прямо в папку с проектом, а setup.h закинул в общую папку с заголовками wxwidgets. Закинул те, настройки, которые вы мне дали, но оказалось, что стартует уже с 3-я библиотеками: wx_gtk3u_gl-3.2 wx_baseu-3.2 и lwx_gtk3u_core-3.2

Всё это я проделал в Code::Blocks. Потом взял этот проект и скопировал в Fedora-у. И тут по какой-то непонятной причине повылезали ошибки линковщика:

./libwx_baseu-3.2.so: undefined reference to `lstat64@GLIBC_2.33'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFGetVersion@LIBTIFF_4.0'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFReadDirectory@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `pcre2_config_32'
./libwx_gtk3u_gl-3.2.so: undefined reference to `wl_proxy_marshal_flags'
./libwx_baseu-3.2.so: undefined reference to `pcre2_code_free_32'
./libwx_baseu-3.2.so: undefined reference to `pthread_mutexattr_init@GLIBC_2.34'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFReadRGBAImageOriented@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `pcre2_get_ovector_pointer_32'
./libwx_baseu-3.2.so: undefined reference to `fcntl64@GLIBC_2.28'
./libwx_baseu-3.2.so: undefined reference to `explicit_bzero@GLIBC_2.25'
./libwx_baseu-3.2.so: undefined reference to `stat64@GLIBC_2.33'
./libwx_baseu-3.2.so: undefined reference to `pthread_create@GLIBC_2.34'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFDefaultStripSize@LIBTIFF_4.0'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFWriteScanline@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `pcre2_match_data_create_from_pattern_32'
./libwx_gtk3u_core-3.2.so: undefined reference to `_TIFFfree@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `dlclose@GLIBC_2.34'
./libwx_baseu-3.2.so: undefined reference to `std::__exception_ptr::exception_ptr::_M_release()@CXXABI_1.3.13'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFGetField@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `pthread_setname_np@GLIBC_2.34'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFScanlineSize@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `pthread_key_delete@GLIBC_2.34'
./libwx_gtk3u_core-3.2.so: undefined reference to `gdk_wayland_display_prefers_ssd'
./libwx_gtk3u_core-3.2.so: undefined reference to `pow@GLIBC_2.29'
./libwx_baseu-3.2.so: undefined reference to `dlsym@GLIBC_2.34'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFClose@LIBTIFF_4.0'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFClientOpen@LIBTIFF_4.0'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFFlush@LIBTIFF_4.0'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFRGBAImageOK@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `pthread_setspecific@GLIBC_2.34'
./libwx_baseu-3.2.so: undefined reference to `dlopen@GLIBC_2.34'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFGetFieldDefaulted@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `fstat64@GLIBC_2.33'
./libwx_baseu-3.2.so: undefined reference to `dlerror@GLIBC_2.34'
./libwx_baseu-3.2.so: undefined reference to `pthread_getspecific@GLIBC_2.34'
./libwx_baseu-3.2.so: undefined reference to `pcre2_compile_32'
./libwx_baseu-3.2.so: undefined reference to `pthread_mutex_trylock@GLIBC_2.34'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFSetField@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `pcre2_match_data_free_32'
./libwx_baseu-3.2.so: undefined reference to `pthread_join@GLIBC_2.34'
./libwx_baseu-3.2.so: undefined reference to `pthread_mutexattr_settype@GLIBC_2.34'
./libwx_baseu-3.2.so: undefined reference to `pcre2_match_32'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFSetWarningHandler@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `std::__exception_ptr::exception_ptr::_M_addref()@CXXABI_1.3.13'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFSetErrorHandler@LIBTIFF_4.0'
./libwx_gtk3u_core-3.2.so: undefined reference to `_TIFFmalloc@LIBTIFF_4.0'
./libwx_baseu-3.2.so: undefined reference to `pcre2_get_error_message_32'
./libwx_baseu-3.2.so: undefined reference to `dladdr@GLIBC_2.34'
./libwx_gtk3u_core-3.2.so: undefined reference to `TIFFSetDirectory@LIBTIFF_4.0'

Не очень понимаю, почему debian собирает, а fedora - нет. Пока стал думать, что может 3-х библиотек всё же мало, но кажется «лишние» я удалил, чтобы не запутаться. Стал пересобирать, но может что-то напутал, потому что Fedora вновь созданные библиотеки вообще не хочет кушать (я вообще никаких флагов не ставил ни в первый ни во второй раз, поэтому пока не понимаю, в чем дело).

Пока застрял, короче…

можно указать –prefix=где_лежит_версия –exec-prefix=куда_ты_перетащил_so_шки

Честно говоря, пока вообще не представляю, что с этим делать, а man wx-config посылает меня куда подальше, аргументируя чем-то в стиле «мануала нет»

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

Если хозяин компа против установки wxWidgets, то не стоит её туда ставить. В случае сурового работодателя обходить явные запреты конторы вряд ли стоит, особенно если контора особо закрытая: можно по шапке получить и работы лишиться.

Технические, не политические (I mean policy, not politics) варианты есть?

Пока застрял, короче…

Держи нас в курсе. Простые решения они такие. ;-)

Честно говоря, пока вообще не представляю, что с этим делать, а man wx-config посылает меня куда подальше, аргументируя чем-то в стиле «мануала нет»

и яндекс с гуглом тоже посылают ? чем аргументируют ?? :-)

прям в строку поиска вбей «man wx-config»

2. если wxwidgets ищет не только .so-шки, а какие-то ресурсы в файлах - то тут больше всгео вопросов, как реализован их поиск

Специально для этой цели существует $XDG_DATA_DIRS. https://specifications.freedesktop.org/basedir-spec/latest/

Обычно адекватный софт поддерживает этот вариант.

Конкретно про wxwidgets не знаю, близко с ней дела не имел.

3. Имхо в таком виде нереально.

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

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

Не могу поспорить с вашей логикой. Хорошо, попробую объяснить, потому как это, действительно может прояснить ситуацию.

А пытаюсь сделать Среду разработки на C++. Практически, у меня есть своя библиотека, к которой прилагается визуальный редактор для создания GUI-интерфейса + к этому, естественно, можно код писать прямо у меня внутри этого редактора. Но компилятора у меня нет. Но есть функция экспорта в некоторые среды типа Visual Studio и Code::Blocks, а также есть вариант с CMake. Короче я ручками генерирую проект для этой Visual Studio, а потом она его открывает и там всё должно собираться и работать также, как это было сделано в моём визуальном редакторе. Всё это усугубляется тем, что мне нужны и Linux-платформы и желательно Mac OS.Здесь я пока и застрял, потому как более-менее разбираюсь только в Windows. Для остальных платформ я вынужден был взять wxWidgets в качестве прослойки по взаимодействию с OS (я бы может быть взял SDL, но там нет нормального Drag & Drop). И сейчас я упираюсь в странные для меня подходы, которые приняты в Linux-ах за норму. Например, я хотел бы после генерации проекта для Linux-а, чтобы он без проблем запускался, а не требовал от пользователя глубокого погружения в эту тему. Т.е. у меня основная проблема в том, что я хотел бы закрыть от пользователя весь тот ад, который существует на Linux-ах. Т.е. то что я выдаю как результат, желательно, чтобы собиралось с минимальными телодвижениями. Надеюсь,что более-менее объяснил…

Надеюсь,что более-менее объяснил…

Нет.

Я не буду говорить «не нужно» или задавать вопросы «а чем это лучше XXX?» — ну, хочется тебе писать среду разработки — пиши ради бога.

Непонятно какие проблемы у тебя с wxWidgets. Чем тебя не устраивает штатно установленная wxWidgets? dnf install wxGTK3-devel не требует «глубокого погружения в тему», особенно если ты таки осилишь создание rpm-пакета с твоей средой разработки, в котором будет прописана зависимость от пакета wxGTK3-devel. В таком случае пользователь твоей среды разработки вообще ничего не обязан знать о wxWidgets — зависимости будут подтянуты и установлены автоматически.

Что дальше? Твоей среде разработки нужно знать с какими ключами компилировать исходники и с какими ключами линковать экзешник, чтобы заголовки нашлись и нужные библиотеки подключились. Здесь в теме кто-то уже упоминал программу wx-config: wx-config --cppflags вернёт тебе флаги компилятора, wx-config --libs вернёт тебе флаги линкера. Например, на моей системе:

$ wx-config --cppflags
-I/usr/lib64/wx/include/gtk3-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__

$ wx-config --libs
-pthread   -lwx_gtk3u_xrc-3.0 -lwx_gtk3u_webview-3.0 -lwx_gtk3u_html-3.0 -lwx_gtk3u_qa-3.0 -lwx_gtk3u_adv-3.0 -lwx_gtk3u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 

В чём проблема вызвать wx-config два раза и полученные флаги использовать при генерации проекта для Code::Blocks?

Если я собираю динамические библиотеки и пытаюсь их подключить, то проблема возникает уже на этапе подключения заголовков, потому что требуемый файл setup.h вообще отсутствует в папке include.

И правильно отсутствует:

$ wx-config --cppflags
-I/usr/lib64/wx/include/gtk3-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__

Первый ключ -I видишь? Угадай, зачем он нужен:

$ ll /usr/lib64/wx/include/gtk3-unicode-3.0
total 4
drwxr-xr-x. 2 root root 4096 Apr 27  2023 wx

$ ll /usr/lib64/wx/include/gtk3-unicode-3.0/wx
total 28
-rw-r--r--. 1 root root 26664 Jan 21  2023 setup.h

Опаньки, setup.h нашёлся!

Угадай, зачем он нужен:

Дык, у меня и нет проблемы с подключением setup.h - я же выше написал, что я его переложил в папку с основными заголовками. А ничего другого в папке /usr/lib64/wx/include/gtk3-unicode-3.0 больше нет, поэтому путь этот подключать незачем - можно просто файл скопировать.

я его переложил в папку с основными заголовками.

Т. е. решил таки через жопу. Ладно, удачи.

И тут по какой-то непонятной причине повылезали ошибки линковщика:

либы он не видит glibc и tiff. какая там в федоре ld_library_path?

К слову получить путь где лежит бинарник довольно сложно - если в agrv[0] относитеьлный путь, а пользователь в процессе работы через диалог открытия файла изменил текущую директорию - получать уже поздно.

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

либы он не видит glibc и tiff. какая там в федоре ld_library_path?

На echo $LD_LIBRARY_PATH не печатается ничего, т.е. видимо эта переменная не задана

Чем тебя не устраивает штатно установленная wxWidgets?

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

у тебя линкер похоже не знает, где либы нужные лежат.

почитай тут например. https://uzverss.livejournal.com/57883.html?ysclid=m4g78dzoaw663918429

Если бы мне не нужно было сделать иначе, то я бы не задавал этот вопрос

man Проблема XY

Самое близкое из того, что тебе предложили – это статическая линковка. Это даже не «рядом с», это «внутрь».

пытаюсь сделать Среду разработки на C++

у меня основная проблема в том, что я хотел бы закрыть от пользователя весь тот ад, который существует на Linux-ах

Вот здесь у тебя противоречие. Твои пользователи – это разработчики, и далеко не все из них будут тебе благодарны за то, что ты от них пытаешься закрыть. Более того, скорее всего, будут в претензии, что ты навязываешь им определённую версию wxWidgets вместо той, которая у них в репах.

Для меня, как разработчика, никакого ада в линуксах нет. Наоборот, для программиста линукс гораздо удобнее. В линуксе есть valgrind. В линуксе я для притаскивания внешней библиотеки просто пишу -l <имя библиотеки>, а не страдаю с абсолютными путями, как в винде. Если я пишу в линуксе, а в винде только собираю и тестирую, оно в 99% работает сразу. Если наоборот – начинается веселье, например, программист опечатался и написал #include <Math.h>, и что самое замечательное, винда это скушает, а потом под линуксом, макосью и прочими юниксами придётся расхлёбывать, и стопудово не в одном месте, а в десятках разных. :)

Давай начнём немножко с другого.

1. Что ты пишешь – опенсорс или проприетарщину?

2а) Если опенсорс, то под какой лицензией?

2б) Если проприетарщину, то сколько у неё будет пользователей, другими словами, она будет свободно продаваться или пишется под заказ, а может, просто закрыто-бесплатная, как Opera/Vivaldi? Если заказная разработка – предусматривает ли договор передачу исходников заказчику? (Это диктует и способы распространения, и многое другое.)

Ну, по крайней мере, на MAC OS, я собрал пусковой файл своей программы, а он запускается только там, где я его собрал. Т.е. я взял и поставил другую MAC OS и там уже не работает.

Это возможно. Гугли в сторону «Run-Path Dependent Libraries». Читай что написано в доках.

Но, если там заново пересобрать проект, то запускается. Т.е. я пока вообще не понимаю, как распространять пусковой файл.

Во-первых, думай — чем отличается старый экшешник от пересобранного? Читай доки. Станешь понимающим и опытным, а не макакой, слепо следующей чужим советам.

Во-вторых, каким образом твои проблемы на маке влияют на линукс? Почему из-за твоей неспособности справиться с маком ты начинаешь на линуксе делать всё через жопу?

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

В интерненте на одного нормального приходится десять неадекватов. Если тебе скажут в колодец окно прыгнуть — прыгнешь? Или таки научишься отличать разумные советы от неадекватных?

Если называть вещи своими именами, то твоё «избавление от зависимостей» на самом деле означает «затащить зависимости в пакет». Это не рекомендуется гайдлайнами, например, федоровскими. Скорее всего, в остальных дистрах есть подобные требования.

⁂

Судя по твоим проблемам (то setup.h не нашёлся, то приложение не запускается), ты не являешься опытным разработчиком. Ещё раз: гайдлайны написаны людьми, которые в разы опытнее тебя. Ты должен следовать гайдлайнам, а не принимать свои собственные черезжопные решения, основываясь на советах неадекватов из интернета.

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

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

В линуксе я для притаскивания внешней библиотеки просто пишу -l <имя библиотеки>, а не страдаю с абсолютными путями, как в винде.

Вот тогда как раз к вам у меня вопрос по поводу удобства. У меня следующая проблема. Я могу собрать wxWidgets либо на Debian, либо на Fedora. Могу всё это подключить к проекту и всё это стартует, но стоит мне переместить этот проект целиком (т.е. вместе с wxWidgets) из Debian в Fedora или наоборот (а я пробовал и так и так), то там происходит ошибка линковки. Удалось установить, что проблема в следующем:

/usr/bin/ld: предупреждение: libtiff.so.5, нужное для __MagicDev__/wxwidgets/lib/libwx_gtk3u_core-3.1.so, не найдено (попробуйте задать -rpath или -rpath-link)

Это пишет Debian, у которого имеется libtiff.so.6. У Fedora, соответственно, всё наоборот - у неё есть только libtiff.so.5. И, как я понимаю, это и есть проблема. Теперь как это исправить ? Я сначала пробую скопировать из Fedora эту libtiff.so.5 и просто положить её рядом с остальными библиотеками. Не находит. Тогда я пытаюсь скопировать эту библиотеку в /usr/lib - опять не находит. Далее я пытаюсь положить эту библиотеку рядом с libtiff.so.6, которая лежит уже в /usr/lib/x86_64-linux-gnu, но опять нет. Я просто не понимаю, почему оно не находится, и этим я полночи занимался. Я уж не знаю… может опять дело в каких-то правах. Но всё это точно к удобству не имеет никакого отношения.

Если я пишу в линуксе, а в винде только собираю и тестирую, оно в 99% работает сразу.

С этим я абсолютно согласен, но я это объясняю с точностью до наоборот.

2б) Если проприетарщину, то сколько у неё будет пользователей,

Понятия не имею. Я все риски беру на себя в таких случаях. Понравится, значит пойдет, а не понравится, то не пойдет. Пока не дойду до уровня, чтобы это можно было показать, и получить обратную связь, всё так и будет в неопределенности.

Если заказная разработка – предусматривает ли договор передачу исходников заказчику?

Не… Я не настолько богат, чтобы тратить свою жизнь на обогащение какого-нибудь «дяди» с сомнительными моральными качествами. Так что у меня всё своё и всё самостоятельно.

у тебя линкер похоже не знает, где либы нужные лежат.

Оказалось, что Fedora имеет libtiff.so.5, а Debian libtiff.so.6. И этот wxWidgets не может найти нужную версию, когда я его переношу между этими OS. Вот пока на этом застрял.

Оказалось, что Fedora имеет libtiff.so.5, а Debian libtiff.so.6. И этот wxWidgets не может найти нужную версию, когда я его переношу между этими OS. Вот пока на этом застрял.

Прикинь, wxWidgets, установленный из штатной репы, будет работать именно с той libtiff.so, которая есть в этом дистрибутиве.

негр-с-пальцем-у-виска.jpg

Что будешь делать дальше? А почему бы тебе не таскать libtiff.so с собой?! Фигли, wxWidgets же ты решил взять, бери и libtiff до кучи.

Чего вы на человека накинулись? Он старается, проприетарно импортозамещает, а вы его заставляете делать хорошо, а не как он хочет.

Сделай всё сначала только для Windows, а потом найми человека, который тебе для UNIX-like систем настроит сборку.

Сделай всё сначала только для Windows, а потом найми человека, который тебе для UNIX-like систем настроит сборку.

Ну, я Windows уже сделал. А так да… мысль вполне рабочая. Желающие есть ?

Это называется «проблема XY».

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

Полагаю, что в таком случае и с такими заявками лучше поискать другой форум, а не спрашивать на том, который «почти не существует».

/thread

Полагаю, что в таком случае и с такими заявками лучше поискать другой форум, а не спрашивать на том, который «почти не существует»

Не очень понял, в чем причина вашего недовольства. Объективно программистов на Unix-ах очень мало по сравнению с программистами на Windows. И что тут обидного мне не очень ясно. Да, я буду ориентироваться на большинство - это логично.

Можно, офф.сайт читал?

https://www.wxwidgets.org/blog/2019/01/wxwidgets-and-vcpkg/

Там правда пример для VS, но на CMake переделывается просто, можешь попробовать для начала более простые vcpkg пакеты поставить, для тренировки.

Будет примерно так:

...

find_package(wxWidgets REQUIRED COMPONENTS core base)
include(${wxWidgets_USE_FILE})
target_link_libraries(${PROJECT_NAME} ${wxWidgets_LIBRARIES})

...

Будет примерно так:

Так ведь это просто требование иметь этот wxWidgets в установленном виде. Да, CMake на него наткнется, но он же ничего ставить автоматически не будет, а просто напишет, что wxWidgets отсутствует и остановится. У меня и сейчас то же самое написано в этом CMakeLists.txt. Или я вас не так понял ?