Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

openSUSE installation issues

Help
2012-01-25
2013-04-22
  • Oliver Gloth
    Oliver Gloth
    2012-01-25

    Hello,

    I have severe problems installing BRL-CAD-7.20.4 on an openSUSE system. The rpm package gives the following error when starting mged:

    mged: symbol lookup error: mged: undefined symbol: ogl_interface
    

    When trying to compile the source I receive the following error:

    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c: In function ‘isect_2D_loop_ray.clone.2’:
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:625:57: error: array subscript is above array bounds
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:625:45: error: array subscript is above array bounds
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:625:69: error: array subscript is above array bounds
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:625:57: error: array subscript is above array bounds
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:625:45: error: array subscript is above array bounds
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:672:2: error: array subscript is above array bounds
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:674:2: error: array subscript is above array bounds
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:677:5: error: array subscript is above array bounds
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:624:8: error: ra[2] may be used uninitialized in this function
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:1623:15: note: ‘ra[2]’ was declared here
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:624:8: error: rb[2] may be used uninitialized in this function
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:1624:15: note: ‘rb[2]’ was declared here
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:624:8: error: center2d[2] may be used uninitialized in this function
    /nopt/brlcad-7.20.4/src/librt/primitives/extrude/extrude.c:1628:15: note: ‘center2d[2]’ was declared here
    make[2]: *** [src/librt/CMakeFiles/librt.dir/primitives/extrude/extrude.c.o] Error 1
    make[1]: *** [src/librt/CMakeFiles/librt.dir/all] Error 2
    make: *** [all] Error 2
    
     
  • Sean Morrison
    Sean Morrison
    2012-01-25

    ogloth,

    That build issue has been fixed in the latest sources of BRL-CAD (after 7.20.4).  To get past that issue now, you can either build from an svn checkout or re-run the cmake build configuration to disable strict mode compilation (cmake -DBRLCAD_ENABLE_STRICT=OFF or select it in ccmake gui).

    Cheers!
    Sean

     
  • Oliver Gloth
    Oliver Gloth
    2012-01-25

    Sean,

    that was quick - thanks!!

    Any idea about the rpm package issue??

    Cheers,
    Oliver

     
  • Jordi Sayol
    Jordi Sayol
    2012-01-25

    ogloth, on which opensuse version? 32 or 64-bit?

     
  • Sean Morrison
    Sean Morrison
    2012-01-25

    Oliver,

    Several ideas, but none terribly enlightening without more investigative searching.  My reluctant guess as to what is happening is that you have a libfb library somewhere else on your system that is conflicting with the rpm.  So when you run mged/archer, it's finding that other libfb where opengl was disabled and then ends up unable to resolve the opengl-enabled mged/archer that you're trying to run.  Money is on an LD_LIBRARY_PATH set, unset it and it just might work.

    Cheers!
    Sean

     
  • Oliver Gloth
    Oliver Gloth
    2012-01-25

    Sean - good bet!! I put the BRL-CAD libraries at the beginning of LD_LIBRARY_PATH and now it works. Let's wait and see which other software does not work any more … ;-)

    Thanks again!

     
  • Sean Morrison
    Sean Morrison
    2012-01-25

    Interesting, that's a pretty rare library naming conflict then.  There's a relatively young framebuffer library with that name, but never encountered them in the wild.  If you remove BRL-CAD's path from LD_LIBRARY_PATH and run "ldd /path/to/mged", it'll tell you which libfb it intends to use.  Could just as likely be another install of BRL-CAD somewhere on your system.

    So when can we expect to see a BRL-CAD <-> enGrid exporter/importer?  :-)

     
  • Oliver Gloth
    Oliver Gloth
    2012-01-25

    I'll do the test tomorrow when I am back in the office.

    There is a preliminary BRL-CAD import functionality in enGrid's master branch, but it is based on STL files - fairly ugly to be honest. Currently I am waiting for a contract signature and on the back of that project we will try to get a real interface to BRL-CAD - i.e. using BRL-CAD databases as geometry input. Do you know what is the state of the step-g tool? That will be an important utility to have in order to ensure compatibility with other CAD packages.

     
  • Sean Morrison
    Sean Morrison
    2012-01-25

    That's fantastic news.  Yeah, STL is not just a terrible format but relies on our ability to evaluate boolean mesh intersections robustly which is often not possible due to dirty input geometry or floating point drift or because it's Tuesday and our tessellation library is in a bad mood.  Working with the geometry in implicit CSG or BREP form is much more ideal.  When/If you work towards integrating more directly, join the dev list and we can walk through the process (pretty simple really).

    Currently, our bridge to FEA/CFD codes is via SNL's Cubit package, which isn't open source so it's an unsolved problem from my perspective.  I don't really want BRL-CAD to get into the meshing business any more than we need to, too.  I'd love to be able to say that if folks want an FEM from BRL-CAD geometry that they can just download and import into enGrid and get whatever mesh they want back.

    The step-g importer is coming along great.  We've got a few guys working on tasks directly and indirectly related to it from a few different angles.  Just today, support was added for importing assemblies.  Getting our STEP library cleanly ported  to Windows is almost complete as well with a lot of issues worked out along the way.  In a month or so, we should have the step-g importer going through regular regression testing where we'll start throwing more complex and varied inputs at it for robustness.

    Cheers!
    Sean