【问题标题】:lua ffi functions sharing namespacelua ffi 函数共享命名空间
【发布时间】:2015-12-06 01:14:23
【问题描述】:

我可以在 Linux 中使用 LuaJit 为两个不同的库共享相同的“命名空间”

A = ffi.load(ffi.os == "Windows" and "opengl32" or "GLESv2")
B = ffi.load(ffi.os == "Windows" and "glfw3" or "glfw")
C = B,A

这样做允许我从 C 变量调用任一库中的函数

但是在最后一个库 A 中的 windows 函数中找不到(我正在使用来自 https://luapower.com/ 的 LuaJit 二进制文件)

我猜两个平台的行为应该相同(如果不能在两个平台上完成(这很奇怪),那么两个平台都不应该允许它?)

这是一个错误还是有更强大的方法来做我正在尝试的事情?

【问题讨论】:

  • 我认为 Linux 上的 glfw 必须为我动态链接函数(来自 GLES)。 C = B --,A 也有效,即我认为 C 只包含第一个库中的函数....(所以我想做的事情在这两个平台上都不起作用!)
  • 在 linux 中设法使用了 ffi.C 甚至 C=ffi.C(在使用 global=true 加载后),但 windows 似乎也不喜欢......?
  • C = B, A 没有意义……或者至少它将B 分配给C 并丢弃A

标签: c lua ffi luajit


【解决方案1】:

如果我正确阅读了the documentation,那么您通常无法通过同一命名空间访问所有库。

在 POSIX(Linux、BSD 等)系统上,您可以调用 ffi.load( name, true ) 以使符号在 ffi.C 中可用。没有提到这在 Windows 上工作或不工作,所以我认为这不会在那里工作。

这意味着这不是一个错误,您正在寻找的更强大的方法是通过它们各自的库名称空间访问来自不同库的符号。 (对于您的示例,这意味着通过A 访问opengl 函数和通过B 访问glfw 函数。)


我猜两个平台的行为应该相同(如果不能在两个平台上完成(这很奇怪)那么两个平台都不应该允许它?)

有很多东西可以在 Windows/Linux/Mac OS/BSD/... 上以某种方式完成,但在部分或全部上的工作方式完全不同。动态链接只是其中之一。还有更多,包括简单的东西,比如包含文件的“目录”的概念——这个概念存在于所有这些平台上,但没有通用的 API,并且低级包装器(如 LuaJIT 的 FFI 用于动态链接)可能会暴露一些差异。

【讨论】:

    猜你喜欢
    • 2013-03-12
    • 2018-02-28
    • 2018-11-30
    • 1970-01-01
    • 2021-11-21
    • 1970-01-01
    • 1970-01-01
    • 2013-05-20
    • 1970-01-01
    相关资源
    最近更新 更多