May 2010 - cgma-dev - mailman3.cels.anl.gov

buildbot failure in Fathom on cgm-cubit
by cgma-dev＠lists.mcs.anl.gov 19 May '10

19 May '10

The Fathomatic has detected a failed build of cgm-cubit on Fathom. Full details are available at: http://gnep.mcs.anl.gov:8010/builders/cgm-cubit/builds/116 Buildbot URL: http://gnep.mcs.anl.gov:8010/ Buildslave for this Build: gnep Build Reason: The Nightly scheduler named 'nightly' triggered this build Build Source Stamp: None Blamelist: BUILD FAILED: failed configure LOG EXCERPT: checking whether to build static libraries... yes checking for g77 option to produce PIC... -fPIC checking if g77 PIC flag -fPIC works... yes checking if g77 static flag -static works... yes checking if g77 supports -c -o file.o... yes checking whether the g77 linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so (cached) (cached) checking how to hardcode library paths into programs... immediate checking for a sed that does not truncate output... /bin/sed checking whether byte ordering is bigendian... no checking for known C compilers... GNU checking for known compiler/OS combinations... GNU:x86_64 checking for known c++ compilers... GNU checking for known compiler/OS combinations... GNU:x86_64 checking how to get verbose linking output from gfortran... -v checking for Fortran libraries of gfortran... -L/usr/lib/gcc/x86_64-linux-gnu/4.2.4 -L/usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../.. -lgfortranbegin -lgfortran -lm checking for dummy main to link with Fortran libraries... ./configure: line 23628: conftest.err: Disk quota exceeded cat: conftest.err: No such file or directory none checking for Fortran name-mangling scheme... lower case, underscore, no extra underscore checking for C++-standard library in std:: namespace... yes checking for C++-standard I/O in std:: namespace... yes checking if C++ template definitions should be included... yes checking for AcisQueryEngine::instance_ in /home/sharp/3rdparty/Cubit/Cubit64/cubit-10.2-amd64/bin/libcubiti19.so... yes CXXFLAGS = -Wall -pipe -pedantic -O2 -DNDEBUG configure: creating ./config.status config.status: creating Makefile config.status: creating util/Makefile config.status: creating geom/Makefile config.status: creating geom/ACIS/Makefile sed: couldn't close stdout: Disk quota exceeded config.status: creating geom/Cholla/Makefile config.status: creating geom/facet/Makefile config.status: creating geom/facetbool/Makefile config.status: creating geom/OCC/Makefile config.status: creating geom/parallel/Makefile config.status: creating geom/virtual/Makefile config.status: creating init/Makefile config.status: creating compat/Makefile config.status: creating cgm.make config.status: creating itaps/Makefile config.status: creating itaps/iGeom-Defs.inc config.status: creating itaps/SIDL/Makefile config.status: creating itaps/SIDL/common.make config.status: creating itaps/SIDL/iGeom-SIDL-Defs.inc config.status: creating test/Makefile config.status: creating cgm_apps/Makefile config.status: creating cgm_apps/examples/Makefile config.status: creating cgm_apps/examples/driverc++/Makefile config.status: error: cannot find input file: cgm_apps/examples/facetdriver/Makefile.in sincerely, -The Fathomatic

1 0

r3903 - cgm/trunk/itaps
by sjackson＠cae.wisc.edu 14 May '10

14 May '10

Author: sjackson Date: 2010-05-14 14:34:52 -0500 (Fri, 14 May 2010) New Revision: 3903 Modified: cgm/trunk/itaps/iGeom_CGMA.cc Log: Workaround to allow iGeom to export .step and .iges files Background: The import and export functions of the AcisQueryEngine accept optional log file names, and will, for some file formats, always write a default log file if no name is provided. AcisQueryEngine misuses strcpy as follows: char* log_filename = NULL; if( {no user-provided log name} ) strcpy( log_filename, "default_logfile" ); // writes to null pointer This means that importing or exporting .step or .iges files from iGeom results in a segfault. This checkin works around this problem for exporting files only. (Fixing .step/.iges import would require changing iGeom to use GeometryQueryTool::import_solid_model() instead of the simpler GeometryQueryTool::read_geometry_file() currently used.) Fixing the bugs in AcisQueryEngine would be more appropriate than this workaround, however: * This is the only way to fix CGM when built against Cubit 10, and * AcisQueryEngine may see an overhaul when CGM is upgraded for Cubit 12. Modified: cgm/trunk/itaps/iGeom_CGMA.cc =================================================================== --- cgm/trunk/itaps/iGeom_CGMA.cc 2010-05-14 16:41:09 UTC (rev 3902) +++ cgm/trunk/itaps/iGeom_CGMA.cc 2010-05-14 19:34:52 UTC (rev 3903) @@ -501,12 +501,24 @@ ERROR(iBase_FAILURE, "Unknown geometry file extension and no file type."); } + /** + * Work around AcisQueryEngine log file handling bug: + * If the export format is iges or step, be sure the log file name is not null + */ + const char* logfile_name = NULL; + if( file_type == "IGES" ){ + logfile_name = "igeom_iges_export.log"; + } + else if( file_type == "STEP" ){ + logfile_name = "igeom_step_export.log"; + } + // process options (none right now...) DLIList<RefEntity*> bodies; int num_ents_exported; CubitString cubit_version(" (iGeom)"); CubitStatus status = gqt->export_solid_model(bodies, name, file_type.c_str(), - num_ents_exported, cubit_version); + num_ents_exported, cubit_version, logfile_name ); if (CUBIT_SUCCESS != status) ERROR(iBase_FAILURE, "Trouble saving geometry file.");

1 0

r3891 - cgm/trunk/m4
by kraftche＠cae.wisc.edu 12 May '10

12 May '10

Author: kraftche Date: 2010-05-12 17:10:02 -0500 (Wed, 12 May 2010) New Revision: 3891 Modified: cgm/trunk/m4/compiler.m4 Log: sync compiler config with MOAB Modified: cgm/trunk/m4/compiler.m4 =================================================================== --- cgm/trunk/m4/compiler.m4 2010-05-12 22:08:09 UTC (rev 3890) +++ cgm/trunk/m4/compiler.m4 2010-05-12 22:10:02 UTC (rev 3891) @@ -14,6 +14,31 @@ rm .tmp ]) + +########## Helper function for FATHOM_CHECK_COMPILERS ############# +# args: compiler variable, compiler list, path +AC_DEFUN([FATHOM_SET_MPI_COMPILER], [ + if test "x" = "x${$1}"; then + if test "x" = "x$3"; then + AC_CHECK_PROGS([$1], [$2], [false]) + else + $1=false + for prog in $2 ; do + if test -x "$3/$prog"; then + $1="$3/$prog" + AC_SUBST($1) + export $1 + break + fi + done + fi + + if test "x${$1}" = "xfalse"; then + AC_MSG_ERROR([Cannot find MPI compiler. Try specifying \$$1]) + fi + fi +]) + ####################################################################################### # Implement checks for C and C++ compilers, with all corresponding options # @@ -52,91 +77,38 @@ # Need to check this early so we can look for the correct compiler AC_ARG_WITH( [mpi], AC_HELP_STRING([[--with-mpi(=DIR)]], [Enable parallel support]), [WITH_MPI=$withval],[WITH_MPI=no] ) -case "x$WITH_MPI" in - xno) - CC_LIST= - CXX_LIST= - FC_LIST= - F77_LIST= - ;; - xyes) - CC_LIST="mpicc mpcc" - CXX_LIST="mpiCC mpCC mpicxx" - FC_LIST="mpif90"

1 0

Re: [cgma-dev] r3886 - cgm/trunk/m4
by Robert Smith 12 May '10

12 May '10

Something in this change causes shared builds to fail. I used the information provided last week about putting Cubit in my LPATH and tried rebuilding CGM in shared mode using Cubit and OCC in 2 different configurations. Both fail when linking libcgm with the following error: gcc: libcgm.so.0: No such file or directory gcc: unrecognized option '-soname' make[2]: *** [libcgm.la] Error 1 This is because the last line of the long link statement says: "/home/fathom/3rdparty/occ/OpenCASCADE6.3.0/gcc/lib/libTKBinL.so -ldl - lm -lc -soname libcgm.so.0 -o .libs/libcgm.so.0.0.0" I've tried to figure out what the error is in this file but I haven't found it. Somehow the '-Wl,' switch is being removed from the archive commands. Building with the previous rev, 3835, works. --Bob On May 12, 2010, at 12:53 PM, kraftche(a)cae.wisc.edu wrote: > Author: kraftche > Date: 2010-05-12 12:53:11 -0500 (Wed, 12 May 2010) > New Revision: 3886 > > Modified: > cgm/trunk/m4/compiler.m4 > Log: > sync compiler configuration w/ MOAB > > Modified: cgm/trunk/m4/compiler.m4 > =================================================================== > --- cgm/trunk/m4/compiler.m4 2010-05-12 17:50:25 UTC (rev 3885) > +++ cgm/trunk/m4/compiler.m4 2010-05-12 17:53:11 UTC (rev 3886) > @@ -21,6 +21,7 @@ > # CPP - The C preprocessor > # CC - The C compiler > # CXX - The C++ compiler > +# FC - The Fortran compiler > # CFLAGS - C compiler flags > # CXXFLAGS - C++ compiler flags > # WITH_MPI - 'yes' if parallel support, 'no' otherwise > @@ -41,7 +42,6 @@ > test "xno" = "x$CHECK_CXX" || CHECK_CXX=yes > test "xno" = "x$CHECK_FC" || CHECK_FC=yes > > - > # Save these before calling AC_PROG_CC or AC_PROG_CXX > # because those macros will modify them, and we want > # the original user values, not the autoconf defaults. > @@ -54,10 +54,10 @@ > [WITH_MPI=$withval],[WITH_MPI=no] ) > case "x$WITH_MPI" in > xno) > - CC_LIST="cc gcc cl egcs pgcc" > - CXX_LIST="CC aCC cxx xlC_r xlC c++ g++ pgCC gpp cc++ cl FCC KCC > RCC" > - FC_LIST="gfortran ifort pgf90" > - F77_LIST="gfortran ifort pgf77" > + CC_LIST= > + CXX_LIST= > + FC_LIST= > + F77_LIST= > ;; > xyes) > CC_LIST="mpicc mpcc" > @@ -111,16 +111,32 @@ > esac > > if test "xno" != "x$CHECK_CC"; then > - AC_PROG_CC( [$CC_LIST] ) > + if test "x" = "x$CC_LIST"; then > + AC_PROG_CC > + else > + AC_PROG_CC( [$CC_LIST] ) > + fi > fi > AC_PROG_CPP > if test "xno" != "x$CHECK_CXX"; then > - AC_PROG_CXX( [$CXX_LIST] ) > + if test "x" = "x$CXX_LIST"; then > + AC_PROG_CXX

1 0

r3886 - cgm/trunk/m4
by kraftche＠cae.wisc.edu 12 May '10

12 May '10

Author: kraftche Date: 2010-05-12 12:53:11 -0500 (Wed, 12 May 2010) New Revision: 3886 Modified: cgm/trunk/m4/compiler.m4 Log: sync compiler configuration w/ MOAB Modified: cgm/trunk/m4/compiler.m4 =================================================================== --- cgm/trunk/m4/compiler.m4 2010-05-12 17:50:25 UTC (rev 3885) +++ cgm/trunk/m4/compiler.m4 2010-05-12 17:53:11 UTC (rev 3886) @@ -21,6 +21,7 @@ # CPP - The C preprocessor # CC - The C compiler # CXX - The C++ compiler +# FC - The Fortran compiler # CFLAGS - C compiler flags # CXXFLAGS - C++ compiler flags # WITH_MPI - 'yes' if parallel support, 'no' otherwise @@ -41,7 +42,6 @@ test "xno" = "x$CHECK_CXX" || CHECK_CXX=yes test "xno" = "x$CHECK_FC" || CHECK_FC=yes - # Save these before calling AC_PROG_CC or AC_PROG_CXX # because those macros will modify them, and we want # the original user values, not the autoconf defaults. @@ -54,10 +54,10 @@ [WITH_MPI=$withval],[WITH_MPI=no] ) case "x$WITH_MPI" in xno) - CC_LIST="cc gcc cl egcs pgcc" - CXX_LIST="CC aCC cxx xlC_r xlC c++ g++ pgCC gpp cc++ cl FCC KCC RCC" - FC_LIST="gfortran ifort pgf90" - F77_LIST="gfortran ifort pgf77" + CC_LIST= + CXX_LIST= + FC_LIST= + F77_LIST= ;; xyes) CC_LIST="mpicc mpcc" @@ -111,16 +111,32 @@ esac if test "xno" != "x$CHECK_CC"; then - AC_PROG_CC( [$CC_LIST] ) + if test "x" = "x$CC_LIST"; then + AC_PROG_CC + else + AC_PROG_CC( [$CC_LIST] ) + fi fi AC_PROG_CPP if test "xno" != "x$CHECK_CXX"; then - AC_PROG_CXX( [$CXX_LIST] ) + if test "x" = "x$CXX_LIST"; then + AC_PROG_CXX

1 0

Re: [cgma-dev] Writing STEP files from iGeom
by Jason Kraftcheck 12 May '10

12 May '10

Steve Jackson wrote: > I have an iGeom program that builds geometry "from scratch" (using > functions like createBrick and boolean opertions), then writes it out. > This program is only known to work with a CGM that's built against some > form of ACIS modeling engine. I was asked whether it could write a STEP > file, and these were the results. > > For CGM built with 64-bit ACIS or 64-bit Cubit: attempting to write a > .step file produces this message: "ERROR: The STEP translator is not > licensed for this installation". > > For CGM built with 32-bit Cubit: attempting to write a .step file makes > the program segfault in AcisQeuryEngine::export_solid_model() (inside > libcubiti19.so). The fault is a write through a null pointer; further > debugging info is unavailable. > > I don't have a bare copy of 32-bit ACIS to test. > > Are these known issues? ~S The segfault is troubling. AFAIK, we don't have a license for the STEP or IGES translators for ACIS, so it's no surprise that that didn't work. I think it was the case at the time of the cubit 10.2 release that ACIS did not support the translators on 64-bit linux. You might be able to get the build w/ 32-bit Cubit to work. Try setting whatever environmental variables the cubit script exports. -jason

1 0

Writing STEP files from iGeom
by Steve Jackson 12 May '10

12 May '10

I have an iGeom program that builds geometry "from scratch" (using functions like createBrick and boolean opertions), then writes it out. This program is only known to work with a CGM that's built against some form of ACIS modeling engine. I was asked whether it could write a STEP file, and these were the results. For CGM built with 64-bit ACIS or 64-bit Cubit: attempting to write a .step file produces this message: "ERROR: The STEP translator is not licensed for this installation". For CGM built with 32-bit Cubit: attempting to write a .step file makes the program segfault in AcisQeuryEngine::export_solid_model() (inside libcubiti19.so). The fault is a write through a null pointer; further debugging info is unavailable. I don't have a bare copy of 32-bit ACIS to test. Are these known issues? ~S

1 0

Re: [cgma-dev] Problem building CGM in shared mode
by James Porter 06 May '10

06 May '10

On Thu, 2010-05-06 at 17:51 -0500, Stuart Slattery wrote: > For my build I do not have it included in my $PATH as it only needs > the libraries. Instead, I include the cubit bin directory in my > $LD_LIBRARY_PATH and $LPATH environment variables. This is how I have my CGM shared build set up. I'm pretty certain that $LPATH is necessary for shared CGM to work. - Jim

1 0

Re: [cgma-dev] Problem building CGM in shared mode
by Rajeev Jain 06 May '10

06 May '10

I tried putting cubit-dir and cubit-bin-dir in my path in both cases it doesn't find the linker and comes with /usr/bin/ld: cannot find -lcubiti19 error in the make step. Since, cubit's bin directory is in the LD_LIBRARY_PATH the autotools should find the linker, but that doesn't happen.. Rajeev On 05/06/2010 05:31 PM, Tim Tautges wrote: > Doesn't it also have to be in your PATH? I seem to recall that... > > - tim > > Rajeev Jain wrote: >> On 05/06/2010 04:26 PM, Robert Smith wrote: >>> Is there some trick to getting CGM to build with --enable-shared? >>> This also has Cubit turned on. >>> >>> I tried running the configure as it is done on the buildbot server >>> and I continually get an error when it tries to link libcgm.la. It >>> says that '/bin/ld cannot find -lcubiti19'. That makes sense since >>> there is no -L switch to point to the Cubit install directory in the >>> link line although the libcubiti19.so file is included explicitly in >>> the libtool line. And the output of the make is slightly different >>> on my build than the buildbot build. >>> >>> Could this be a libtool mismatch? I'm on the ANL Linux cluster >>> running 1.5.26. >>> >>> --Bob >> Adding LDFLAGS=-L/home/rajeev/cubit-32/bin LIBS=-lcubiti19 to the >> configure script did the trick for cubit-32 using 32 bit >> ubuntu-10.04, This can be found at >> http://trac.mcs.anl.gov/projects/ITAPS/ticket/158 >> >> > -- Rajeev

1 0

Re: [cgma-dev] Problem building CGM in shared mode
by Stuart Slattery 06 May '10

06 May '10

For my build I do not have it included in my $PATH as it only needs the libraries. Instead, I include the cubit bin directory in my $LD_LIBRARY_PATH and $LPATH environment variables. Stuart On 05/06/10, Tim Tautges <tautges(a)mcs.anl.gov> wrote: > Doesn't it also have to be in your PATH? I seem to recall that... > > - tim > > Rajeev Jain wrote: > >On 05/06/2010 04:26 PM, Robert Smith wrote: > >>Is there some trick to getting CGM to build with --enable-shared? This also has Cubit turned on. > >> > >>I tried running the configure as it is done on the buildbot server and I continually get an error when it tries to link libcgm.la. It says that '/bin/ld cannot find -lcubiti19'. That makes sense since there is no -L switch to point to the Cubit install directory in the link line although the libcubiti19.so file is included explicitly in the libtool line. And the output of the make is slightly different on my build than the buildbot build. > >> > >>Could this be a libtool mismatch? I'm on the ANL Linux cluster running 1.5.26. > >> > >>--Bob > >Adding LDFLAGS=-L/home/rajeev/cubit-32/bin LIBS=-lcubiti19 to the configure script did the trick for cubit-32 using 32 bit ubuntu-10.04, This can be found at http://trac.mcs.anl.gov/projects/ITAPS/ticket/158 (http://trac.mcs.anl.gov/projects/ITAPS/ticket/158) > > > > > > -- > ================================================================ > "You will keep in perfect peace him whose mind is > steadfast, because he trusts in you." Isaiah 26:3 > > Tim Tautges Argonne National Laboratory > (tautges(a)mcs.anl.gov) (telecommuting from UW-Madison) > phone: (608) 263-8485 1500 Engineering Dr. > fax: (608) 263-4499 Madison, WI 53706 > > >

1 0