[omniORB] EXT: Re: Building omniORBpy 2.4.6 on MSYS2 + MinGW64

Tue Jul 16 21:56:40 UTC 2024

Hi Marc, Duncan, all,

thanks for your reply. In my case, the issue is slightly different, since I
am targeting x86_win_mingw and sadly the patches do not apply.

Here, the issue is the following:

for each idl file (e.g. corbaidl.idl), the omniORBpy/modules/dir.mk script
calls the python omniidl compiler interface ((lib/python/omniidl/main.py).
In that call, it  runs a preprocessor command aimed to generated the c++
code from the IDL:

      file = os.popen(preproc_cmd, "r")

 with file: the file descriptor and preproc_cmd the preprocessor command
which is a call to omnicpp for c++ code generation:
 omnicpp -lang-c++ -undef -D__OMNIIDL__=0x2630 -I "../../.
./../../idl" -I "D:/msys64/idl/omniORB" -I "D:/msys64/share/idl/omniORB" -I
"D:/msys64/idl/omniORB" -D__OMNIIDL_PYTHON__
"../../../../../idl/corbaidl.idl"

The file descriptor as well as the idl file are given as arguments to
_omniidl.compile indeed IdlPyCompile of idlpython.cc
and strangely IdlPyCompile  fails to run:  file = fdopen(fd, "r")  (fd is
the file descriptor os.popen(preproc_cmd, "r"))

The issue here is simply that IdlPyCompile  fails to open the file
descriptor.

I am wondering whether this could not be linked to some encoding issue
here, since if i interactively run

omnicpp -lang-c++ -undef -D__OMNIIDL__=0x2630 -I "../../.
./../../idl" -I "D:/msys64/idl/omniORB" -I "D:/msys64/share/idl/omniORB" -I
"D:/msys64/idl/omniORB" -D__OMNIIDL_PYTHON__
"../../../../../idl/corbaidl.idl

it generates the c++ code without error:

Does someone have some suggestions on how to proceed here ?

Thanks for your valuable feedback.

On Mon, Jul 15, 2024 at 9:47 AM Lucca-Daniau, Marc-Francois <
Marc-Francois.Lucca-Daniau at gehealthcare.com> wrote:

> Hello,
>
>
>
> Made a try some time ago and submitted some changes : see "Building
> OmniORB on MSYS2" thread on that mailing list.
>
>
>
> Hope it could help.
>
>
> Regards,
>
> MFLD
>
>
>
> *From:* Nabil Ghodbane via omniORB-list <omniorb-list at omniorb-support.com>
>
> *Sent:* Sunday, 14 July, 2024 21:36
> *To:* Duncan Grisby <duncan at grisby.org>
> *Cc:* omniORB-list at omniorb-support.com
> *Subject:* EXT: Re: [omniORB] Building omniORBpy 2.4.6 on MSYS2 + MinGW64
>
>
>
> *AVERTISSEMENT: *cet email provient de l'extérieur de GE. Veuillez
> valider l'adresse e-mail de l'expéditeur avant de cliquer sur les liens ou
> les pièces jointes, car ils risquent de ne pas être sûrs.
>
>
>
> Hi,
>
> yes you're right it's 4.2.6; I modified the dir.mk files such that the
> pyd files are now generated.
>
> Unfortunately,  I come to this error during the installation process about
> corbaidl.idl
>
> Does this by chance ring a bell ? I welcome hints about how to proceed
> here .
>
> I will of course gather all these patches into one single file that I will
> share at the end .
>
> Thanks for your valuable feedback.
>
>
>
> Traceback (most recent call last):
>
>   File "<string>", line 33, in <module>
>
>   File
> "D:\msys64\home\nghodban\workspace\BUILD\omniORB-4.2.6\lib\python\omniidl\main.py",
> line 430, in main
>
>     tree = _omniidl.compile(file, name)
>
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> OSError: Cannot open file descriptor
>
>
>
> nghodban at PO16920 MINGW64 ~/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy
>
> $ make export
>
> PYSUBDIR = python3
>
> making export in src/lib/omniORBpy/modules...
>
> make[1]: Entering directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/modules'
>
> File pydistdate.hh hasn't changed.
>
> File _omnipy.pyd hasn't changed.
>
> making export in src/lib/omniORBpy/modules/codesets...
>
> make[2]: Entering directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/modules/codesets'
>
> File _omnicodesets.pyd hasn't changed.
>
> make[2]: Leaving directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/modules/codesets'
>
> making export in src/lib/omniORBpy/modules/connections...
>
> make[2]: Entering directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/modules/connections'
>
> File _omniConnMgmt.pyd hasn't changed.
>
> make[2]: Leaving directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/modules/connections'
>
> make[1]: Leaving directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/modules'
>
> making export in src/lib/omniORBpy/python3...
>
> make[1]: Entering directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/python3'
>
> making export in src/lib/omniORBpy/python3/omniidl_be...
>
> make[2]: Entering directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/python3/omniidl_be'
>
> File __init__.py hasn't changed.
>
> File python.py hasn't changed.
>
> Listing '.'...
>
> Listing '.\\cxx'...
>
> Listing '.\\cxx\\dynskel'...
>
> Listing '.\\cxx\\header'...
>
> Listing '.\\cxx\\impl'...
>
> Listing '.\\cxx\\skel'...
>
> make[2]: Leaving directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/python3/omniidl_be'
>
> making export in src/lib/omniORBpy/python3/omniORB...
>
> make[2]: Entering directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/python3/omniORB'
>
> ../../../../../bin/x86_win32/omniidl -v
> -p../../../../../python3/omniidl_be \
>
>         -I../../../../../idl \
>
>         -I../../../idl/omniORB \
>
>         -I../../../share/idl/omniORB \
>
>         -I/idl/omniORB \
>
>         -bpython -nf -Wbno_package ../../../../../idl/corbaidl.idl
>
> omniidl: Importing back-end 'python'
>
> omniidl: 'python' imported from
> 'D:\msys64\home\nghodban\workspace\BUILD\omniORB-4.2.6\lib\python\omniidl_be\python.py'
>
> omniidl: Preprocessing '../../../../../idl/corbaidl.idl' with
> 'D:\msys64\home\nghodban\workspace\BUILD\omniORB-4.2.6\bin\x86_win32\omnicpp
> -lang-c++ -undef -D__OMNIIDL__=0x2630 -I "../../../..
>
> /../idl" -I "../../../idl/omniORB" -I "../../../share/idl/omniORB" -I
> "D:/msys64/idl/omniORB" -D__OMNIIDL_PYTHON__
> "../../../../../idl/corbaidl.idl"'
>
> omniidl: Running front end
>
> Traceback (most recent call last):
>
>   File "<string>", line 33, in <module>
>
>   File
> "D:\msys64\home\nghodban\workspace\BUILD\omniORB-4.2.6\lib\python\omniidl\main.py",
> line 430, in main
>
>     tree = _omniidl.compile(file, name)
>
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> OSError: Cannot open file descriptor
>
> make[2]: *** [dir.mk:16: corbaidl_idl.py] Error 127
>
> make[2]: Leaving directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/python3/omniORB'
>
> make[1]: *** [dir.mk:12: export] Error 2
>
> make[1]: Leaving directory
> '/home/nghodban/workspace/BUILD/omniORB-4.2.6/src/lib/omniorpy/python3'
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Jul 14, 2024 at 8:34 PM Duncan Grisby <duncan at grisby.org> wrote:
>
> On Sun, 2024-07-14 at 14:16 +0200, Nabil Ghodbane via omniORB-list
> wrote:
>
> [...]
> >   - It seems that omniORB 2.4.6 at least does not support c++17
> > standard on MinGW and one has to fall back to c++14.
>
> I assume you mean 4.2.6. There was never a 2.4.6 release.
>
> Regardless, 4.2 is very old. The current release is 4.3.2. You are
> unlikely to have much success in using up-to-date C++ and Python
> versions with old omniORB versions.
>
> MinGW is not a supported compiler for omniORB. You might be able to
> make it work, but it is no surprise if it doesn't work at present.
>
> If you are successful in compiling omniORB and omniORBpy 4.3.2 with
> MinGW, please send patches.
>
> Regards,
>
> Duncan.
>
> --
> Duncan Grisby <duncan at grisby.org>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.omniorb-support.com/pipermail/omniorb-list/attachments/20240716/229f5967/attachment-0001.htm>