[omniORB] Can 64-bit omniidl 4.1.7 still target 32-bit ala gcc -m32? Working around Red Hat Linux 6.5 64-bit _omniidlmodule.so: wrong ELF

[Brian Brooks]

Thanks for omniORB we've been using it in many production environments
for over 10 years with no problems!

We're working towards migrating our app to from Red Hat Enterprise
Linux (RHEL) 5.4 32-bit to RHEL 6.5 64-bit. We're having a problem
invoking omniidl 4.1.7 32-bit on RHEL 64-bit.

omniidl: (The error was
'/root/m2/repository/NativeThirdParty/omniORB/omniORB-4.1.7-1-linux32/lib/_omniidlmodule.so:
wrong ELF class: ELFCLASS32')

**CONTEXT**
Our app is cross-platform (primarily Windows and Linux) and uses
omniorb to do CORBA communication both with SSL and without SSL. Our
build is fully automated by maven and includes extracting the omniorb
binaries, invoking omniidl and eventually packaging omniorb
dlls/.lib.so's into the app's installer.

RHEL only installs python 64-bit and after a couple of weeks going
back and forth with Red Hat support it seems that Red Hat does not
support a parallel install of python 32-bit (e.g. just a different
install prefix). Here's a statement from Kyle at Red Hat support,
"Unfortunately, we cannot assist in making the 32bit variant of the
Python interpreter fully functional within the 64bit OS. This is
primarily due to the packaging that is involved in the operation. The
32bit variant simply would overwrite the 64bit version already
installed and void the QE process that is implemented to make sure
that the Python applications installed by default to the system are
expected to be fully functional."

**POSSIBLE SOLUTION**
To workaround the ELFCLASS32 issue, Red Hat is recommending to use a
64-bit omniidl binary. So now I have a question for the omniorb team,
does omniidl 64-bit support targeting 32-bit similar to gcc 64-bit's
machine option -m32? I'm concerned that a 64-bit omniidl would
generate cpp source code that breaks if compiled with gcc -m32.

Any advice from the omniorb users would be greatly appreciated!

Sincerely,
Brian Brooks
brian.brooks at rockwellcollins.com / 678-252-4498

[Duncan Grisby]

Post by Brian Brooks
We're working towards migrating our app to from Red Hat Enterprise
Linux (RHEL) 5.4 32-bit to RHEL 6.5 64-bit. We're having a problem
invoking omniidl 4.1.7 32-bit on RHEL 64-bit.
omniidl: (The error was
wrong ELF class: ELFCLASS32')

As I think you understand, that's because you're using a 32 bit build of
omniidl against a 64 bit Python.

[...]

Post by Brian Brooks
RHEL only installs python 64-bit and after a couple of weeks going
back and forth with Red Hat support it seems that Red Hat does not
support a parallel install of python 32-bit (e.g. just a different
install prefix).

RedHat might not "support" it, but you could of course just compile and
install Python yourself with whatever prefix you like, as long as you
keep it apart from RedHat's install.

[...]

Post by Brian Brooks
**POSSIBLE SOLUTION**
To workaround the ELFCLASS32 issue, Red Hat is recommending to use a
64-bit omniidl binary. So now I have a question for the omniorb team,
does omniidl 64-bit support targeting 32-bit similar to gcc 64-bit's
machine option -m32? I'm concerned that a 64-bit omniidl would
generate cpp source code that breaks if compiled with gcc -m32.

omniidl generates exactly the same C++ source code no matter what
platform you run it on. So, yes, you can use a 64 bit omniidl to
generate C++, then compile it as 32 bit.

Duncan.