首先,这不是链接器问题:您有"undefined symbol"
而不是"unresolved symbol"
错误。
这简直是个#include
问题。
在您的 script.cpp 文件中定义 main() 函数。
有一个 G-WAN 文件夹专门用于调用用户定义的包含文件,/gwan/include
但您也可以使用 /csp/my_include.hpp... 如果您使用正确的语法:
例如,#include "toto.hpp"
在 /csp/hello.cpp 中,我可以访问在文件中定义和实现gwan/include/toto.hpp
的 C++ 函数(或在 toto.hpp 中定义并在使用#pragma 链接链接到您的脚本的预编译库中实现)。
如果您更愿意使用#include <toto.hpp>
,则将搜索 SYSTEM INCLUDE PATH(如果您的库已正确安装,这将起作用)。
如果您想#include "toto.hpp"
用于系统中未设置的自定义文件夹,您可以使用 G-WAN 的#pragma include "../my_folder"
指令来指定其 PATH 或者您可以在每个 include: 中明确指定它#include "../my_folder/toto.hpp"
。
没什么特别的,只有 C/C++ 依赖规则适用(并且 G-WAN 通过提供不涉及系统设置的替代方式确实有帮助)。
对于库(请参阅 SQLite、Cairo、mySQL、cURL 等的 G-WAN 示例),您可以使用在 SYSTEM 变量中导出其位置的预安装库...或者将您的库放在/gwan/libraries
文件夹及其包含文件中在/gwan/include
文件夹中。
编写自己的库时,请记住它们需要预编译。这意味着您显然不能使用 G-WAN 符号,因为您的编译器可能 #include "gwan.h" (具有定义)但您的链接器将不知道从哪里可以找到 G-WAN 符号。解决方法是始终使用 G-WAN 脚本中的 G-WAN API。您的自定义库必须是通用的或缓冲打算由 G-WAN 使用的任何有效负载。set_reply()
由于 G-WAN 提供调用以让 G-WAN 使用在没有G-WAN servlet 提供的情况下构建的持久回复,因此不需要双重复制。reply xbuffer
现在,最后一句话linking
(这不是造成您麻烦的原因,但可能会引起混乱)。如果您混合使用 C 和 C++,请使用extern C {}
包装从 C 调用的 C++ 原型(否则您将真正拥有"unresolved symbols"
)。
有了所有这些信息,您应该准备好面对每一种可能的情况。