Ok - I'll reverted the change now. Will see if the problem reappears. The primary reason it came up was due to compilers not returning error codes. [this issue is to be fixed differently - with an explicit compiler check]
The puzzling part for me is - why is this 'functionality' check done in checkdynamcilinker. And what does it actually mean on bgl/xt3 to have PetscDLOpen(). Satish On Sat, 10 Jul 2010, Barry Smith wrote: > > > On Jul 10, 2010, at 12:03 PM, Satish Balay wrote: > > > On Fri, 9 Jul 2010, Barry Smith wrote: > > > >> On Jul 9, 2010, at 6:58 PM, Satish Balay wrote: > >> > >>> I'm gussing its related to the checkDynamicLinker() change I pushed > >>> yesterday. But I don't understand the issue completely. [why is petsc > >>> looking for dlopen - when --with-dynamic is not used]. > >> > >> Someone a while ago asked for support to use dynamic libraries for other > >> stuff even if PETSc is not using dynamic libraries for itself. We've had > >> this support for a while now. In other words even if PETSc is not using > >> dynamic libraries configure should still do all the dynamic library > >> checking. > > > > I think we should have a configure flag to enable this part of the > > functonality [so there is some control on it - and not automatically > > do this.] > > > > The PetscDLOpen() etc part of PETSc works the same as other things in > PETSc. If ../configure detects certain things are available: in this case > LoadLibrary() and friends in Windows and dlopen() and friends in Unix then > PETSc is built to use them otherwise these things are not compiled in for > PETSc. So every thing should be honkey-dorry and "just work". > > Could you please explain exactly what goes wrong here (if ./configure > doesn't detect dlopen() fine, PETSc won't build with it, so not an error). Is > it that ./configure is buggy and crashes when doing checks when it shouldn't > crash? If so, then we should fix configure to not crash, only if it is not > fixable then we should provide an option to prevent the crashes. > > Barry > > > > Wrt the issue Glenn is seeing - I see configure was run on Jul-09 - > > but make was run on Jul-07. So rebuilding the libraries should fix the > > problem. > > > > configure.log:#define PETSC_VERSION_DATE_HG "Fri Jul 09 15:12:56 2010 -0500" > > make.log:#define PETSC_VERSION_DATE_HG "Wed Jul 07 15:57:21 2010 -0500" > > > > Satish > > > >> > >> Barry > >> > >>> > >>> Will check on this later. For now - perhaps you can comment out the > >>> following lines from config/BuildSystem/config/setCompilers.py > >>> > >>> + if not self.framework.argDB['with-dynamic']: > >>> + return > >>> > >>> Satish > >>> > >>> On Fri, 9 Jul 2010, Hammond, Glenn wrote: > >>> > >>>> PETSc, > >>>> > >>>> > >>>> When linking PFLOTRAN on Jaguar, I get the following error (same errors > >>>> with 'make test'. > >>>> > >>>> Suggestions? > >>>> > >>>> Thanks, > >>>> > >>>> Glenn > >>>> > >>>> /ccs/proj/geo002/petsc-dev/cray-xt4-pgi_fast/lib/libpetsc.a(dlimpl.o): > >>>> In function `PetscDLOpen': > >>>> ./dlimpl.c:57: undefined reference to `dlerror' > >>>> ./dlimpl.c:57: undefined reference to `dlopen' > >>>> ./dlimpl.c:128: undefined reference to `dlerror' > >>>> /ccs/proj/geo002/petsc-dev/cray-xt4-pgi_fast/lib/libpetsc.a(dlimpl.o): > >>>> In function `PetscDLClose': > >>>> ./dlimpl.c:153: undefined reference to `dlerror' > >>>> ./dlimpl.c:153: undefined reference to `dlclose' > >>>> ./dlimpl.c:199: undefined reference to `dlerror' > >>>> /ccs/proj/geo002/petsc-dev/cray-xt4-pgi_fast/lib/libpetsc.a(dlimpl.o): > >>>> In function `PetscDLSym': > >>>> ./dlimpl.c:231: undefined reference to `dlerror' > >>>> ./dlimpl.c:231: undefined reference to `dlsym' > >>>> ./dlimpl.c:231: undefined reference to `dlerror' > >>>> /usr/bin/ld.x: link errors found, deleting executable `pflotran' > >>>> cmake: *** [pflotran] Error 2 > >>>> > >>>> > >>> > >>> > >> > >> > >> > > > > > >
