そのため、最近のトピック「Lazarus 1.0が光を見つけた！」に関するコメントで、いくつかの誤った記述と未回答の質問がいくつか出されました。 LazarusとFPCの開発者としてかなり長い間、これらの製品に関連するほとんどの質問に答えて、いくつかの誤った仮定を払拭できます。
ステートメント ：実行可能ファイルのサイズが貧弱です。 コンパイラ、リンカなどが原因です。
このトピックに関するいくつかの情報は、 wikiページにあります 。
そのため、実行可能ファイルのサイズの主な要素はデバッグ情報です。 「-g」スイッチが渡されると、デバッグ情報がFPCコンパイラーによって追加されます。 FPCは、2つのタイプのデバッグ情報を生成できます。廃止されたスタブと最新のドワーフ（バージョン2または3）は、コンパイラーに渡されるキーによっても決定されます。 両方のタイプのデバッグ情報は、gdbデバッガーによって理解されます。 Lazarusでは、デバッグ情報を有効/無効にすることができ、プロジェクト設定の[レイアウト]タブでその外観を決定することもできます。
WindowsまたはLinuxでプロジェクトをビルドしている場合、外部デバッグシンボルファイルを作成できます。 この場合、デバッグ情報は実行可能ファイルに追加されず、代わりに外部デバッグファイルへのリンクが配置されます。
デバッグ情報の例外により、空のプロジェクトのサイズがWindowsで20MBから1.6MBに減少します。 ただし、1.6MBは300Kb以上であり、Delphi 7が提供しました（たとえば、Delphi XEは、RTTIの膨張によりすでに多くを提供しています）。 コンパイラーまたはリンカーが問題を正しく処理するかどうかは問題ではありませんが、ポイントはLCLにあります。
LCL-Lazarusコンポーネントライブラリは、2つの部分で構成されます：フロントエンド-アプリケーション開発者（TForm、TButton、TLabelなど）のプラットフォームに依存しないクラスライブラリとバックエンド-特定のプラットフォーム（win32、qt、gtk2）にこれらのコンポーネントを実装する部分。 ..）。 バックエンドの初期実装中に、実行可能ファイルのサイズについて実際に考えたり、すべてのフロントエンドクラスに対処する一般的なメソッドを書いたりする人はいませんでした。
たとえば、lcl \ interfaces \ win32 \ win32proc.ppモジュールの次のコードは、TCustomGroupBox、TCustomTabControlクラスを、どこでも使用しない場合でも実行可能ファイルにプルします。
if (TheWinControl is TCustomGroupBox) then
begin
...
end else
if TheWinControl is TCustomTabControl then
begin
...
end;
リファクタリングはこの問題を解決できますが、かなりの労力と時間を必要とします。手が足りない状況では、おそらく他の問題の解決に費やす方がよいでしょう。 この方向での努力は2〜3年前に行われたものであり、空のプロジェクトのサイズをフォームで300 KB削減することができました。
ステートメント ：LazarusはかつてWindowsにインストールされていましたが、ウィンドウとボタンを備えた最も単純なプログラムでさえ長い間コンパイルされることを覚えていました。
問題は、FPCがWindows用のGNUリンカーを使用したときでした。 しかし、FPC 2.2（およびLazarusはFPC 2.6を使用）では、Windows用の統合リンカーを開発することで問題が修正されました。 さらに、当時、GNUリンカーはWin64プラットフォームでビルドできなかったため、独自の組み込みリンカーの開発も促されました。 LinuxとDarwinの場合、ビルド速度にそのような問題はなかったことに注意してください（その結果、これらのプラットフォーム用の独自のリンカーはまだありません）。
現在、マシン上のフォームを使用して空のプロジェクトを組み立てて開始するのにかかる時間はわずか2秒です。
質問 ：たとえば、Delphi 2006のように、通常のドッキングがLazarusに表示されると便利です。 インターフェイスの利便性が大幅に向上します。 しかし、多分彼はすでにそこにいるのでしょうか？
追加のパッケージをビルドすることでドッキングを有効にできますが、未解決の問題がまだ多数あるため、これはお勧めできません。 バージョン1.2では、ドッキングの準備が整い、ほとんどの場合すぐに環境に組み込まれます。
ステートメント ：「Mac OS X：10.4、LCLは32ビットのみで、非LCLは64ビットにすることができます。」 うん、印象的。
まず、Lazarusはバージョン10.4以上のMac OS X用のプロジェクトを収集することを意味します。 つまり、10.5と10.6および10.7と10.8がサポートされています（Lazarusが現在実行されています）。 LCLプロジェクトは32ビットのみです。
これは、Max OS Xには、カーボンとココアの2つのメインシステムライブラリがあるという事実によるものです。 Carbonが最初に登場し、関数のライブラリでした。 それに基づいてLCLバックエンドの構築を開始しても問題はありませんでした。 Appleが関数の代わりにObjective-Cクラスを含む別のcocoaライブラリを導入した後。 後に、Appleはカーボンライブラリを64ビットにしないと発表しました。一般に、新しいアプリケーションはココア専用に開発されるべきです。
Objective-Cクラスと対話するために、 Objective-Pascalと呼ばれる方言がFPCに追加されました。 ココアのバックエンドもLazarusに追加されましたが、現在開発中です。 可能です（私はこれに努力します）。バージョン1.2では、gtk2とqtの下のバックエンドレベルになります。