Lazarus жив вообще ?

[FedeX]

betatester
Чем вы не согласны с последним постом Sergei I. Gorelkin ? Если хотите - берите и используйте libc. Это не проблема. И пусть ваши программы будут маленькими и шустрыми под Линуксом
А LCL по-моему от тучности уже не спасти. Большинство тех, кто её разрабатывает, видимо, пишут бухгалтерский или научный софт и фраза "размера итогового кода программы" для них - пустой звук
Так что KOL вам в помощь (извините что всё время пиарю её - всё ещё не отпустило удовлетворение от 42кб )

[betatester]

FedeX

Вы читали мое сообщение? Проблема, еще раз, в том, что существующий механизм организации в FreePascal интерфейса к ЛЮБОЙ динамической библиотеке ущербен по своей сути.

Кто-то когда-то сделал порт *.h файлов в Unit и все радуются. Повторюсь - вот что пишут про интерфейс к libc:

The translation was done on a SuSE 8.1 machine:
Kernel version: 2.4.18
glibc version: 2.3

Этим пользоваться сейчас не реально - простите, ядро 2.4.18 было выпущено 25 февраля 2002 года! ПЯТЬ лет назад (скоро уж шесть). Понимаете?
Я не могу "брать и использовать" libc, как это Вы и Сергей мне рекомендуете - опасаюсь, знаете ли, за стабильность своего кода!

И такие рекомендации, как дает Сергей - называются просто - отмазки, уж извините.

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

Или Вы мне прикажете вручную добавлять изменения в базовые классы FreePascal при каждом существенном обновлении ядра и системных библиотек?

Простите, мне будет много проще соскочить с FPC/Lazarus и портировать проект под GTK2 widgets - воистину - я основной объем работы сделаю один раз и уже ничего регулярно переделывать не буду.

[alexs]

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

если их вызов меняется - то в любом случае надо изменять исходники - и сразу слать патчи в fpc/lazarus
(а что делают сишники в этой ситуации?)

если вызов не меняется - то какая вам разница что измекнилось в других функциях? программа от этого перестанет работать?

[betatester]

alexs

Моя программа использует вызовы из многих библиотек. И во многих случаях - например, gdk_pixbuf, libx и прочее - выясняется, что самый свежий интерфейс в FPC/Lazarus Units для этих библиотек (обычно 3-5 лет не изменявшийся) не соотв. действительности.

Приходится:
1)Описывать необходимые мне функции вручную
2)Пользоваться интерфейсом libdl и функцями run-time загрузки библиотек типа dlopen/dlsym/dlclose.

Меня лично это напрягает.

[alexs]

дык может изменения в описании интерфесв кинеш в исходники fpc?

[betatester]

Вот, пожалуйста - http://freepascal.ru/forum/viewtopic.php?t=2898

А все остальное - только один модуль SIVideo вызывает, к примеру, порядка 60 X* функций, из которых 29 вызываются динамически через dlopen/dlsym. Если бы я писал на C - мне бы это делать не потребовалось.

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

Такие дела.

[alexs]

А все остальное - только один модуль SIVideo вызывает, к примеру, порядка 60 X* функций, из которых 29 вызываются динамически через dlopen/dlsym. Если бы я писал на C - мне бы это делать не потребовалось.

т.е. вся проблема в том, что существующий интерфейс модулей просто устарел.
На мой взгляд, эта проблема имеет непосредственное отношение к тому, что fpc ещё не получи долного распространения. Но, я надеюсь, тенденция увеличения чила пользователей fpc/lazarus приведёт к оперативному решению подобных проблем.

[Sergei I. Gorelkin]

Проблемы с модулями gtk1 связаны с устареванием самого gtk1 и постепенным исключением его из дистрибутивов. От этого неудобно многим, но это никаким боком не проблемы FPC.

Не нужно делать в объеме, нужном _вообще_ - естественно укопаешься. Достаточно сделать в объеме, нужном самому себе. Кто-то другой сделает что-то еще, и постепенно все придет в соответствие.

[betatester]

Sergei I. Gorelkin

Гм, а зачем исключать GTK1 из дистрибутива? XMMS до сих пор на GTK1 и входит во все мне известные дистрибутивы Linux (за исключением Gentoo)
Вот недавно вышла версия XMMS 1.2.11 На GTK1.

В плане бинарной совместимости и переносимости - GTK1 чуть ли не единственный базовый стандарт по всему миру Linux/x86.

[Sergei I. Gorelkin]

Наверное считают, что GTK2 достиг взрослого состояния, а он по фичам значительно превосходит первый...
В Слаквари 12 уже нет ни GTK1, ни XMMS. На сайте XMMS перечисляется, откуда их уже исключили, там список поболее будет.

[Attid]

а у меня одного якоря перестали в венде работать ?
или они там не работали ? =)
давно вендовую версию не трогал, а тут оппа =/

[alexs]

В смысле Anchors?
вроде работают (сборка сегодняшняя)