我正在编写一个脚本来运行各种远程测试，我需要获得的值之一来自一个目前有 38 个成员的大型结构。IDL 将该结构作为函数的“inout”参数来获取此数据：

问题是有时会添加或删除成员，我不想仅仅因为有人决定将一条新数据填充到结构中而必须更新我的脚本。有没有办法创建这个结构类的实例而不必填写 38 个成员中的每一个？我只需要传递一些不会触发omniORB.BAD_PARAM_WrongPythonType 的函数。

该结构有各种不同的类型，所以我不能只做这样的事情：

它看起来更像这样：

我希望能够在不静态定义 initArgs 的情况下做到这一点：

语境

我需要在 Windows 10 上安装omniORB 和omniORBpy 以使用Python 3.7 作为服务器骨架和Java Stub 作为客户端。

我已经在 Ubuntu LTS 18.04 中安装了omniORB 和omniORBpy，并且制作了一个小型系统。它工作得很好，但它只与 Python 2.7 兼容，我需要它是 Python 3.7。

这就是我所做的系统的样子（它是西班牙语，对此感到抱歉）

我试过的

首先，我尝试将 omniORBpy 文件（omniORB、CORBA.py 等）从我的 Python 2.7 Ubuntu venv 复制到我在 Windows 中的 Python 2.7 的 venv。只是想试试。

PyCharm 识别 venv 库，但是当我运行脚本时，它说我找不到文件“_omnipy”（我猜它仍然没有告诉我其他文件）。我意识到这个库使用了 * .so 文件（显然）并且我需要它，也许它是一种与 Windows 一起工作的 * .dll。

这是我的 Python 2.7 venv（站点包）

这是我在 PyCharm 上遇到的错误

另一方面，我仍然找不到如何安装omniORB 以使用omniNames 服务并拥有IOR（在Windows 上）并使用omniidl 来“编译”我的idl 文件。

我需要类似的东西

在 Windows cmd 上（不在 Windows 上安装的 Linux 子系统上）。

omn​​iORB 4 使用 Autoconf 配置脚本来支持构建系统的配置。--host许多配置脚本支持使用和--build标志进行交叉编译。不幸的是，omniORB 在他们的文件中明确声明README.unix不支持交叉编译。

Autoconf 构建当前不适用于交叉编译。

当您尝试使用--host和--buildAutoconf 标志时，会发生以下情况：

环境：

• PATH设置为包括交叉编译工具
• CPPFLAGS设置为包含 ARM sysroot/include 文件夹-I.../sysroot/include
• LDFLAGS设置为包括 ARM sysroot/lib 文件夹-L.../sysroot/lib

注意：我使用三个点 (...) 来省略部分文件路径或不重要的输出。

我相信会有重要的信息wrong ELF class: ELFCLASS32。我用file.

所以看起来构建系统构建了这个共享对象模块，供omniidl在omniORB构建期间使用。问题是它是为 ARM 构建的，不能在主机系统上使用。

鉴于缺乏构建系统的支持，我如何交叉编译omniORB？

我正在浏览 REDHAWK SDR 框架的源代码，并希望对其进行升级以支持 SCA 4.1 规范。它已经部分符合 SCA 2.2.2 版本。

我有 SCA 4.1 接口的 IDL 描述，并使用带有 C++ 映射的omniORB IDL 编译器编译它们。骨架和存根代码已正确生成。现在我想了解如何执行以下操作：

1. 这些生成的骨架和存根代码在 REDHAWK 源代码中的位置。

2. 基于这些骨架和存根代码的服务器和客户端代码在redhawk源代码中的放置位置

3. 我还想升级到 SCA 4.1 中指定的日志记录，可从链接https://www.omg.org/spec/LtLOG/1.1/PDF获得。在这里，我再次生成了骨架和存根代码，但不知道如何进一步进行。

4. 我错过了什么（或很多）。

任何指示都会有所帮助。请询问我未包含的任何信息，因为我也处于学习阶段。

我正在尝试在运行 Windows 10 pro 64bit 的虚拟机上测试 OmbiORB V4.2.3。我已经安装了所有必要的软件（python 3.6.5、cygwin、VS 2017）。

配置

我在 config.mk 中取消了以下行的注释platform = x86_win32_vs_15。将以下行添加到 mk\platforms\[platform].mk PYTHON = /cygdrive/c/Software/Python/Python36。

安慰

启动命令 promt"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64并移至 src 目录。使用 .将 Cygwin 和 Python 添加到 PATH 中set path=%path%;c:\Software\cygwin64\bin;c:\Software\Python。当我这样做时，make export我看到两件事可能是问题所在。

和

有谁知道如何解决我面临的这个问题？

我已经为 C++ 安装了omniORB 并从这里下载了它http://omniorb.sourceforge.net/download.html。我试图构建这个程序（main.cpp）：

创建文件 echo.idl：

并运行omniidl -bcxx echo.idl。当我运行g++ main.cpp -o main它返回：

GNU 链接器无法获得omniORB 的定义，为什么？如何解决这个问题并获得二进制文件？

我正在尝试从此链接下载的源安装omniORB： https ://sourceforge.net/projects/omniorb/files/omniORB/omniORB-4.2.4/

我做了 readme.win32 指定的操作（安装 Cygwin，我已经有 Python3 和 Anaconda，安装 MinGW 而不是 Visual Studio，添加到 env PATH，在 /config/config.mk 和 \mk\platforms\x86_win32_mingw.mk 中进行了更改。 ..)，构建\src\tool\omkdepend，然后使用make export构建\src，

我总是收到这个错误：

有人对这个问题有任何想法吗？

我正在尝试在 RHEL 7.5 中安装omniORB。运行 make 命令时出现以下错误。我想要解决这个问题，我必须安装omniidl。

../../../../../src/tool/omniidl/cxx/idlpython.cc:31:26：致命错误：Python.h：没有这样的文件或目录

包括 PYTHON_INCLUDE

编译终止。make[4]: *** [idlpython.o] 错误 1 ​​make[4]: 离开目录/var/omniORB/omniORB-4.2.4/build/src/tool/omniidl/cxx' make[3]: *** [export] Error 1 make[3]: Leaving directory /var/omniORB/omniORB-4.2.4/build/src/tool/omniidl' make[2]: *** [ export] 错误 1 ​​make[2]: 离开目录/var/omniORB/omniORB-4.2.4/build/src/tool' make[1]: *** [export] Error 1 make[1]: Leaving directory /var/omniORB/omniORB-4.2.4/build/src' make: *** [all] 错误 1

当我运行 yum install omniidl 时，出现以下错误。请帮助如何解决相同的问题。

加载的插件：langpacks、product-id、search-disabled-repos、subscription-manager 此系统未向授权服务器注册。您可以使用订阅管理器进行注册。没有可用的软件包omniidl。错误：无事可做

我正试图围绕omniORB 准备使用它来与我们将获得的使用CORBA 的软件交互。我使用的策略是在omniORB（回声示例，特别是eg3_impl和eg3_cc）中举一个例子，并从接收到的软件中混合idl，直到它完成我想要的。为此，我试图将我正在编写的软件与omniORB 堆栈的其余部分隔离开来（即我正在尝试编写一个依赖于已编译库的独立makefile）。我正在使用从 sourceforge 下载的omniORB-4.2.3（通过omniORB-support.com 链接）。

我遇到的问题是，从独立 makefile 编译的示例似乎存在编译树示例没有的内存问题；

1. 从独立 Makefile 编译的示例试图解除分配不是“malloc()”或“new”的指针。（烦人，但不是炫耀）
2. 从独立 Makefile 编译的示例似乎没有正确记录字符串指针。（一个展示者）。

两个示例之间的源文件相同；唯一的区别是，非独立示例使用内置在omniORB树中的makefile结构，独立软件使用我编写的编译脚本，基于我在构建echo示例时观察到makefile结构所做的事情。

这是我的脚本：

...这就是我看到我的独立软件所做的事情（通过将 omniORB.cfg 跟踪级别设置为最大值来生成）

......这就是我看到的回声示例所做的

分析这两次运行时，我注意到损坏代码中的“bind_new_context”消息中缺少“test”和“my_context”的字符串......（这就是命名服务以“无效名称”异常响应的原因）。在断码中，消息更小，消息前面的size字段反映了更小的尺寸。

这与在损坏的代码中没有参数（或使用 NULL 参数）调用“bind_new_context”函数是一致的。但是两个示例都使用相同的源代码；使用相同的 rootContext 和 contextName 变量调用相同的 bind_new_context 函数，并以相同的方式填充。所以我认为我的构建脚本引入了某种环境混淆，而从omniORB编译的版本中不存在。这也可以解释为什么清理代码也被破坏了。但我花了 2 天时间试图摆脱它，但我已经空了。

有任何想法吗？

编辑：这是我基于构建脚本的树的 makefile 的输出。存在差异，但似乎没有实质性的差异。

我是 minGW 的新手。我正在尝试使用 minGW 编译omniORB 4.2.3，以便将库与我在 Dev-CPP 5.11 上开发的应用程序链接起来。我对两者都使用相同的工具链。gcc 版本是 4.9.2 (tdm64-1)。我尽可能到处搜索并找到链接器选项-municode。但错误仍然存​​在。我也尝试了包装解决方案。

这是错误的行：

感谢帮助。