Здравствуйте, rudzuk, Вы писали:

R>Блин, вот кхимик тоже говорит, что у него ничего необычного в коде нет, он просто падает (только у него Delphi). Но так же не бывает, мужчины. Если есть падение, значит есть причина. Выяснять нужно в чем дело. И в первую очередь избавиться от кода собранного добрыми людьми.


1. Если бы падал собранный exe — я бы нашел причину. Но до бинарника даже не доходит. Компилятор падает с ошибками, которые можно найти на форуме FPC (но решение не нашли) и в трекере FPC от 2018 года. Там долго обсуждали, но пришли к выводу, что у разработчиков FPC такая же нога и не болит.

2. А как можно огромный проект без внешних либ написать? Я сейчас не про ДевЭкспресс и прочие, а про, например, работу с Excel без COM? Люди годами это пишут.

Здравствуйте, sfsoft, Вы писали:

S>1. Если бы падал собранный exe — я бы нашел причину. Но до бинарника даже не доходит. Компилятор падает с ошибками, которые можно найти на форуме FPC (но решение не нашли) и в трекере FPC от 2018 года. Там долго обсуждали, но пришли к выводу, что у разработчиков FPC такая же нога и не болит.

Есть универсальный принцип отладки всех подобных проблем. Выдираем куски кода в новый тестовый проект, минимально простой и повторяем ошибку. Упрощаем до максимума — либо находим свою ошибку, либо, что очень редко — ошибку в FPC. В этом случае просто публикуем тестовый проект на форуме Лазаруса и ждем помощи сообщества (ответят быстро).

S>Я знаю, что некоторые здесь используют Лазаря в разработке (тот же Чёрный Властелин). Расскажите, как у вас это получается? Уже месяц потрачен на эту поделку, там вообще нифига не работает. Какие-то рандомные ошибки постоянно валятся, FPC через раз компилирует проект. Может просто перестать это делать с сообщениями типа "Error: Undefined symbol: .Lj3850". Причем решение проблем вообще не гуглится...

S>Может я что-то делаю не так? Подскажите, пожалуйста, знающие люди.

S>P.S. Проект написан на Delphi, ему около 20 лет. Используются почти все современные фичи Delphi (дженерики, атрибуты, расширенный RTTI и прочее). Понятно, что от чего-то придётся отказаться, но не от всего же! )))

Собрал сложный, многопоточный продукт под Ubuntu 22.
1. Версия trunk FPC/Lazarus через fpcdeluxe.
2. Для меня была основная проблема, что PostMessage и SendMessage в потоках работают не так, как в Windows.
3. Частые проблемы при статической компиляции внешних библиотек (теперь использую только shared libraries).
4. Дженерики использую крайне ограниченно.
5. Иногда при быстрой компиляции вылезает ошибка, полный билд ее решает.
6. В виртуальной машине и при кросс-компиляции были боль и страдания. Настроил отдельный комп (без монитора, доступ через RDP) для разработки по Linux. Все стало приемлемо и работать достаточно комфортно.

Здравствуйте, PeterOne, Вы писали:

PO>Здравствуйте, sfsoft, Вы писали:

S>>1. Если бы падал собранный exe — я бы нашел причину. Но до бинарника даже не доходит. Компилятор падает с ошибками, которые можно найти на форуме FPC (но решение не нашли) и в трекере FPC от 2018 года. Там долго обсуждали, но пришли к выводу, что у разработчиков FPC такая же нога и не болит.

PO>Есть универсальный принцип отладки всех подобных проблем. Выдираем куски кода в новый тестовый проект, минимально простой и повторяем ошибку. Упрощаем до максимума — либо находим свою ошибку, либо, что очень редко — ошибку в FPC. В этом случае просто публикуем тестовый проект на форуме Лазаруса и ждем помощи сообщества (ответят быстро).

У FPC есть особенность, при которой этот способ не работает. Механизм загрузки юнитов (который подразумевает, что при изменении в одном из них должны перекомпилироваться все от него зависимые) реализован так, что иногда при достижении некоторой критической массы проекта он дает сбой, и компилятор падает с малопонятными внутренними ошибками.
У многих, сообщающих о таких ошибках, проекты с закрытыми исходниками, из-за чего сообщество помочь не может. С другой стороны, сам FPC и Lazarus — очень немаленькие проекты, которые постоянно изменяются и собираются, и в них такого не происходит.

Здравствуйте, Черный 😈 Властелин, Вы писали:

ЧВ>1) Качаем fpcupdeluxe-i386-win32.exe, именно 32-битную версию, тк есть какие-то заморочки кросс-сборкой с 64-бит версией связаные с softfloat.
ЧВ>2) Ставим FPC FIXES 3.2 и LAZARUS TRUNK (скоро выйдет LAZARUS 3.0 и появится FIXES 3.0)

Спасибо огромное, этот совет помог.
Есть ещё ошибки из-за которых FPC падает с internal error (например в Generics.Collections у TList<T> метод Delete сделали inline), но их можно обойти.

Здравствуйте, Sergei I. Gorelkin, Вы писали:

SIG>У многих, сообщающих о таких ошибках, проекты с закрытыми исходниками, из-за чего сообщество помочь не может.

Именно.

SIG>С другой стороны, сам FPC и Lazarus — очень немаленькие проекты, которые постоянно изменяются и собираются, и в них такого не происходит.

Это везде так. Человек, знающий о проблемах, подсознательно будет из избегать, сам того не осознавая. Поэтому у него всё и всегда будет работать.

Здравствуйте, sfsoft, Вы писали:

s> 1. Если бы падал собранный exe — я бы нашел причину. Но до бинарника даже не доходит. Компилятор падает с ошибками, которые можно найти на форуме FPC (но решение не нашли) и в трекере FPC от 2018 года. Там долго обсуждали, но пришли к выводу, что у разработчиков FPC такая же нога и не болит.

Значит, нужно выкидывать из проекта все, что можно, пока тот не начнет собираться. У меня так было с Delphi, когда тесты проекта на новой версии перестли собираться с внутренней ошибкой компилятора. Сперва нашел модуль из-за которого компилятор падал, потом процедуру, а потом и строку. Комментируя и пересобирая код. Долго и нудно, но других вариантов нет.

s> 2. А как можно огромный проект без внешних либ написать? Я сейчас не про ДевЭкспресс и прочие, а про, например, работу с Excel без COM? Люди годами это пишут.

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

Еще вопрос возник:

При компиляции выдаются warnings и hints от исходников LCL и FCL. Как их убрать, чтобы только свои предупреждения видеть?

Здравствуйте, sfsoft, Вы писали:
S>При компиляции выдаются warnings и hints от исходников LCL и FCL. Как их убрать, чтобы только свои предупреждения видеть?

Вроде ж только при первой сборке, а потом только от дженериков.

Я так понял, в случае с дженериками "specialized" код дублируется в проекте и постоянно лезут ворнинги.

Чтобы это побороть, приходится вставлять {$WARNINGS OFF} в объявления типов использующих Generics.Collections.

Здравствуйте, sfsoft, Вы писали:

s> При компиляции выдаются warnings и hints от исходников LCL и FCL. Как их убрать, чтобы только свои предупреждения видеть?

Уже ответили, но есть еще вариант: отключить все сообщения на уровне проекта, но в своих модулях делать включение {$I project_directives.inc} в котором все включать.

Коллеги, а как использовать, например, FPC 3.3.1? Требуется для TCustomAttribute.
Он собирается в fpcdeluxe, но Лазарь к нему никакой не подходит. Версия LCL не совпадает с изменениями в FCL. Снова что-то упускаю?

Здравствуйте, sfsoft, Вы писали:

s> Коллеги, а как использовать, например, FPC 3.3.1? Требуется для TCustomAttribute.
s> Он собирается в fpcdeluxe, но Лазарь к нему никакой не подходит. Версия LCL не совпадает с изменениями в FCL. Снова что-то упускаю?

Нечетные версии это девелоперские версии. Ставь trunk. Но с дев.версиями бывают неприкольные приколы. Я сам на девелоперских сижу, но аккратно

До кросс-компиляции пока дело не дошло. Но под Win32/64 часть приложения уже собирается и работает. Секса много, Delphi сильно ускакал вперёд в плане системных библиотек. Ну и отладка, конечно, полный п..ц.
Но работает!

S>Но работает!

Всё-таки эта фигня совершенно нерабочая. Как только размер проекта начал расти — начали появляться непонятные ошибки компилятора.
Например, есть вот такая функция:

function ExecuteOpenDialogForm(Report: TRDReport; var Id: Integer): Boolean;

Из-за этого не компилируется весь модуль.



Кода в функции никакого нет, он закомментирован для исключения ошибок.
Если сделать вот так:

function ExecuteOpenDialogForm(Report: TObject; var Id: Integer): Boolean;

, то проблема с этим юнитом пропадает. Но мне не нужно TObject передавать...

Здравствуйте, sfsoft, Вы писали:

S>>Но работает!

S>Всё-таки эта фигня совершенно нерабочая. Как только размер проекта начал расти — начали появляться непонятные ошибки компилятора.
S>Например, есть вот такая функция:

Скорее всего это наведенная ошибка.

Что за класс TRDReport ? Его юнит взят из Delphi или юнит адаптирован для FPC/Lazarus?

Возможно в юните класса TRDReport есть недопустимые unicode символы.

Сделайте тестовый проект, подключите этот юнит и перенесите функцию как Вы процитировали выше. Будет ли компилироваться?

повторю — у меня гигантский проект на FPC/Lazarus — все компилируется и работает и на Windows и на Mac.

Здравствуйте, PeterOne, Вы писали:

PO>Что за класс TRDReport ? Его юнит взят из Delphi или юнит адаптирован для FPC/Lazarus?

Это класс из библиотеки. Первоначально написанный ещё для Delphi 5. С тех пор всё, что с ним происходило, это миграция на Unicode в D2009.

PO>Возможно в юните класса TRDReport есть недопустимые unicode символы.

Файлы исходников в UTF8 переведены. Но, допустим, там есть какие-то недопустимые unicode символы. Почему ошибка указывает на lpr-файл?
И ещё подбешивает, что часто FPC падает с ошибками типа Debug: EAccessViolation: Access violation. Делаешь полный build — ошибка пропадает. Но, блин, это и занимает в разы больше времени...

PO>Сделайте тестовый проект, подключите этот юнит и перенесите функцию как Вы процитировали выше. Будет ли компилироваться?

Этот юнит не сам по себе. Там куча зависимостей.

PO>повторю — у меня гигантский проект на FPC/Lazarus — все компилируется и работает и на Windows и на Mac.

Видимо разные проекты. У меня 1324 юнита, и 26 Мб исходников. Это считается большим проектом?

Здравствуйте, sfsoft, Вы писали:

S>Это класс из библиотеки. Первоначально написанный ещё для Delphi 5. С тех пор всё, что с ним происходило, это миграция на Unicode в D2009.

Если библиотека изначально была написана на Delphi, ее придется адаптировать к FPC. Самый очевидный момент — в каждом модуле придется указать mode delphi, чтобы сохранить максимально синтаксис модуля в Delphi стиле.

Судя по скрину, вы компилируете 32-bit. Это правильно, если раньше в Delphi компиляция была в 32-bit. Переход на 64-bit отдельная задача — лучше сделать отдельно, когда все будет компилироваться. У меня кстати уже сделан шаг с адаптацией кода под 64-bit.

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

Поищите в Вики Lazarus'а — там вроде было руководство по переходу с Delphi и советы по адаптации кода.

Если вы не пользовались самыми новыми фишками языка Delphi, а ограничивались возможностями условно Delphi 7 (нулевых годов), то перенос кода на FPC в режиме mode delphi не должен вызывать никаких проблем.

PO>>повторю — у меня гигантский проект на FPC/Lazarus — все компилируется и работает и на Windows и на Mac.

S>Видимо разные проекты. У меня 1324 юнита, и 26 Мб исходников. Это считается большим проектом?

У меня 1100 юнитов 18 МБ PAS исходников (не считая FPC/Lazarus).

Отладчик в Lazarus соглашусь — хуже чем в Delphi.

Здравствуйте, PeterOne, Вы писали:

PO>Если библиотека изначально была написана на Delphi, ее придется адаптировать к FPC. Самый очевидный момент — в каждом модуле придется указать mode delphi, чтобы сохранить максимально синтаксис модуля в Delphi стиле.

Это в первую очередь было сделано. Тем более в Лазаре есть специальный тул для этого. Который, кстати, в транке 3.99 поломан: dfm не конвертятся.

PO>Судя по скрину, вы компилируете 32-bit. Это правильно, если раньше в Delphi компиляция была в 32-bit. Переход на 64-bit отдельная задача — лучше сделать отдельно, когда все будет компилироваться. У меня кстати уже сделан шаг с адаптацией кода под 64-bit.

Софт для Win64 давно уже адаптирован и работает. Под Delphi, конечно же.

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

PO>Поищите в Вики Lazarus'а — там вроде было руководство по переходу с Delphi и советы по адаптации кода.

Все уже прочитано и изучено. Вероятнее всего FPC просто не готов к современной разработке. Я в IT c 1996 года. Профессионально с 2000. Гуглить и решать проблемы обучен ))) Но писать компиляторы — не моя сфера интересов.

PO>Если вы не пользовались самыми новыми фишками языка Delphi, а ограничивались возможностями условно Delphi 7 (нулевых годов), то перенос кода на FPC в режиме mode delphi не должен вызывать никаких проблем.

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

PO>Отладчик в Lazarus соглашусь — хуже чем в Delphi.
Это сильное преуменьшение качества отладчика

Не могу больше помочь, извините. Видимо Вам придется решить — оставаться на Delphi (может это и неплохой вариант), или неспеша пробовать адаптировать код под FPC/Lazarus.

А что Delphi сейчас не умеет компилировать VCL приложение для Linux?

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

PO>Не могу больше помочь, извините. Видимо Вам придется решить — оставаться на Delphi (может это и неплохой вариант), или неспеша пробовать адаптировать код под FPC/Lazarus.

Спасибо за помощь. Комьюнити, видимо, таки работает. Две недели назад trunc FPC и trunc Lazarus совместно не работали. LCL не подходила к FCL. Что-то сломали. Я в тот момент плюнул на это, а пару дней назад увидел тему об этом на форуме. Вчера вечером скачал оба trunk'а — и всё завелось. Пропали и те ошибки несовместимости. И мои, кстати, тоже пропали. Постараюсь не дышать на FPC, чтобы ничего не сломать

PO>А что Delphi сейчас не умеет компилировать VCL приложение для Linux?

Нет. Есть проект VCL для Linux от Крюкова, но он заброшен, насколько можно судить по его баг-трекеру. Ещё есть FMXLinux. Но это FMX. Я его как-то не очень, хотя надо отдать должное, за 10 лет он сильно изменился. Плюс на FMX нужно весь GUI переписывать с нуля, конвертер умер (был такой, Mida). Ну и самое главное, из-за курса доллара и отмены Путиным постановления о двойном налогообложении все поставщики западного ПО подняли цены на 20-25% единомоментно. И сейчас Delphi для Linux стоит 488000 т.р. Что как-то овердофига.