問題タブ [omniorb]

環境

Python 3.7 をサーバー スケルトンとして使用し、Java スタブをクライアントとして使用するには、Windows 10 に omniORB と omniORBpy をインストールする必要があります。

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 (site-packages) です。

これは、PyCharmで発生するエラーです

一方で、omniORB をインストールして omniNames サービスを使用し、(Windows 上で) IOR を取得し、omniidl を使用して idl ファイルを「コンパイル」する方法をまだ見つけることができません。

次のようなものが必要です

Windows cmd (Windows にインストールされた Linux のサブシステムではありません)。

このリンクからダウンロードしたソースから omniORB をインストールしようとしています: https://sourceforge.net/projects/omniorb/files/omniORB/omniORB-4.2.4/

readme.win32 が指定したことを行いました (Cygwin をインストールし、既に Anaconda で Python3 を使用しており、Visual Studio の代わりに MinGW をインストールし、env PATH に追加し、 /config/config.mk と \mk\platforms\x86_win32_mingw.mk を変更しました。 ..)、\src\tool\omkdepend をビルドし、次に make export で \src をビルドします。

ただし、常にこのエラーが発生します。

誰でもこの問題について何か考えがありますか?

CORBA を使用するソフトウェアとのインターフェイスとして omniORB を使用する準備として、omniORB について理解しようとしています。私が使用している戦略は、omniORB の例 (echo の例、具体的には eg3_impl と eg3_cc) を使用し、受信したソフトウェアの idl を必要な動作をするまでブレンドすることです。そのために、私が書いているソフトウェアを残りの omniORB スタックから分離しようとしています (つまり、コンパイルされたライブラリに依存する独立した makefile を書こうとしています)。sourceforge から (omniORB-support.com リンク経由で) ダウンロードした omniORB-4.2.3 を使用しています。

私が直面している問題は、独立したメイクファイルからコンパイルされた例には、ツリーでコンパイルされた例にはないメモリの問題があるように見えることです。

1. 独立した Makefile からコンパイルされた例では、「malloc()」または「new」されていないポインターの割り当てを解除しようとしています。（迷惑ですが、ショーストッパーではありません）
2. 独立した Makefile からコンパイルされた例は、文字列ポインタを正しく記録していないようです。（ショーストッパー）。

ソース ファイルは 2 つの例で同じです。唯一の違いは、非独立の例では omniORB ツリーに組み込まれた makefile 構造を使用し、独立したソフトウェアでは、echo の例をビルドしたときに makefile 構造が行っていることを観察したことに基づいて、私が書いたコンパイル スクリプトを使用することです。

ここに私のスクリプトがあります:

...これが私の独立したソフトウェアの動作です (omniORB.cfg tracelevel を最大に設定することによって生成されます)。

...そして、これがエコーの例で見ていることです

これら 2 つの実行を分析すると、壊れたコードの「bind_new_context」メッセージから「test」と「my_context」の文字列が欠落していることに気付きます... (これが、ネーム サービスが「無効な名前」例外で応答する理由です)。壊れたコードでは、メッセージが小さくなり、メッセージの先頭にあるサイズ フィールドに小さいサイズが反映されます。

これは、壊れたコードで "bind_new_context" 関数が引数なし (または NULL 引数付き) で呼び出されることと一致しています。ただし、どちらの例も同じソース コードを使用しています。同じ rootContext 変数と contextName 変数を使用して同じ bind_new_context 関数を呼び出し、同じ方法で入力します。したがって、omniORB 内からコンパイルされたバージョンには存在しない、私のビルド スクリプトが導入するある種の環境の混乱があるに違いないと思います。これは、クリーンアップ コードが壊れた理由も説明している可能性があります。しかし、私はそれをゆるめようとして2日間費やしましたが、空になってしまいました.

何か案は？

編集: これは、ビルド スクリプトのベースとなったツリーの makefile からの出力です。違いはありますが、実質的なものは何もありません。