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