XS 模块和 perl 构建之间的结构定义冲突
在 OpenSolaris（$^O eq 'solaris'，第 2.11 节）上，我尝试构建一个使用 XPGv4v2/Single Unix 规范的 XS 模块。了解 struct msghdr，专门用于“辅助数据”询问。
但是，本机 perl (v5.8.4) 是在没有必要定义的情况下构建的，因此我的 XS 文件中可见的 struct msghdr 是较旧的 BSD 类型::
#include "EXTERN.h"
#include "perl.h" /* older, "msg_accrights"-style msghdr now visible */
#include "XSUB.h"
....
struct msghdr m;
m.msg_control = buf; /* ERROR, structure has no member named "msg_control" */
....
提供“正确的”#defines（_XOPEN_SOURCE 和 _XOPEN_SOURCE_EXTENDED）破坏了构建，因为它改变了 perl 期望的很多东西。
有没有一种优雅的方式可以让 XS 模块使用我想要的结构定义？
On OpenSolaris ($^O eq 'solaris', vers. 2.11), I'm trying to build an XS module which uses the XPGv4v2/Single Unix Spec. understanding of struct msghdr, specifically for "ancillary data" interrogation.
However, the native perl (v5.8.4) was built without the requisite defines, and so the struct msghdr visible within my XS file is the older, BSD kind::
#include "EXTERN.h"
#include "perl.h" /* older, "msg_accrights"-style msghdr now visible */
#include "XSUB.h"
....
struct msghdr m;
m.msg_control = buf; /* ERROR, structure has no member named "msg_control" */
....
Supplying the "right" #defines (_XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED) breaks the build, since it changes a great many things that perl was expecting.
Is there an elegant way I can have the XS module use the structure definition I'd like?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您要么必须使用现有 perl 理解的定义，要么使用您想要的定义编译新的 perl。
不过，您不需要替换现有的 perl。您可以单独安装新的 perl，这样它们就不会发生冲突。
如果您想要这两种方式，您必须弄清楚您的 Perl 有哪些定义并编写处理正确的定义集的代码。您可以添加一个抽象层，以便可以使用任一组定义来实现底层位。可能有很多重复的代码，但这就是可移植性，不幸的是。 :(
You either have to use the definitions that your existing perl understands, or compile a new perl with the definitions that you want.
You don't need to replace the existing perl, though. You can install the new perl separately so they don't conflict.
If you want it both ways, you have to figure out which definitions your Perl has and write code that handles the right set of definitions. You might add a layer of abstraction so you can implement the underlying bits with either set of definitions. It's a lot of repeated code probably, but that's what portability is, unfortunately. :(