compiling omniORB 32bits libraries on a 64bits machine (Suse) - Object

On Feb 21, 7:12 pm, vlad....@gmail.com wrote:
> First thing I tried is to use the 32bits omniORB that I compiled on
> Redhat (32bits) but then when running the exe "omniidl" I would get
> the error everybody posts about "Could not open IDL compiler module
> _omniidlmodule.so ..."
>
> So I compiled it myself on Suse (64bits) and got 64bits libraries, I
> can't use them, I need 32bits libraries.
> Then I used manual configuration and added the flags "-m32 -Wa,-32 -
> Wl,-melf_i386".
> It started compiling fine but then during the build I get the same
> error when it uses "omniidl":
>
> ../../../bin/i586_linux_2.0_glibc2.1/omniidl -bcxx -p../../../src/lib/
> omniORB -Wbdebug -Wba -p../../../src/lib/omniORB -Wbdebug -v -
> ComniORB4 ../../../idl/Naming.idl
> omniidl: ERROR!
> omniidl: Could not open IDL compiler module _omniidlmodule.so
> omniidl: Please make sure it is in directory /n/fast/vnicul/
> fix_omniORB2/omniORB-4.1.0/lib/i586_linux_2.0_glibc2.1
> omniidl: (or set the PYTHONPATH environment variable)
> omniidl: (The error was '/n/fast/vnicul/fix_omniORB2/omniORB-4.1.0/lib/
> i586_linux_2.0_glibc2.1/_omniidlmodule.so: cannot open shared object
> file: No such file or directory')
>
> How comes ? I compiled it my Suse box and it won't run on it ?
> Do you please have any light to shed on this mystery ?
> Am I following the right track (manual config, add the flags myself) ?
>
> If I'm not clear, don't hesitate to ask me for clarification.
> Thanks very much for your time.



I have found a solution !!!

I have to point config.mk to python in /usr/local/bin/python and
not /usr/bin/python
But there's still a problem left.
The build system creates omniidlrun.py start with
#!/usr/bin/env python
instead of
#!/usr/bin/env /usr/local/bin/python

So the build still fails.
So I modify the script, rerun the makefile (make export in src) and it
fails again
Because the makefile rewrites that script and ignores my
modifications.

In article <1172085130.291658.49340@p10g2000cwp.googlegroups.com>,
<vlad.nic@gmail.com> wrote:

>First thing I tried is to use the 32bits omniORB that I compiled on
>Redhat (32bits) but then when running the exe "omniidl" I would get
>the error everybody posts about "Could not open IDL compiler module
>_omniidlmodule.so ..."

That's because omniidl is implemented as a Python extension module.
The Python executable you are using is a 64 bit executable, so it
can't load a 32 bit library.

>So I compiled it myself on Suse (64bits) and got 64bits libraries, I
>can't use them, I need 32bits libraries.
>Then I used manual configuration and added the flags "-m32 -Wa,-32 -
>Wl,-melf_i386".
>It started compiling fine but then during the build I get the same
>error when it uses "omniidl":

You still have a 32 bit Python extension module and a 64 bit Python
executable.

To get around the problem, you should either build a 32 bit Python
interpreter, or build a 64 bit omniidl and copy its _omniidlmodule.so
file on top of the 32 bit one.

Python and the omniidl module are only required for compiling IDL --
they aren't used at run time in your C++ programs.

Cheers,

Duncan.

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

Thanks for the answer Duncan.
That's why it worked with my other python in /usr/local/bin/ then

But the PYTHON path I set up in my i586(something).mk file does not
get written in the script omniidlrun. Which makes it fail. And if I
modify it, it gets written again by the build system.


On Feb 22, 11:08 am, Duncan Grisby <duncan-n...@grisby.org> wrote:
> In article <1172085130.291658.49...@p10g2000cwp.googlegroups.com>,
>
> <vlad....@gmail.com> wrote:
> >First thing I tried is to use the 32bits omniORB that I compiled on
> >Redhat (32bits) but then when running the exe "omniidl" I would get
> >the error everybody posts about "Could not open IDL compiler module
> >_omniidlmodule.so ..."
>
> That's because omniidl is implemented as a Python extension module.
> The Python executable you are using is a 64 bit executable, so it
> can't load a 32 bit library.
>
> >So I compiled it myself on Suse (64bits) and got 64bits libraries, I
> >can't use them, I need 32bits libraries.
> >Then I used manual configuration and added the flags "-m32 -Wa,-32 -
> >Wl,-melf_i386".
> >It started compiling fine but then during the build I get the same
> >error when it uses "omniidl":
>
> You still have a 32 bit Python extension module and a 64 bit Python
> executable.
>
> To get around the problem, you should either build a 32 bit Python
> interpreter, or build a 64 bit omniidl and copy its _omniidlmodule.so
> file on top of the 32 bit one.
>
> Python and the omniidl module are only required for compiling IDL --
> they aren't used at run time in your C++ programs.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby --
> -- dun...@grisby.org --
> --http://www.grisby.org--

It's ok now, I just had to set my PATH to pick up python in /usr/local/
bin first.

And now everything is working as our good lord intended it

I still wonder how to install the library when doing a manual
configuration, or even if it's at all possible.
I'll be looking into the forums.

Thanx, Vlad


On Feb 22, 12:48 pm, vlad....@gmail.com wrote:
> Thanks for the answer Duncan.
> That's why it worked with my other python in /usr/local/bin/ then
>
> But the PYTHON path I set up in my i586(something).mk file does not
> get written in the script omniidlrun. Which makes it fail. And if I
> modify it, it gets written again by the build system.
>
> On Feb 22, 11:08 am, Duncan Grisby <duncan-n...@grisby.org> wrote:
>
> > In article <1172085130.291658.49...@p10g2000cwp.googlegroups.com>,
>
> > <vlad....@gmail.com> wrote:
> > >First thing I tried is to use the 32bits omniORB that I compiled on
> > >Redhat (32bits) but then when running the exe "omniidl" I would get
> > >the error everybody posts about "Could not open IDL compiler module
> > >_omniidlmodule.so ..."
>
> > That's because omniidl is implemented as a Python extension module.
> > The Python executable you are using is a 64 bit executable, so it
> > can't load a 32 bit library.
>
> > >So I compiled it myself on Suse (64bits) and got 64bits libraries, I
> > >can't use them, I need 32bits libraries.
> > >Then I used manual configuration and added the flags "-m32 -Wa,-32 -
> > >Wl,-melf_i386".
> > >It started compiling fine but then during the build I get the same
> > >error when it uses "omniidl":
>
> > You still have a 32 bit Python extension module and a 64 bit Python
> > executable.
>
> > To get around the problem, you should either build a 32 bit Python
> > interpreter, or build a 64 bit omniidl and copy its _omniidlmodule.so
> > file on top of the 32 bit one.
>
> > Python and the omniidl module are only required for compiling IDL --
> > they aren't used at run time in your C++ programs.
>
> > Cheers,
>
> > Duncan.
>
> > --
> > -- Duncan Grisby --
> > -- dun...@grisby.org --
> > --http://www.grisby.org--

In article <1172148529.243160.210670@l53g2000cwa.googlegroups.com>,
<vlad.nic@gmail.com> wrote:

>Thanks for the answer Duncan.
>That's why it worked with my other python in /usr/local/bin/ then
>
>But the PYTHON path I set up in my i586(something).mk file does not
>get written in the script omniidlrun. Which makes it fail. And if I
>modify it, it gets written again by the build system.

Those platform makefiles are not used if you use the autoconf
configure script. You should use an incantation like this to specify
the Python to use:

./configure PYTHON=/usr/local/bin/python --prefix=...

That way the scripts all get set up the right way.

Cheers,

Duncan.

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