freepascal.ru

Несколько лет назад перешёл в стадию стабильных релизов новый линкер mold (https://github.com/rui314/mold). В FPC используется и очень сложным способом (включая отсутствующий пока в mold скриптинг) ld. Но тем не менее обратить на него внимание всё-таки стоит. Он более быстр и похоже позволяет решить задачу по заметному уменьшению размера выполняемого файла. Быть может разработчики FPC добавят что-то для поддержки mold или разработчики mold добавят поддержку fpc (а скорее всего нужно и то и другое), но это могло бы быть выигрышным решением.

Ну и наконец в мире Си и ассемблеров его уже можно успешно применять. Пример этого здесь: http://soft.self-made-free.ru/GORG64_166.tar.xz
Обращает на себя внимание уменьшение размеров выполняемого файла.

ИМХО проще LLCL доработать ...

LLCL

Под Линукс не "доработать", а практически "с нуля":

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

/home/first/src/FPC/LLCL/sources/LLCLOSInt.pas(133,3) Fatal: (10022) Can't find unit Windows used by LLCLOSInt

Но это же виджеты, а то компоновщик, линкер. На размер они тоже влияют, но с другой стороны.

На гитхабе картинка размеров и времени прямо-таки сказочная. Что, как бы, намекает, что это либо сказки, либо даёт неработоспособный код, либо исходники подобраны специально. Да и Сишный код, даже в скомпилированном виде, несколько отличается от паскалевского, так что не факт, что выигрыш будет вообще.

неработоспособный код

Не, не всё так плохо. Код получается работоспособным. Даже выигрыш есть.
Просто не так радужно как в рекламе на гитхабе по части полной замены ld .

Alexander писал(а):Но это же виджеты, а то компоновщик, линкер. На размер они тоже влияют, но с другой стороны.

Это понятно, но стандартный LCL и так иногда "косит лиловым глазом" (например то очищая поля при повторном создании класса то рандомно забывая это делать - лечится это легко но трудно "поставить диагноз" ) а тут еще "таинственный линкер" что-то в "диком ООП" от LCL "за оптимизирует". (Хорошо еще в LCL дженериков нет )

Alex2013 писал(а):(Хорошо еще в LCL дженериков нет )

в смысле, "нет"? А FGL, который активно используется в LCL?

Awkward писал(а):в смысле, "нет"? А FGL, который активно используется в LCL?

Ну это насколько я понял просто поддержка самых дженериков .
А основной код LCL написан очень давно без опоры на дженерики .
(Впрочем я давно не обновлял лазарус - есть несколько долгоиграющих легаси проектов и вообще мне пока и того что есть хватает)

Так-то в FPC есть свой собственный линкер...

Возможно ли это ?

Так-то в FPC есть свой собственный линкер...

Есть. И в него можно добавить подходы успешно применённые в mold, если понять их. И ещё не известно, что проще: добавить запуск mold или добавить его функции во встроенный линкер. Правда встроенный на текущий момент не умеет smartlink и по умолчанию не используется, но может это и даст импульс для его развития.

Smartlink во встроенном линкере есть. Он для этого и был написан.
Строго говоря, написан он был для винды, потому что ld-bfd не умеет в smartlink для объектных файлов формата COFF. Для ELF - умеет, поэтому особо сакрального смысла во внутреннем линкере и нет, кроме как "все свое ношу с собой".

Smartlink во встроенном линкере есть.

Если временно переименовать исполняемый файл системного линкера (*x86_64-linux-gnu-ld.bfd в *x86_64-linux-gnu-ld.bfd_) получим:

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

program sl;

{$MODE OBJFPC}
{$SMARTLINK ON}

begin
WriteLn('*');
end.


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

first@my:~/src/fpc/sl$ fpc -CX -XX -Xi sl.pas
Free Pascal Compiler version 3.3.1 [2024/03/07] for x86_64
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling sl.pas
Linking sl
sl.pas(8,1) Error: Util ld not found, switching to external linking
sl.pas(8,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /usr/bin/ppcx64 returned an error exitcode

То есть он его всё равно задействует и без него не может. Даже при явном указании -Xi .