[omniORB] Building omniORBpy 2.4.6 on MSYS2 + MinGW64

[Nabil Ghodbane]

Dear all,

I am trying to compile *omniORBpy *on MYS2/MinGW64 and I am hitting
some issues.I am wondering whether someone has already tried to build
omniORBpy on MSYS2/MinGW. From the documentation, I understand that one
needs to simply extract the omniORBpy archive in src/lib, set
environment PATH, LD_LIBRARY_PATH, PYTHONPATH and run make export, but
sadly it fails. Digging this out, it appears that file modules/dir.mk does
not implement any MinGW32Build switch for pyd generation.
Before starting to implement this, I am wondering whether someone already
implemented this and could share it? Thanks. Regards

In addition, I would like to share that I could successfully compile and
run omniORB  but I had to fix several issues which I will share here:
  - 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.
  - gcc 13 introduces more stringent constraints and one has to use the
-fpermissive flag to be able to compile.
  -  omniORBpy does not seem to compile out of the box if one extracts it
to src/lib and runs make export. I may have missed something here though.

Regards.

Below is feedback about OmniORB

First my configuration: MSYS2 / MINGW64 with GCC 13.2 with C++17 as
baseline. In addition, I use Python 3.11.3 windows official binary.

MINGW64_NT-10.0-19044 PO16920 3.5.3.x86_64 2024-05-06 06:45 UTC x86_64 Msys
gcc version 13.2.0 (Rev6, Built by MSYS2 project)
$ g++ -dM -E -x c++ /dev/null | grep -F __cplusplus
#define __cplusplus 201703L


Following the README steps, I proceeded as follows:

   - set platform to platform = x86_win32_mingw in  *config\config.mk
   <http://config.mk>*
   - use python 3.11 windows distribution and fix *PYTHON* to the python
   executable in *mk\platforms\x86_win32_mingw.mk
   <http://x86_win32_mingw.mk>. No need to say, that one needs to expand
   LD_LIBRARY_PATH such that compilation works.*
   -  I compiled *omkdepend *as described in the README. Nothing to report
   here.
   - I then ran: make export in src folder...

 => It *miserably failed* when it tried to build omniidl.exe with  an error
message about WinMain:

C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crtexewin.c:67:(.text.startup+0xbd):
undefined reference to `WinMain'

=> fixed by adding: ,*--subsystem,console -municode* to the link options


   - Issue with /src/lib/omniORB/orbcore - GCC 13 is too stringent and one
   needs to add -fpermissive to the CXXOPTIONS  to relax the compiler
   constraints...


   - Issue about c++ standard (gcc 13 uses c++17 as default standard)

orbOptionsReg.cc:50:34: error: ISO C++17 does not allow dynamic exception
specifications

=> Fixed by changing the standard to c++14 in CXXOPTIONS (-std=c++14)

=> a lot of warnings due to this header file:
../../../../include/omniORB4/seqTemplatedecls.h:

 In instantiation of 'static T** _CORBA_Sequence_ObjRef<T, T_Elem,
T_Helper>::allocbuf(_CORBA_ULong) [with T = DynamicAny::DynAny; T_Elem

=>* Is this known to the developers  and can one safely ignore these ?*


   - Issue with src/services/mklib/dynstublib and a wrong library name:

=> D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
cannot find COS426_rt.lib: No such file or directory

Here obviously there is a bug in dir.mk, since it should use COS426_rt.a
and -lCOS426_rt as linked library

=> Fixed in dir.mk of that directory by replacing (dirty approach):

COS$(OMNIORB_MAJOR_VERSION)$(OMNIORB_MINOR_VERSION)$(OMNIORB_MICRO_VERSION)_rt.lib

     with:

-lCOS$(OMNIORB_MAJOR_VERSION)$(OMNIORB_MINOR_VERSION)$(OMNIORB_MICRO_VERSION)_rt

=>* there is obviously a bug in the implementation.*


   - examples: No issue!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.omniorb-support.com/pipermail/omniorb-list/attachments/20240714/4411e0f6/attachment.htm>