this fixed yet? I can test out a petsc-dev build on my MBP and see if I've got the same issues. ~A On Fri, May 2, 2008 at 2:21 PM, Barry Smith <[email protected]> wrote:

apple

On May 1, 2008, at 11:23 AM, Satish Balay wrote:

What machine is this?

...

Its been working forever for me on linux.

Satish

--------------------------------------------------- asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials>ls /home/balay/spetsc/asterix/lib/ foo libpetscdm.so libpetscmat.so libpetsc.so libpetscvec.so libpetsccontrib.so libpetscksp.so libpetscsnes.so libpetscts.so asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials>

<removed .a files>

asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials>ldd ex2 linux-gate.so.1 => (0x00110000) libpetscksp.so => /home/balay/spetsc/asterix/lib/libpetscksp.so (0x00111000) libpetscdm.so => /home/balay/spetsc/asterix/lib/libpetscdm.so (0x00374000) libpetscmat.so => /home/balay/spetsc/asterix/lib/libpetscmat.so (0x00493000) libpetscvec.so => /home/balay/spetsc/asterix/lib/libpetscvec.so (0x00838000) libpetsc.so => /home/balay/spetsc/asterix/lib/libpetsc.so (0x00a55000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00bf9000) liblapack.so.3 => /usr/lib/atlas/liblapack.so.3 (0x00cf5000) libblas.so.3 => /usr/lib/atlas/libblas.so.3 (0x02a29000) libm.so.6 => /lib/libm.so.6 (0x009a0000) libpthread.so.0 => /lib/libpthread.so.0 (0x009c9000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00a0e000) libgfortran.so.1 => /usr/lib/libgfortran.so.1 (0x0600e000) libc.so.6 => /lib/libc.so.6 (0x078a3000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x009e2000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x009e4000) libdl.so.2 => /lib/libdl.so.2 (0x00a00000) /lib/ld-linux.so.2 (0x00a38000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00a05000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00a08000) asterix:/home/balay/spetsc/src/ksp/ksp/examples/tutorials>gdb ex2 GNU gdb Red Hat Linux (6.6-45.fc8rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) b MatMult Function "MatMult" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (MatMult) pending. (gdb) r Starting program: /home/balay/hg-repo/petsc-dev/src/ksp/ksp/examples/tutorials/ex2 [Thread debugging using libthread_db enabled] Breakpoint 2 at 0x6250f3: file matrix.c, line 1690. Pending breakpoint "MatMult" resolved [New Thread -1208318272 (LWP 30748)] [Switching to Thread -1208318272 (LWP 30748)]

Breakpoint 2, MatMult (mat=0x9aabc58, x=0x9a9c888, y=0x9a9d698) at matrix.c:1690 1690 PetscFunctionBegin; Missing separate debuginfos, use: debuginfo-install atlas.i386 gcc.i386 glibc.i686 libX11.i386 libXau.i386 libXdmcp.i386 libxcb.i386 (gdb) list 1685 @*/ 1686 PetscErrorCode PETSCMAT_DLLEXPORT MatMult(Mat mat,Vec x,Vec y) 1687 { 1688 PetscErrorCode ierr; 1689 1690 PetscFunctionBegin; 1691 PetscValidHeaderSpecific(mat,MAT_COOKIE,1); 1692 PetscValidType(mat,1); 1693 PetscValidHeaderSpecific(x,VEC_COOKIE,2); 1694 PetscValidHeaderSpecific(y,VEC_COOKIE,3); (gdb)

On Thu, 1 May 2008, Barry Smith wrote:

...

It seems to now be impossible to debug in code that uses PETSc shared libraries

fi; \ if [ "$$flag" != "" ]; then \ echo "building $$LIBNAME.${SL_LINKER_SUFFIX}"; \ ${RM} -f ${INSTALL_LIB_DIR}/tmp-petsc-shlib/*; \ cd ${INSTALL_LIB_DIR}/tmp-petsc-shlib; \ ${AR} x ${INSTALL_LIB_DIR}/$$LIBNAME.${AR_LIB_SUFFIX}; \ cd $$cwd;\ ${OMAKE} LIBNAME=$$LIBNAME SHARED_LIBRARY_TMPDIR=${INSTALL_LIB_DIR}/tmp-petsc-shlib shared_arch; \ fi; \ fi; \ done; \ ${RM} -rf ${INSTALL_LIB_DIR}/tmp-petsc-shlib; \ fi

In the debugger, of course, one gets warning: Could not find object file "/Users/bsmith/Src/petsc-dev-for-fixes/shit/lib/tmp-petsc-shlib/bvec2.o" - no debug information available for "bvec2.c".

since the .o files are removed the debugger cannot find any debug information.

Is this intentional? Seems pretty terrible to give up debugging just to use shared libraries.

Barry