[overture] Re: trouble saving hard copies

  • From: Bill Henshaw <henshaw@xxxxxxxx>
  • To: "overture@xxxxxxxxxxxxx" <overture@xxxxxxxxxxxxx>
  • Date: Thu, 04 Nov 2010 16:40:45 -0700

Hi Yongsheng:
The current version of Overture does not use the LD_LIBRARY_PATH anymore. Instead it uses the "rpath" command on the load line. To get Overture programs like plotStuff
to find the Mesa libraries you will need to edit Overture/bin/Makefile.
I think if you add the rpath lines for Mesa:
     $(OV_RPATH)$(MOTIF_LIB) -L$(MOTIF_LIB)
to the start of the FLIBS variable: (around line 167 of Overture/bin/Makefile) FLIBS= $(OV_RPATH)$(MOTIF_LIB) -L$(MOTIF_LIB) $(OV_RPATH)$(Overture)/lib $(LDFLAGS)$(Overture)/lib $(LibOverture) $(OV_COMPILER_LIBS) $(HDF_LIBS) $(AppLibraries) $(FORTRAN_LIBS)

then hopefully it will find your Mesa libraries before the system OpenGL libs. You will need to remove Overture/bin/plotStuff and type make. Then do 'ldd plotStuff' to see
if it worked.

...Bill


Yongsheng Lian wrote:
Hi Bill,

I also suspected that since Mesa under my local directory is not included. I checked the configure.option and did find the Mesa was there. I tried to put Mesa in front of /usr/local/lib64 in the LD_LIBRARY_PATH in the .bashrc file. But it did not help. Is there a way that I can force the make to link to the local Mesa library instead of the system one?

Yongsheng


On Wed, Nov 3, 2010 at 6:20 PM, Bill Henshaw <henshaw@xxxxxxxx <mailto:henshaw@xxxxxxxx>> wrote:

    Hi Yongsheng,
       I guess the reason that you are getting seg faults when you try
    to save a hardcopy is that
    you are accidently linking to the system versions of OpenGL
    instead of your Mesa version:
            libGL.so.1 => /usr/local/lib64/libGL.so.1 (0x00002b177a64e000)
            libGLU.so.1 => /usr/local/lib64/libGLU.so.1
    (0x00002b177a9ff000)
    I guess that these are the system version of the libraries and not
    the Mesa version ??.
    When you change the hardcopy rendering to framebuffer then the
    hardcopy is taken from
    the hardware screen frame buffer (and thus is limited to the
    resolution of your screen) instead
    of rendering in memory.

    ...Bill


    Yongsheng Lian wrote:
    Bill,

      I soft of figure out a way to handle the problem.

      Using ldd the libraries used by plotStuff are the following.  I
    compared with the libraries used by the old working version and
    they are the same.

      A student showed me a trick to make the new version plotStuff
    work. Under "hardcopy"-->"rendering" change offScreen to
    frameBuffer. Not sure why but the trick works.

    Yongsheng

      ldd
    /home/2510/yslian/Overture.v23/Overture.v23New/Overture.v23g/bin/plotStuff
            libOverture.so =>
    
/home/2510/yslian/Overture.v23/Overture.v23New/Overture.v23g/lib/libOverture.so
    (0x00002b1775d9a000)
            libhdf5.so.0 =>
    /home/2510/yslian/Overture/hdf5-1.6.5-serial/hdf5-1.6.5/lib/libhdf5.so.0
    (0x00002b1778f71000)
            libjpeg.so.62 => /usr/lib64/libjpeg.so.62
    (0x00002b17791b6000)
            libz.so.1 => /lib64/libz.so.1 (0x00002b17792d7000)
            libApp.so =>
    /home/2510/yslian/Overture/A++P++-0.7.9d/A++/install/lib/libApp.so
    (0x00002b17793eb000)
            libgfortran.so.1 => /usr/lib64/libgfortran.so.1
    (0x00002b1779f10000)
            libperl.so =>
    /usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
    (0x00002b177a0a7000)
            libdl.so.2 => /lib64/libdl.so.2 (0x00002b177a2f9000)
            libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b177a3fe000)
            libpthread.so.0 => /lib64/libpthread.so.0
    (0x00002b177a537000)
            libGL.so.1 => /usr/local/lib64/libGL.so.1
    (0x00002b177a64e000)
            libGLU.so.1 => /usr/local/lib64/libGLU.so.1
    (0x00002b177a9ff000)
            libOSMesa.so.6 => /usr/local/lib64/libOSMesa.so.6
    (0x00002b177ab83000)
            libXm.so.3 => /usr/X11R6/lib64/libXm.so.3
    (0x00002b177ac8b000)
            libXpm.so.4 => /usr/X11R6/lib64/libXpm.so.4
    (0x00002b177b02c000)
            libXp.so.6 => /usr/X11R6/lib64/libXp.so.6
    (0x00002b177b13c000)
            libXt.so.6 => /usr/X11R6/lib64/libXt.so.6
    (0x00002b177b244000)
            libXmu.so.6 => /usr/X11R6/lib64/libXmu.so.6
    (0x00002b177b3a6000)
            libXi.so.6 => /usr/X11R6/lib64/libXi.so.6
    (0x00002b177b4be000)
            libXext.so.6 => /usr/X11R6/lib64/libXext.so.6
    (0x00002b177b5c6000)
            libX11.so.6 => /usr/X11R6/lib64/libX11.so.6
    (0x00002b177b6d8000)
            libm.so.6 => /lib64/libm.so.6 (0x00002b177b8e6000)
            libstdc++.so.6 => /usr/lib64/libstdc++.so.6
    (0x00002b177ba3b000)
            libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b177bc3a000)
            libc.so.6 => /lib64/libc.so.6 (0x00002b177bd47000)
            /lib64/ld-linux-x86-64.so.2 (0x00002b1775c7e000)
            libSM.so.6 => /usr/X11R6/lib64/libSM.so.6
    (0x00002b177bf79000)
            libICE.so.6 => /usr/X11R6/lib64/libICE.so.6
    (0x00002b177c083000)



    On Tue, Nov 2, 2010 at 12:48 PM, Bill Henshaw <henshaw@xxxxxxxx
    <mailto:henshaw@xxxxxxxx>> wrote:

        Hi,
          I doubt that you need a new version of Mesa. I am using
        Mesa-7.2 and it
        is probably not wise to use any version newer than that.

          I wonder if you can save a hardcopy at all ??  Also make
        sure you
        are not accidently linking to the system version of OpenGL --
        do an
        "ldd plotStuff" to see all the lib's you link to.

        ...Bill


        Yongsheng Lian wrote:
        Bill,

          Here is what I found using gdb. I thought the problem was
        caused by Mesa and tried to install the newest version of
        Mesa. As always, there are lots of dependency issues since
        we are using commercial SUSE from Noell. After many failed
        attempts this morning,  I will wait for a better solution.

        Thanks,
         Yongsheng

          Program received signal SIGSEGV, Segmentation fault.
        [Switching to Thread 47398938949808 (LWP 31453)]
        0x00002b1bec8c21df in memcpy () from /lib64/libc.so.6
        (gdb) bt
        #0  0x00002b1bec8c21df in memcpy () from /lib64/libc.so.6
        #1  0x00002b1bed640010 in ?? ()
        #2  0x00002b1be899162e in
        GL_GraphicsInterface::offScreenRenderMesa (this=0x5747c0,
            fileName=0x9efdb8 "movie0000.ppm", parameters=@0x81b828)
        at osRender.C:314
        #3  0x00002b1be8991c92 in
        GL_GraphicsInterface::offScreenRender (this=0x5747c0,
            fileName=0x9efdb8 "movie0000.ppm", parameters=@0x81b828)
        at osRender.C:28
        #4  0x00002b1be89131f5 in GL_GraphicsInterface::hardCopy
        (this=0x5747c0, fileName=@0x7fffc435cc10,
            parameters=@0x81b828, win_number=0) at
        GL_GraphicsInterface.C:2119
        #5  0x00002b1be89f2b95 in ShowFilePlotter::plot
        (this=0x7fffc435cd90) at ShowFilePlotter.C:1516
        #6  0x000000000040c6b4 in plotStuff (argc=2,
        argv=0x7fffc435d388) at plotStuffFunction.C:193
        #7  0x000000000040bef4 in main (argc=2, argv=0x7fffc435d388)
        at plotStuffDriver.C:37





        On Mon, Nov 1, 2010 at 6:43 PM, Bill Henshaw
        <henshaw@xxxxxxxx <mailto:henshaw@xxxxxxxx>> wrote:

            Hi Yongsheng,
             I am able to save movies from plotStuff and show files.
            Do you mean the version v23g I sent you?
            Can you make a simple example that fails and send it to me?

            Thanks,
             Bill

            Yongsheng Lian wrote:

                Hi Bill,

                 Not sure whether you have noticed  the save movie
                option in the new version (v23).  It crashes
                whenever we try to save a movie file. The previous
                version (v22) can save a movie file but is not
                compatible with the new version of showfile.

                Yongsheng








Other related posts: