Lazarus жив вообще ?

[Sergei I. Gorelkin]

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

Ни фига он не стандартный. Под каждую пишется configure.in, потом "компилируется" с помощью automake. В процессе участвуют не только настройки конкретной системы, но и настройки компилятора, которым все будут собирать. Если собрать в кучу все средства, которыми это достигается (отдельный компилятор языка M4 и прочее), волосы дыбом встают. Для приведения в соответствие 100 кБайт исходников нужен скрипт на 500 КБайт (!!!). Правда, и для 50мБайт исходников остаются те же 500КБ.

Паскаль как таковой представляет из себя попытку куда-то от этого деться. Кстати, вполне успешную попытку Сама идеология Паскаля предполагает то, что все зависимости перечисляются в исходниках, а исходники от других модулей в общем случае не требуются (достаточно .ppu). Поэтому и автоматическое изменение исходников не предусматривается.
Переносить сюда Сишный механизм конфигурации - по крайней мере неразумно.

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

В смысле кроссплатформенности _должно_ быть одинаково. То есть libc должна быть так же стабильна, как и ядро. Но на практике это, увы, не так.
Собственно, если мы вызываем syscall, которого в ядре нет, ничего фатального не происходит. А если мы связываемся с несуществующей ф-цией из библиотеки, то программа не запустится вообще.

p.s: дискуссия ушла в далекий офтоп...

[betatester]

Давайте отделим мух от котлет!

1)Механизм .configue есть и он РАБОТАЕТ! Пишу Вам, как пользователь Gentoo Linux, в которой все собирается из исходников. И везде (в 98 случаях из 100) используется скрипт .configure. А уж сколько килобайт там надо для его выполнения - не важно.

2)Про нестабильность libc - пожалуйста, по подробнее. Это POSIX стандарт. Который используется ВСЕМИ программами. Мне трудно найти код, который libc НЕ ИСПОЛЬЗУЕТ!

3)Вы не сможете ЧИСТО ФИЗИЧЕСКИ "связываемся с несуществующей ф-цией из библиотеки" - Вам линковщик такую программу просто не слинкует! Это возможно только при использовании libdl и функций run-time загрузки библиотек типа dlopen/dlsym.

[Sergei I. Gorelkin]

1)Механизм .configue есть и он РАБОТАЕТ! Пишу Вам, как пользователь Gentoo Linux, в которой все собирается из исходников. И везде (в 98 случаях из 100) используется скрипт .configure. А уж сколько килобайт там надо для его выполнения - не важно.

Я и не спорю, что он есть и работает. Я утверждаю, что принцип работы fpc отличается от gcc настолько, что применение .configure для программ на fpc лишено смысла.

2)Про нестабильность libc - пожалуйста, по подробнее. Это POSIX стандарт. Который используется ВСЕМИ программами. Мне трудно найти код, который libc НЕ ИСПОЛЬЗУЕТ!

libc - не только posix библиотека, но еще и рантайм от gcc. Который как раз ни разу не стандарт. Сильно сомневаюсь, что, взяв libc от gcc 4, удастся хоть что-то собрать с помощью gcc 3. Равно как взяв libc от Gentoo, хоть что-то собрать на какой-нибудь Slackware.
Мне сложно говорить о конкретных фактах, т.к. я не участвовал в разработке RTL. Но исходники с {$ifdef fpc_use_libc} говорят о том, что проблемы были.

3)Вы не сможете ЧИСТО ФИЗИЧЕСКИ "связываемся с несуществующей ф-цией из библиотеки" - Вам линковщик такую программу просто не слинкует! Это возможно только при использовании libdl и функций run-time загрузки библиотек типа dlopen/dlsym.

В Си - не смогу. В Паскале - сколько угодно:

Код: Выделить всё

procedure foo; external "xxx.dll" name "yyy";


...по крайней мере в винде. Что происходит в Линуксе - почему половина ф-ций определена, как я написал выше, а вторая половина подключается с помощью {$LINKLIB FOO} - честно говоря, сам не до конца понимаю.

[Максим]

betatester
Вы, очевидно, не понимаете разницу между стандартом и его реализацией.

Про нестабильность libc - пожалуйста, по подробнее. Это POSIX стандарт.

И не путайте, пожалуйста, божий дар с яичницей - GNU LIBC - это РЕАЛИЗАЦИЯ стандартной библиотеки LIBC, а не отдельная по сути библиотека. Я, собственно, говорил про LIBC в целом.

Нет в природе такой вещи, как "LIBC в целом". Есть реализация на Linux в виде Glibc, есть реализации на других ОС, есть dietlibc, uclibc и пр. В них неизбежно будут отклонения от стандартов, да и ошибки, в конце концов.

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

Тут "долго смеялсо" я.

[betatester]

Господа. Кажется назрело непонимание.

ИМХО вы пишите то, что как минимум не проверили.

1)

Код: Выделить всё

procedure foo; external "xxx.dll" name "yyy";

- не есть пример вызова несуществующей функции из библиотеки - вы в ответ получите сообщение линковщика

Код: Выделить всё

zzzzz.pas:(.text+0xac): undefined reference to `yyy'

- по крайней мере, в Linux.

Пример того, как это бывает на практике, приведен мною в топике Функции gdk_pixbuf в среде GTK1 в FPC

А вот несуществующий syscall вызвать достаточно легко.

2)Я искренне не понимаю, почему бы не сделать следующие шаги:
- при установке FPC выполняется скрипт "настраивающий" необходимые файл заголовков
- файлы заголовков преобразуются в Unit'ы - интерфейсы к соотв. библиотекам.
Не вижу тут ничего революционного и не реализуемого. Утилита H2PAS имеется.

Однако, вместо этого я должен пользоваться Unit'ом, в README к которому написано:

Код: Выделить всё

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

Мое текущее ядро - 2.6.22, версия libc - 2.6.1. Разумеется, при использовании ТАКОГО Unit'а могут возникнуть проблемы.

3)Говоря о libc я имел в виду переносимость кода, а не бинарную совместимость.

И опять же - Вы хоть сами смотрели, о чем идет разговор? Т.е. какие конкретно функции можно вызывать из этой самой злосчастной libc и какие там могут быть "нестабильности", "несовместимости" и пр. проблемы?

Докладываю - я имел в виду базовые системные функции класса open/read/write/close - т.е. файловый IO, функции работы с памятью и со строкам и так далее.
Можно услышать что-то более конкретное, чем туманные ссылки на "критику Линуса Торвальдса" и "проблемы были"?

Несерьезный разговор получается...

Да, и причем тут Windows?

[Vadim]

betatester
1.

Код:
procedure foo; external "xxx.dll" name "yyy";
- не есть пример вызова несуществующей функции из библиотеки - вы в ответ получите сообщение линковщика
Код:
zzzzz.pas:(.text+0xac): undefined reference to `yyy'
- по крайней мере, в Linux.

В Windows не так...
Компилятор со спокойной душой откомпилирует исходник и только при вызове объявленой таким образом процедуры появится сообщение об ошибке, что "точка входа в процедуру YYY не найдена в xxx.dll".
Мало того, даже если не существует самой библиотеки, компиляция тоже пройдёт на ура.
2. В принципе, подобный скрипт написать легко, только убивает сразу же такая штука. Честно скажу, не знаю как в Линуксе, в Windows при компиляции DLL компилятор коверкает имена функций. Принцип коверкания зависит от того, какого типа аргументы у функции, член ли это класса, возвращаемый тип и т.п. При этом у MS Visual С++ свои принципы коверкания, а у Borland С++ - свои. Так что только в винде мы получаем две таблицы соответствий для составления заголовочных файлов. Для других ОС будет еще...

[betatester]

Vadim

Скажите, ну причем тут Windows?

Я веду речь о Unix и о Linux в частности. В Linux есть все необходимые *.h файлы (обычно в /usr/include), которые можно конвертировать в PAS Unit'ы описанным выше механизмом.

[Vadim]

betatester
А при том. Даже если мы не будем вслух произносить это гадкое слово, проблема совместимости никуда не денется... В том, что совершенно не при чём, *.h файлов отчего-то куда меньше. чем в /usr/include

[betatester]

Vadim

Какая "проблема совместимости"? Чего с чем?

Сейчас обсуждается, собственно, некие файлы, находящиеся в /usr/share/fpcsrc/rtl/linux и /usr/share/fpcsrc/packages/base/libc

[Sergei I. Gorelkin]

Непонимание таки да, назрело.

Из-за чего вообще весь сыр-бор?
FPC и его программы работают на заявленных платформах? Работают.
Функции из libc вызывать можно? Mожно.
Собрать RTL так, чтобы вместо syscall использовались ф-ции из libc? Mожно, достаточно определить символ FPC_USE_LIBC.

Модуль libc устарел? Так обновите его, никто ж возражать не будет.

[betatester]

Sergei I. Gorelkin - Спасибо, я все понял.

Дискуссия пошла весьма интересным путем - я про Линукс, мне про Виндовс, я про libc - мне опять про Виндовс. Народ бросается словами "несовместимость" и "глючность", а в доказательство приводит какие-то смутные "видимо проблемы были".
Я, когда чувствую, что не в теме - стараюсь попусту не писать.

[Vadim]

betatester
Ну это как обычно. Кто про что, а голый - про баню...
У каждого ведь своё видение.
Если Вы работаете исключительно в Linux, то слово "совместимость" для Вас, естественно, пустой звук.

[betatester]

Vadim

Сделайте одолжение - поищите, пожалуйста, в директории C:\Windows файл (g)libc.dll. Если найдете - напишите, пожалуйста, сюда результат.

[Vadim]

betatester
"Хихикайте, если больше ничего не умеете".
http://gnuwin32.sourceforge.net/packages/libc.htm.bak
По-моему это именно Вы настаиваете на обязательном применении (g)libc. Почему я то за Вас искать её должен?

[betatester]

Упаси меня Бог настаивать на обязательном применении (g)libc!
Тем более, на платформе Windows! Я, кажется, и словом нигде об этом не обмолвился!

Речь шла о стандартизации системных вызовов в Unix/Linux - а их на этих платформах можно вызывать системными вызовами из ядра (механизм syscall) или через интерфейсные библиотеки, ОДНОЙ ИЗ КОТОРЫЙ является (g)libc - НЕ БОЛЕЕ ТОГО! Интерфейс к libc есть еще как минимум в двух операционных системах - OS/2 и Novell Netware.

Кроме того - использование libc может и должно привести к сокращению размера итогового кода программы.

Такие вот дела.