Lazarus жив вообще ?

[Максим]

betatester

Во-первых, все как раз наоборот - структура LCL более близка к WinAPI, а не к GTK Widgets - механизмы взаимодействия Widget основаны на "сигналах", а не на "Очереди сообщений" - это две принципиально разные, как по смыслу, так и по реализации, технологии. Таким образом, в LCL все это по отношению к GTK эмулируется, производя много лишнего кода.

Что наоборот? Как эта фраза противоречит тому, что я написал?
Я как раз и имел ввиду, что KOL ещё дальше от GTK Widgets, чем LCL

Во-вторых, использование LIBC - это нормальная практика программирования в Linux, стандарт де-факто и де-юре. И то, что FPC/Lazarus не использует LIBC говорит опять же про большую его заточенность под WinAPI.

По-моему, тут идёт путаница между библиотекой Libc и модулем Libc
Это разные вещи. Кстати, по-моему, как раз библиотеку Libc Lazarus использует.
Модуль же Libc заточен только под платформу Linux/i386, являясь наследием Kylix.

В третьих - не вижу никакой связи между Kylix и Linux/i386.

Не понял, почему. Он только на этой платформе и работал.

Кстати, а что это такое? Имеется в виду что-то из ряда Linux/PPC, Linux/Sparc и так далее?

Именно так

[tria]

улучшение Smart Link, уменьшение размера "экзешника"

У меня уменьшение размера произошло. Проект был 3.5 стал 2.8 (Дельфовый был 2.5). SpinEdit заработал наконец-то нормально, по переключению по Alt+tab перестало окно программы переходить из состояния развернутого на весь экран в обычное.
В общем, положительные сдвиги есть, наш паровоз вперед идет

[betatester]

Кстати, по-моему, как раз библиотеку Libc Lazarus использует.

Ага, использует. Аж 9 функций вызывает - типа setlocale(), tolower(), toupper(), iconv(), iconv_close(), iconv_open(), nl_langinfo(), wcscoll() и strcoll().

При этом объем библиотеки libc.so ~ 134КБайт, функций - несколько сотен штук.
Причем, характерно, что tolower() и toupper() в Lazarus вызываются, а в мой программе, которая использует функции UpperCase() и LowerCase() их нет.

[Attid]

кста интересно кто нибуть QT использует ?
довольно много правок было в той стороне, даже тот же куб от фаст репорта линуксовый вроде на кутю затачивается, хотя они наверно больше на кайликс стараются совместимостью, общался с ними в ростове слышал что в планах портировать фаст репорт у них есть и вроде даже какие-то подвижки в этом плане =)

в общем что-то я отвлекся, есть на форуме любители QT ?

[Brainenjii]

Я попробовал qt - текстовый редактор не мерцает, да и вообще, опрятней несколько... Только вылетает периодически ^_^ Таблицы рисуются значительно быстрей, чем в GTK2... Но невизуальные компоненты на форме не видны (ActionList, к примеру), и контролы игнорируют StatusBar, при Align = AlClient, так что нижняя часть пропадает ^_^ Плюс приложения не обращают внимания на темы оформления KDE3 и KDE4, настраиваются через qtconfig...
Вообще, хотелось бы помочь с этим делом, KDE мне больше по душе, чем GNOME, но даже не знаю с чего начинать...

[Attid]

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

[Павел Ишенин]

Я стараюсь все по qt сам фиксить.

[GrayEddy]

Насчет портирования KOL-CE.
Проверено - все работает хорошо, компоненты кидаются и настраиваются, экзешник выдается требуемого размера.
Но положу ложку дегтя в бочку меда - не работает табуляция.
Без мышки - это не жизнь .

[Максим]

betatester

Ага, использует. Аж 9 функций вызывает - типа setlocale(), tolower(), toupper(), iconv(), iconv_close(), iconv_open(), nl_langinfo(), wcscoll() и strcoll().

При этом объем библиотеки libc.so ~ 134КБайт, функций - несколько сотен штук.

Да, наверное. Только я это записал бы скорее в плюсы

[betatester]

betatester

Ага, использует. Аж 9 функций вызывает - типа setlocale(), tolower(), toupper(), iconv(), iconv_close(), iconv_open(), nl_langinfo(), wcscoll() и strcoll().

При этом объем библиотеки libc.so ~ 134КБайт, функций - несколько сотен штук.

Да, наверное. Только я это записал бы скорее в плюсы

Почему? Можете объяснить?

[Юра]

Насчет портирования KOL-CE.
Проверено - все работает хорошо, компоненты кидаются и настраиваются, экзешник выдается требуемого размера.
Но положу ложку дегтя в бочку меда - не работает табуляция.
Без мышки - это не жизнь .

Как говорится - RTFM. Для формы нужно включить Tabulate или TabulateEx.

[Максим]

betatester

Почему? Можете объяснить?

Могу.

1) Официально Glibc работает только под Linux (ну, и ещё под Hurd, см. подробнее, например, здесь). Соответственно, при активном её использовании, при портировании на другие *NIX будет присутствовать геморрой различной степени тяжести, в зависимости от используемой в них версии Glibc, степени её запатченности или, в худшем случае, совместимости собственной реализации её аналога.

2) При активном использовании этой библиотеки может регулярно возникать геморрой даже при переносе программы с одного дистрибутива Linux на другой, что было красочно проиллюстрировано, например, историей с fpide, где её использовали, а потом от неё пришлось отказаться. Связано это с регулярными мутациями этой библиотеки.

[betatester]

Вы мне, Максим, просто глаза открыли! Долго смеялсо.

Откройте, хохмы ради и просмотрите код того же AbiWord или mplayer, или вообще чего угодно, собираемого не из *.pas исходников - и вы найдете там "геморройную" libc и ссылки на ее функции - POSIX стандарт, как-никак! Видать, авторы сих программ не читали Википедии!

Видимо, поэтому у AbiWord не возникает никакого геморроя при переносе оного "с одного дистрибутива Linux на другой" - как в бинарном виде, так и в исходниках. А уж у GCC - который, о, ужас! тоже использует функции LIBC - и подавно!

И не путайте, пожалуйста, божий дар с яичницей - GNU LIBC - это РЕАЛИЗАЦИЯ стандартной библиотеки LIBC, а не отдельная по сути библиотека. Я, собственно, говорил про LIBC в целом. Которая ОФИЦИАЛЬНО поддерживается на ВСЕХ Unix-подобных системах + еще IBM OS/2 + Novell Netware и многое другое. Фактически, libc есть везде, кроме Window$.

И не читайте, а главное, не цитируйте Википедию в разговорах с программистами - моветон потому что.

[Sergei I. Gorelkin]

При переносе программ на C с одного дистрибутива на другой используется механизм configure, как раз для разруливания несоответствий. При этом за счет создания файлов .h, можно сказать, происходит модификация исходников.
У FPC такого механизма нет, отсюда и проблемы. Поэтому сам компилятор и RTL сделаны независимыми от libc (но если хочется, никто не мешает скомпилить их, определив символ FPC_USE_LIBC). Далее уже каждый решает, хочется ли ему связываться с libc, на свой страх и риск.
Лично у меня в Slackware файл libc.so представляет собой не ELF, а linker script, в котором написано, где на самом деле лежит libc. По этой причине не линкуется ни одна программа на FPC, в которой есть {$LINKLIB C}. Если же этот libc.so заменить симлинком на "правильную" libc, то программы на FPC линкуются нормально, зато не линкуется ни одна программа на C. Вот такие пирожки...

[betatester]

Сергей - тут есть две проблемы

1) Отсутствие механизма автоматического портирования *.h файлов и механизма, подобного configure. Configure - стандартный скрипт, обеспечивающий портирование - и от этого никуда не денешься. К тому же - он работает.
Разумеется, если раз в год-два править *.pas файлы в их описательной части - далеко не уедешь.

Получается ситуация, когда исходный коды в C САМИ настраиваются под окружение, а программы в *.pas нужно настраивать вручную, пересобирая при этом значительную часть библиотек компилятора! Парадоксально, не правда ли?
ИМХО это очень тормозит реальное применение FP/Lazarus для разработки программ, тем более кросс-платформенных.

2) В следствие 1) изначальная нацеленность FP на кросс-платформенность реализована весьма слабо - она ведь требует непрерывной ручной подстройки под конкретную OS и процессор. Кто-то когда-то что-то написал - и это что-то как-то работает и тянется от версии к версии. Хотя под рукой есть стандартные библиотеки стандарта POSIX, которые могли бы решить множество проблем (они для этого и писались - для кросс-платформенности!)

Как Вы полагаете - как правильнее делать - базовые функции OS syscall'ами вызывать или все же из libc? Что более правильно в смысле переносимости и кросс-платформенности?

Что касается Вашего случая с libc - то это странно, ведь Вы и программы в сходниках С при линковке используете одну и ту же программу - линковщик ld. Если она работает при сборке того же GCC - должна работать и при сборке FPC. А коли не работает - значить что-то в исходниках FPC не так - согласны?