（前ページへ）
これとは逆に、サブアプリ内にあるシンボルを本体アプリや他のアプリが利用する場合は、図2-3や図2-4 のように定義します。
シンボルの共有はサブアプリ間においても同様の手順で定義できます。
図2-3 サブアプリのシンボルを本体アプリで共有する（テキストファイルを利用）
図2-4 サブアプリのシンボルを本体アプリで共有する（APIを利用）
以上のように、SOLIDではAPIを使ってシンボル共有を定義します。APIで定義されることで、SOLIDではアプリ間のシンボル解決をするための処理をランタイムソフトウエアとして生成し、その実体を本体アプリ内に常駐させます。SOLIDでは、このようなアプリ内に常駐する管理用のランタイムプログラムをコアサービスと名付けています（コアサービスは京都マイクロコンピュータの造語で、ロード以外にMMUの管理などの機能も持っています。詳しくは第三回目でご紹介します）。
コアサービス内にあるインテリジェントローダーは、本体プログラムを実行した際に、あたかもリンカが行っているようなアドレス解決を行いながら、メモリ上に実行モジュールを配置していく機能を持っています。
シンボル共有定義ができた「本体アプリ」「サブアプリ(アプリ1、アプリ2)が各開発拠点でビルドできたところで、それらのアプリケーションを結合して実行するまでの流れを紹介します。
ここでSOLIDが用意したのが、本体アプリがサブアプリをロードするためのAPIです。
ローディングAPI [SOLID_LDR_LoadFile()]：
実行モジュールが存在するファイルパスを指定し、メモリ上にプログラムをロードします。この時点ではアプリ間の共有変数など相互参照しているアドレスは未解決の状態なので、まだアプリの実行は出来ません。
実行可能チェックAPI [SOLID_LDR_CanExec()]：
ローディングAPIでロードすると決めたアプリが実行可能なのか（アドレス解決が矛盾なくできているか）をチェックし、問題無く実行できるならば True を返します。
図2-5. でその手順を説明します。
図2-5 アプリを結合して実行するまでの流れ
① まず、本体アプリをロードします。
② 本単アプリから、アプリ１をロードします。アプリ1はUSBメモリやシリアルフラッシュメモリなど、ファイルシステム上に予めコピーしておきます。
③ プログラムが、実行可能な状態かどうかを確認します。
④ しかし、アプリ２でも相互参照しているシンボルがあるため、この段階ではシンボル解決できておらず、実行できないという結果(False)が返されます。
⑤ 次にアプリ2をロードします。
⑥ 再度、アプリ1、アプリ2が実行可能な状態かどうかを確認します。
⑦ 今度は全てのシンボルの相互参照が確認できたため、シンボル解決が完了したこと(True)が返されます。
⑧ これ以降、本体アプリ、アプリ1、アプリ2は定義された相互参照シンボルを使ってシームレスに実行できるようになります。
（図中 ELF解析、ELF情報 という記載がありますが、こちらについては第三回目で説明します）