Линковка с кроссплатформенными либами для C vs жабамашина vs интерпретаторщина (аля пистон)

Qt

Поддерживаю

озвучьте задачу монсеньор и таргет-платформу, тогда можно будет что-то сказать

таргет-платформу

Сначала на мастдае, чтоб потом плавненько перевести на линь.

Джава. Производительность приличная, с портируемостью проблем нет. Только вот память жрет.

Qt

Тут Вам и сеть, и работа с файлами (+stdin/out).
Там же можно делать ГУИ.

В смысле Линукс наше всё, но жизнеспособность софтина должна показать и в винде.

Хорошо. А какие из этих языков ты знаешь?

Limbo, luajit, nekovm, parrot если не перекомпилировать.
Множество ЯП, хоть го, хоть хаскель, если перекомпилировать возможно.

без задачи сложно о чем-то говорить, но КМК в boost можно найти все:

Для движка, работающего с файлами, сетью и STDIN/STDOUT.

А гуй уже лепить в зависимости от платформы на WPF / PyGTK. Ибо одинаковый гуй под все платформы нарушит HIG этих всех платформ и по-хорошему должен быть реализован под каждую платформу отдельно.

тогда альтернатив qt нет

а существуют приложения линкующиеся с отдельными либами qt, а гуй пользует gtk?

Я бы накидал приложения за 15-30 минут, но мне лень.
Но вообще таскать с собой 2 тулкита ради одного приложения - это не совсем комильфо.

Java, можно попробовать таскать в каталоге и саму виртуальную машину (не знаю, сейчас это разрешено по лицензии?). Скорости хватит на любое приложение, безопасность, важная при работе с сетью и все такое.

А в qt есть аналог ncurses?

Насколько я знаю - нет.
Все же в первую очередь это библиотека для разработки GUI. Была во всяком случае.

А если при qt + ncurses, в винде проблем не будет?

ncurses
в винде

Не очень понятно, зачем Вам в винде использовать псевдографику (или я чего-то не знаю об ncurses?).

Вообще проблем быть не должно, но я лично не проверял.

Скомпилированная программа на C запустится на любом 32-битном ядре Linux! А если на 64-битном - то на любом 64-битном! Для этого делаем ldd faileg и смотрим библиотеки-зависимости. Здесь 4 варианта: библиотеки иксов - есть везде. Библиотеки из стандарта LSB (всякие там libc, libz, libm - есть везде), libstdc++ - есть везде, но есть проблема. Если компилируем программу с версией 6.0.12, то на 6.0.13 и последущих программа будет работать, а на 6.0.11 и более поздних - нет. Вывод: кладём библиотеку вместе с программой при распространении, либо берём компилятор GCC 4.0 и компилируем программу в нём - тогда она запустится везде. И четвёртая библиотека libGL, есть в каждой системе и её ни в коем случае нельзя класть с программой.

Остальные библиотеки, не перечисленные выше - кладём с программой и несём в архиве с ней. Кроме тех, которые не менялись в дистрибутивах много лет. libpng и libopenal? Берём с собой. libQt? Не берём с собой.

Затем пакуем в RPM, DEB и tar.XXX, и распространяем, запустится у всех. Если код открыт, делать бинарники совсем не обязательно, а можно сделать и их, и src.rpmи deb-src.

С Linux разобрались, с Mac, Windows, BSD и Solaris не знаю, ни разу под ними не компилировал.

> и более поздних

И более ранних

Вывод: кладём библиотеку вместе с программой при распространении, либо берём компилятор GCC 4.0 и компилируем программу в нём - тогда она запустится везде

шел бы отсюда в другое место пороть чушь

То есть, по-твоему программа на C++, скомпилированная с GCC 4.0, не запустится на libstdc++ всех последующих версий? Или скомпилированная с GCC 4.5 запустится на libstdc++ от GCC 4.0? libstdc++, напомню, стала частью GCC, и версия so.6 появилась в GCC 4.0.

То есть, по-твоему программа на C++, скомпилированная с GCC 4.0, не запустится на libstdc++ всех последующих версий?

ABI libstdc++ иногда меняется, ее лучше таскать с собой. Я вообще не советовал бы использовать глюкодром под названием «GCC 4.0». К тому же, дело не столько в libstdc++, сколько в libc, использующей версии символов.

Лучше взять GCC 4.4 на CentOS 5 и прихватить все зависмости, включая libstdc++. Проблем не будет.

libQt? Не берём с собой.

...и получаем дикие грабли

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

На самом деле можно, если собрать месу с софтверным рендерингом

> ABI libstdc++ иногда меняется, ее лучше таскать с собой.

Хм, не знал. Ты имеешь в виду то что so.5 сменилось на so.6, а потом будет so.7? Или прямо so.6 сам с собой становится несовместим?

> Лучше взять GCC 4.4 на CentOS 5 и прихватить все зависмости, включая libstdc++. Проблем не будет.

Проблем не будет- ну, да в принципе. С компиляцией во всяком случае точно не будет проблем, а вот с запуском... Я про старые дистрибутивы, года 2006-го. На старый компьютер другую систему и не поставишь, а новые программы не все ресурсоёмкие, они могут работать и там.
Раз так, то положить библиотеку в архив с программой будет лучше, чем компиляция в GCC 4.0. В обоих случаях запускаться будет везде.

>> libQt? Не берём с собой.

...и получаем дикие грабли

Не знаю как избавиться, у меня Skype запускается везде, а imageshack-image-uploader - на некоторых компьютерах только. Подозреваю, что если Qt был новый, то программа как и в случае выше не заработает со старым.

>> И четвёртая библиотека libGL, есть в каждой системе и её ни в коем случае нельзя класть с программой.

На самом деле можно, если собрать месу с софтверным рендерингом

Софтварный лучше реализовать через SDL, а не через Mesa OpenGL. Например, Quake 2 не имеет зависимости от OpenGL, так как работает или в режиме SDL, или в режиме OpenGL.

Скомпилированная программа на C запустится на любом 32-битном ядре Linux!

Брехня

То есть, по-твоему программа на C++, скомпилированная с GCC 4.0, не запустится на libstdc++ всех последующих версий?

далеко не каждая современная программа на С++ соберется с gcc 4.0, ну да ладно, дело не в libstdc++, а в libc - и я тебе уже это писал

Или скомпилированная с GCC 4.5 запустится на libstdc++ от GCC 4.0?

опять же дело не в самом libstdc++, его, при определенных условиях, вообще можно статично линковать

берём компилятор GCC 4.0 и компилируем программу в нём - тогда она запустится везде

только если таскать все с собой, и то не факт, что все срастется и подхватится, или вообще не вывалится с крешем в одной из библиотек, в частности «ванильный» wx2.8 в убунте 11.10 прекрасно себе падает при некоторых операциях, фикс есть в 2.9, но он еще нестабильный, а если не таскать с собой - то все библиотеки нужных версий далеко не в каждом дистрибутиве найдутся

Я про старые дистрибутивы, года 2006-го.

Если у тебя не serious business и не программа для выч. кластеров, все что старше RHEL 5 можно считать безнадежно устаревшим.

На старый компьютер другую систему и не поставишь.

Заливаешь.

Подозреваю, что если Qt был новый, то программа как и в случае выше не заработает со старым.

В точку. Поэтому есть только два выхода: юзать 4.2 (LSB) или тащить с собой.

Софтварный лучше реализовать через SDL, а не через Mesa OpenGL.

По-моему это совсем не в тему, или SDL предоставляет бинарную совместимость с libGL?

+1

> Поэтому есть только два выхода: юзать 4.2 (LSB)

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

>> Софтварный лучше реализовать через SDL, а не через Mesa OpenGL.

По-моему это совсем не в тему, или SDL предоставляет бинарную совместимость с libGL?

ldd по «quake2» не выдаёт зависимости от libGL, я об этом. Хотя при наличии OpenGL программа может работать через него, а может и софтварно.