[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 class: ELFCLASS32

[Duncan Grisby]

On Mon, 2014-06-16 at 10:48 -0400, Brian Brooks wrote:

> 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')

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

[...]
> 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.

[...]
> **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.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --