まず、これはリンカーの問題ではありません。エラーとしてでは"undefined symbol"なく、問題"unresolved symbol"があります。
これは単に#include問題です。
script.cppファイルでmain（）関数を定義します。
と呼ばれるユーザー定義のインクルードファイル専用のG-WANフォルダー/gwan/includeがありますが、正しい構文を使用している場合は、/ csp /my_include.hpp...を使用することもできます。
たとえば、 / csp / hello.cppにあると、ファイルで定義および実装された（または、toto.hppで定義され、＃pragmaリンクを使用してスクリプトにリンクされたコンパイル済みライブラリに実装された#include "toto.hpp"） C++関数にアクセスできます。gwan/include/toto.hpp
使用する場合は#include <toto.hpp>、代わりにSYSTEM INCLUDE PATHが検索されます（ライブラリが正しくインストールされていれば、これは機能します）。
#include "toto.hpp"システムに設定されていないカスタムフォルダに使用する場合は、G-WANの#pragma include "../my_folder"ディレクティブを使用してそのPATHを指定するか、各インクルードで明示的に指定することができます#include "../my_folder/toto.hpp"。
そこには特別なことは何もありません。C/C++の依存関係ルールのみが適用されます（G-WANは、システム設定を伴わない代替方法を提供することで実際に役立ちます）。
ライブラリ（SQLite、Cairo、mySQL、cURLなどのG-WANの例を参照）の場合は、SYSTEM変数に場所をエクスポートしたプレインストールライブラリを使用するか、ライブラリを/gwan/librariesフォルダとインクルードファイルに配置します。/gwan/includeフォルダ内。
独自のライブラリを作成するときは、事前にコンパイルする必要があることに注意してください。これは、コンパイラが「gwan.h」（定義を持つため）を#includeする可能性があるため、明らかにG-WANシンボルを使用できないことを意味しますが、リンカはG-WANシンボルがどこにあるかを認識しません。回避策は、常にG-WANスクリプトからG-WANAPIを使用することです。カスタムライブラリは、汎用であるか、G-WANで使用することを目的としたペイロードをバッファリングする必要があります。G-WANは、 G-WANサーブレットによって提供されることなく構築された永続的な応答set_reply()をG-WANに使用させるための呼び出しを提供するため、二重コピーは必要ありません。reply xbuffer
さて、最後の言葉linking（これはあなたのトラブルの原因ではありませんでしたが、混乱に参加する可能性があります）。CとC++を混在させる場合は、extern C {}Cから呼び出されるC ++プロトタイプをラップするために使用します（そうでない場合は、実際に使用されます"unresolved symbols"）。
これらすべての情報があれば、考えられるすべての状況に直面する準備ができているはずです。