Menu
▾
▴
Re: [vrjuggler-devel] [ vrjuggler-Bugs-1108774 ] Dependency package omniOrb incorrect
|
From: Greg S. (Contractor) <gre...@nr...> - 2005-01-25 22:50:32
|
Patrick,
I tested the omniOrb build on the following architectures:
RHEL
RH8
Both failed.
Let me describe further what I did specifically on RH8 to make this
error show up.
1) d/l vrjuggler-2.0-beta2.src
d/l vrjuggler-2.0-beta2.linux-rh8-deps.tar.bz2
untarred each
2) changed in src and created build
changed into build and created shell script to configure
shell script contains:
setenv NOPP_TOOLKITS_DIR to dir (specifics don't matter here)
../configure.pl --prefix=$NOPP_TOOLKITS_DIR/vrjuggler --module=Tweek
--with-jdkhome=$JDK_HOME
CPPFLAGS=-I$NOPP_TOOLKITS_DIR/vrjuggler/vrjuggler-2.0-beta2.linux-rh8-deps/include
--with-cxx-orb=omniORB4
--with-cxx-orb-root=$NOPP_TOOLKITS_DIR/vrjuggler/vrjuggler-2.0-beta2.linux-rh8-deps
--with-java-orb=JDK
--with-cppunit=$NOPP_TOOLKITS_DIR/vrjuggler/vrjuggler-2.0-beta2.linux-rh8-deps
--with-boost=$NOPP_TOOLKITS_DIR/vrjuggler/vrjuggler-2.0-beta2.linux-rh8-deps
--with-cppdom=$NOPP_TOOLKITS_DIR/vrjuggler/vrjuggler-2.0-beta2.linux-rh8-deps
--with-junit=$NOPP_TOOLKITS_DIR/junit/junit3.8.1/junit.jar
--with-gmtl-prefix=$NOPP_TOOLKITS_DIR/vrjuggler/vrjuggler-2.0-beta2.linux-rh8-deps
3) run the shell script, it creates the appropriate stuff (instlinks,
external, modules, reconfig, Makefile, config.cache)...
verify that "reconfig" is the same with some cleanup stuff, even
run reconfig if you like, won't matter
4) make build
this starts to build the Tweek module and within 10 secs (2.4 ghz
cpu) you will have a compile crash:
/usr/bin/perl
/home/depot/main/nopp/toolkits/vrjuggler/vrjuggler-2.0-beta2.src/release/scripts/install-dir.pl
-l \
-i
/home/depot/main/nopp/toolkits/vrjuggler/vrjuggler-2.0-beta2.linux-rh8-deps/lib/python2.2/site-packages/omniidl
\
-o
/home/depot/main/nopp/toolkits/vrjuggler/vrjuggler-2.0-beta2.src/build/instlinks/lib/python/omniidl
ERROR: Cannot chdir to
/home/depot/main/nopp/toolkits/vrjuggler/vrjuggler-2.0-beta2.linux-rh8-deps/lib/python2.2/site-packages/omniidl:
No such file or directory
This dir does not exist, of course, in the deps package for RH8.
Somewhere a script is not getting the change
path you guys made (of ~lib/python/).
5) Things you might be interested in:
Configure output when I ran the "make build" above which verifies
that I have python2.2 of course.
Keep in mind that the version of Redhat 8 I am testing this on is EXACTLY
the default version off of the RH8 cds (no upgrades of patches
whatsoever). We had to keep this at
that version for another reason.
checking for cygpath... no
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking whether we are using the Intel C compiler... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking whether we are using the Intel C++ compiler... no
checking whether g++ version is >= 3.0... 3.2
checking whether gcc accepts -pipe... yes
checking whether g++ accepts -pipe... yes
checking for C++ template support... yes
checking for Perl version >= 5.004... /usr/bin/perl
checking for make... make
checking whether make is GNU make... yes
checking whether GNU make version is >= 3.78... 3.79.1
checking whether ln -s works... yes
checking for vrjuggler group... no
checking for python... /usr/bin/python
checking for Python version... 2.2
The big question might be " what is PYTHON_HOME set to?"
It doesn't matter. It defaults to "/usr", but I unset it, set it to
other things,
etc. Doesn't matter. This error is in the config of Tweek somewhere
or the paths of the omniOrb should be left as they were when you d/l
them.
The downloaded version of omniOrb-4.0.2 after build and install, it's
lib dir looks like this:
libCOS4.a libomniCodeSets4.so libomniORB4.so.0
libCOS4.so libomniCodeSets4.so.0 libomniORB4.so.0.2
libCOS4.so.0 libomniCodeSets4.so.0.2 libomnithread.a
libCOS4.so.0.2 libomniDynamic4.a libomnithread.so
libCOSDynamic4.a libomniDynamic4.so libomnithread.so.3
libCOSDynamic4.so libomniDynamic4.so.0 libomnithread.so.3.0
libCOSDynamic4.so.0 libomniDynamic4.so.0.2 python2.2
libCOSDynamic4.so.0.2 libomniORB4.a
libomniCodeSets4.a libomniORB4.so
Here is a script I use to standardly install omniOrb:
if test ! -d ./lib; then
echo "[OMNIORB Setup]: Begin"
tar jxf omniORB-4.0.2-src.tar.bz2
echo "[OMNIORB Setup]: Building"
cd ./omniORB-4.0.2
mkdir ./build
cd ./build
../configure --prefix=$P4ROOT/depot/main/nopp/toolkits/omniorb
--with-omniORB-config=$P4ROOT/depot/main/nopp/toolkits/omniorb/omniORB-nrl.cfg
>& ../../omniorb-configure-log.txt
echo "[OMNIORB Setup]: Compiling"
make >& ../../omniorb-compile-log.txt
echo "[OMNIORB Setup]: Installing"
make install >& ../../omniorb-install-log.txt
cd ..
echo "[OMNIORB Setup]: Finished"
else
echo "[OMNIORB Setup]: omniORB already set up. Run
'clobber-omniorb.sh' to redo."fi
There is nothing special in the config that we do that changes the
paths. That is the default path
arrangement for what appears to be about the same version of omniOrb
used in the deps.
----
Please check this further.
Thanks
greg
SourceForge.net wrote:
>Bugs item #1108774, was opened at 2005-01-24 19:01
>Message generated for change (Comment added) made by patrickh
>You can respond by visiting:
>https://sourceforge.net/tracker/?func=detail&atid=108041&aid=1108774&group_id=8041
>
>Category: Build System
>
>
>>Group: v1.1
>>Status: Closed
>>Resolution: Works For Me
>>
>>
>Priority: 5
>Submitted By: Nobody/Anonymous (nobody)
>
>
>>Assigned to: Patrick Hartling (patrickh)
>>
>>
>Summary: Dependency package omniOrb incorrect
>
>Initial Comment:
>Detailed Description:
>-----------------------------
>The dependency packages contain the package omniOrb.
>The lib directory in the deps package (at least with
>Fedora Core 1)
>does not contain the directory
>./python2.2/site-packages, which is
>what the build system is looking for (it crashes, of
>course). If you download omniORB-4.0.2, which appears
>to be the correct version, the directory
>"python2.2/site-packages" is created after you "make"
>and "make install".
>
>Suggested Solutions:
>-------------------------------
>In order to prevent having someone d/l the omniOrb
>package separately and taking advantage of the
>dependency package (which is their intent), do the
>following:
>
>1) d/l omniOrb-4.0.2, configure, build and install
>locally and copy the dirs "lib", "include" and "bin"
>into the dependencies. Replace old omniOrb stuff and
>./lib/python dir. I am sure that a developer was
>probably trying to shortcut that link
>(python2.2/site-packages), but didn't update the build
>system to handle it. That would be Option 2
>
>2) Modify build of Juggler to handle the dependency
>path lib/python instead of lib/python2.2/site-packages.
> But obviously I don't recommend - best to follow how
>the source package does things for consistency if
>someone wants to compile their own version of omniOrb.
>
>Just FYI, I again compiled and found this build bug
>under RHEL (Red Hat Enterprise Linux WS release 3
>(Taroon Update 4)).
>I will also be testing it on Fedora Core 3 soon, but
>this is OS dependent.
>
>Greg Schmidt
>Virtual Reality Laboratory
>Naval Research Laboratory
>gre...@nr...
>
>
>
>
>----------------------------------------------------------------------
>
>
>
>>Comment By: Patrick Hartling (patrickh)
>>
>>
>Date: 2005-01-24 21:28
>
>Message:
>Logged In: YES
>user_id=49856
>
>As far as I can tell, this way of installing the omniORB
>Python pieces works just fine. That is, when I test it, it
>works just as it should.
>
>The dependency bundling of omniORB is done this way
>specifically to avoid requiring that users set $PYTHONPATH
>so that omniidl and friends can find the Python extension
>modules that they need. At run time, the omniORB Python
>scripts search for the modules, and one of the places that
>they search is relative to the directory containing the
>script in ../lib/python. For example, look at the script
>omniidl. It extends the Python library search path using
>that directory.
>
>----------------------------------------------------------------------
>
>You can respond by visiting:
>https://sourceforge.net/tracker/?func=detail&atid=108041&aid=1108774&group_id=8041
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>Tool for open source databases. Create drag-&-drop reports. Save time
>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>_______________________________________________
>vrjuggler-devel mailing list
>vrj...@li...
>https://lists.sourceforge.net/lists/listinfo/vrjuggler-devel
>
>
|