ML symbols in petscksp.so
Satish Balay wrote: > I don't see any changes in the 'shared' target for linux [in conf/rules] > > And I just did a build with current petsc-dev - and see a bunch of ML_ symbols Thanks Satish. Wiping externalpackages and PETSC_ARCH was enough. It just didn't work when I only wiped the ML-related stuff and reconfigured. I'm not sure what I missed, but sorry for the confusion. Jed -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091028/18640393/attachment.pgp>
ML symbols in petscksp.so
Barry Smith wrote: > > We do do this for Mac (libpetsc*.dylib) and I think it mostly works. > But I am not aware of anyone doing this intentionally for PETSc on Linux > (though I think it is a good idea if it can be done). It has been working for more than a year on Linux. If you still have a --with-shared build from last week, run $ nm -D $PETSC_ARCH/lib/libpetscksp.so |grep ML_ # I have over 800 symbols I still have all the symbols from HYPRE, Sundials, MUMPS, etc. Only ML was broken in the last few days. > On Oct 28, 2009, at 4:27 PM, Matthew Knepley wrote: >> Wenever did this, and satill don't. We use -rpath, so that you can >> track back to the associated shared library, if it exists. Use of RPATH is orthogonal to this, --download-* builds static libs which get bundled into libpetsc*.so. Jed -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091028/f2f072b5/attachment.pgp>
ML symbols in petscksp.so
Matthew Knepley wrote: > You always have to link the ML library if you configure for ML, right? No, all the third party libs used to be put into the PETSc shared libs (but not the static libs). The easiest way to do this is with -Wl,--whole-archive though I haven't looked at the build system to see if this is how it is actually being done. All the others still behave this way, but ML is no longer included. So if you are using shared libs, you only need to link libpetsc*.so. This is recommended practice with shared libs, you only explicitly link the interface libraries (those that your code actually calls into) and let the linker handle the dependencies. Of course when using static libs, you need to explicitly link all the dependencies. Jed -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091028/1f60bc07/attachment.pgp>
remove 'x11' test from 'make test'
Looks like for 10.5 it is > defaults write org.x.X11 nolisten_tcp -boolean true On Oct 28, 2009, at 9:04 PM, Satish Balay wrote: > Perhaps the relavent setting can be toggled with: > > defaults com.apple.x11 nolisten_tcp -boolean true > > http://lists.apple.com/archives/x11-users/2005/May/msg00073.html > > Satish > > On Wed, 28 Oct 2009, Barry Smith wrote: > >> >> On my Mac >> >> bsmith-laptop:~/Src/petsc-dev] barrysmith% echo $DISPLAY >> /tmp/launch-r289TD/:0 >> >> I don't seem to have a problem with X when I change my IP address. >> I carry my >> laptop around open it and use X and it pretty much always works. >> >> Barry >> >> >> On Oct 28, 2009, at 8:02 PM, Satish Balay wrote: >> >>> On Wed, 28 Oct 2009, Boyana Norris wrote: >>> Apart from the idiot reasons, X11 tests can easily fail on an Apple laptop because the X server becomes unusable every time the IP changes, which is fairly frequently. I don't really use X a lot and thus do not restart the server every time I move the laptop, so these tests fail almost all the time (but I've learned to ignore those errors). >>> >>> Linux on laptops used to have this problem - but it doesn't exist >>> anymore. >>> >>> The reason is - x-server is now bound-to/listen-on a unix socket [: >>> 0] >>> - and not a tcp socket [localhost:0] - so hostname change doesn't >>> affect it. [from ps:] >>> >>> /usr/bin/Xorg :0 -nr -verbose -auth >>> /var/run/gdm/auth-for-gdm-l9vnzI/database -nolisten tcp >>> >>> Not sure how this can be done on mac/windows.. >>> >>> Satish >> >
ML symbols in petscksp.so
Something recently caused these symbols to get lost, meaning that users have to explicitly link the static libml.a. Jed -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091028/6d8e3fbb/attachment.pgp>
remove 'x11' test from 'make test'
Perhaps the relavent setting can be toggled with: defaults com.apple.x11 nolisten_tcp -boolean true http://lists.apple.com/archives/x11-users/2005/May/msg00073.html Satish On Wed, 28 Oct 2009, Barry Smith wrote: > > On my Mac > > bsmith-laptop:~/Src/petsc-dev] barrysmith% echo $DISPLAY > /tmp/launch-r289TD/:0 > > I don't seem to have a problem with X when I change my IP address. I carry my > laptop around open it and use X and it pretty much always works. > > Barry > > > On Oct 28, 2009, at 8:02 PM, Satish Balay wrote: > > > On Wed, 28 Oct 2009, Boyana Norris wrote: > > > > > Apart from the idiot reasons, X11 tests can easily fail on an Apple laptop > > > because the X server becomes unusable every time the IP changes, which is > > > fairly frequently. I don't really use X a lot and thus do not restart the > > > server every time I move the laptop, so these tests fail almost all the > > > time > > > (but I've learned to ignore those errors). > > > > Linux on laptops used to have this problem - but it doesn't exist anymore. > > > > The reason is - x-server is now bound-to/listen-on a unix socket [:0] > > - and not a tcp socket [localhost:0] - so hostname change doesn't > > affect it. [from ps:] > > > > /usr/bin/Xorg :0 -nr -verbose -auth > > /var/run/gdm/auth-for-gdm-l9vnzI/database -nolisten tcp > > > > Not sure how this can be done on mac/windows.. > > > > Satish >
remove 'x11' test from 'make test'
On my Mac bsmith-laptop:~/Src/petsc-dev] barrysmith% echo $DISPLAY /tmp/launch-r289TD/:0 I don't seem to have a problem with X when I change my IP address. I carry my laptop around open it and use X and it pretty much always works. Barry On Oct 28, 2009, at 8:02 PM, Satish Balay wrote: > On Wed, 28 Oct 2009, Boyana Norris wrote: > >> Apart from the idiot reasons, X11 tests can easily fail on an Apple >> laptop >> because the X server becomes unusable every time the IP changes, >> which is >> fairly frequently. I don't really use X a lot and thus do not >> restart the >> server every time I move the laptop, so these tests fail almost all >> the time >> (but I've learned to ignore those errors). > > Linux on laptops used to have this problem - but it doesn't exist > anymore. > > The reason is - x-server is now bound-to/listen-on a unix socket [:0] > - and not a tcp socket [localhost:0] - so hostname change doesn't > affect it. [from ps:] > > /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-l9vnzI/ > database -nolisten tcp > > Not sure how this can be done on mac/windows.. > > Satish
remove 'x11' test from 'make test'
On Wed, 28 Oct 2009, Boyana Norris wrote: > Apart from the idiot reasons, X11 tests can easily fail on an Apple laptop > because the X server becomes unusable every time the IP changes, which is > fairly frequently. I don't really use X a lot and thus do not restart the > server every time I move the laptop, so these tests fail almost all the time > (but I've learned to ignore those errors). Linux on laptops used to have this problem - but it doesn't exist anymore. The reason is - x-server is now bound-to/listen-on a unix socket [:0] - and not a tcp socket [localhost:0] - so hostname change doesn't affect it. [from ps:] /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-l9vnzI/database -nolisten tcp Not sure how this can be done on mac/windows.. Satish
remove 'x11' test from 'make test'
Apart from the idiot reasons, X11 tests can easily fail on an Apple laptop because the X server becomes unusable every time the IP changes, which is fairly frequently. I don't really use X a lot and thus do not restart the server every time I move the laptop, so these tests fail almost all the time (but I've learned to ignore those errors). Boyana -- Boyana Norris, Computer Scientist, Argonne National Laboratory norris at mcs.anl.gov, +1.630.252.7908, http://www.mcs.anl.gov/~norris/ On Oct 28, 2009, at 6:49 PM, Barry Smith wrote: > > On Oct 28, 2009, at 6:41 PM, Satish Balay wrote: > >> Barry, >> >> any objections to removing the 'x11' test from 'make test?' >> >> It fails for significant numer of installs [for users without working >> x11 etc..]. And the c/fortran/parallel tests should be the primary >> tests anyway.. > > The make rule for make tests only runs this test when ./configure > has found X11 and tested that it compiles and links properly. > > Thus it is not failing because of a failed X11 install. > > My understanding is that it ONLY fails because people don't have > the proper DISPLAY variable set. That is either > 1) DISPLAY does not exist or has garbage or > 2) DISPLAY points to a proper X server but because of permission > issues or firewalls the X client cannot connect to the X server. > > Does it fail for any other reason? > > I hate to pander to complete idiots who cannot set up their X > system properly; but I guess you can move that test to a new test > called > testx11 > > Barry > >> >> thanks, >> Satish >
remove 'x11' test from 'make test'
On Wed, 28 Oct 2009, Barry Smith wrote: > > On Oct 28, 2009, at 6:41 PM, Satish Balay wrote: > > > Barry, > > > > any objections to removing the 'x11' test from 'make test?' > > > > It fails for significant numer of installs [for users without working > > x11 etc..]. And the c/fortran/parallel tests should be the primary > > tests anyway.. > > The make rule for make tests only runs this test when ./configure has found > X11 and tested that it compiles and links properly. > > Thus it is not failing because of a failed X11 install. > > My understanding is that it ONLY fails because people don't have the proper > DISPLAY variable set. That is either > 1) DISPLAY does not exist or has garbage or > 2) DISPLAY points to a proper X server but because of permission issues or > firewalls the X client cannot connect to the X server. > > Does it fail for any other reason? Or one is not running a X server on their desktop [and installs on a remote linux box] > > I hate to pander to complete idiots who cannot set up their X system > properly; but I guess you can move that test to a new test called > testx11 I guess some users don't need or use X11 directly [esp on Mac?]. And with PETSc - its secondary usage anyway [We install with X11 , but its primarily useful to users at debugging stage - when debugging matrix assembly with -mat_view_draw etc..]. Hence my proposal to remove it from 'make test'. Will move it to 'testx11' thanks, satish
remove 'x11' test from 'make test'
On Oct 28, 2009, at 6:41 PM, Satish Balay wrote: > Barry, > > any objections to removing the 'x11' test from 'make test?' > > It fails for significant numer of installs [for users without working > x11 etc..]. And the c/fortran/parallel tests should be the primary > tests anyway.. The make rule for make tests only runs this test when ./configure has found X11 and tested that it compiles and links properly. Thus it is not failing because of a failed X11 install. My understanding is that it ONLY fails because people don't have the proper DISPLAY variable set. That is either 1) DISPLAY does not exist or has garbage or 2) DISPLAY points to a proper X server but because of permission issues or firewalls the X client cannot connect to the X server. Does it fail for any other reason? I hate to pander to complete idiots who cannot set up their X system properly; but I guess you can move that test to a new test called testx11 Barry > > thanks, > Satish
remove 'x11' test from 'make test'
Barry, any objections to removing the 'x11' test from 'make test?' It fails for significant numer of installs [for users without working x11 etc..]. And the c/fortran/parallel tests should be the primary tests anyway.. thanks, Satish
Move src/sys/viewerimpl.h to include/private ?
I don't think external projects should have to include <../src/whatever> because this doesn't work if PETSc is "installed" and it's a screwy API (even if most users don't see it). Any objections to this? Jed -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091028/3413f919/attachment.pgp>
ML symbols in petscksp.so
On Wed, 28 Oct 2009, Jed Brown wrote: > Barry Smith wrote: > > > > We do do this for Mac (libpetsc*.dylib) and I think it mostly works. > > But I am not aware of anyone doing this intentionally for PETSc on Linux > > (though I think it is a good idea if it can be done). > > It has been working for more than a year on Linux. If you still have a > --with-shared build from last week, run > > $ nm -D $PETSC_ARCH/lib/libpetscksp.so |grep ML_ # I have over 800 symbols > > I still have all the symbols from HYPRE, Sundials, MUMPS, etc. Only ML > was broken in the last few days. I don't see any changes in the 'shared' target for linux [in conf/rules] And I just did a build with current petsc-dev - and see a bunch of ML_ symbols > ./configure --with-mpi-dir=/home/petsc/soft/linux-Ubuntu_8.04-ia32/mpich2-1.0.8p1-gcc431 --download-ml=1 PETSC_ARCH=arch-linux-ml --with-shared=1 && make PETSC_ARCH=arch-linux-ml [petsc:petsc-dev/arch-linux-ml/lib] petsc> nm -Ao *.so | grep ML_ | grep ' T ' | wc -l 820 [petsc:petsc-dev/arch-linux-ml/lib] petsc> Satish
ML symbols in petscksp.so
On Oct 28, 2009, at 4:37 PM, Jed Brown wrote: > Barry Smith wrote: >> >> We do do this for Mac (libpetsc*.dylib) and I think it mostly works. >> But I am not aware of anyone doing this intentionally for PETSc on >> Linux >> (though I think it is a good idea if it can be done). > > It has been working for more than a year on Linux. If you still > have a > --with-shared build from last week, run > > $ nm -D $PETSC_ARCH/lib/libpetscksp.so |grep ML_ # I have over 800 > symbols > I never said it didn't work. I just said we didn't intentionally set it up this way. Since Matt and I are not aware of this feature than whoever did set it up (or you) have to figure out why it changed for ML. Also I said I like it. Barry > I still have all the symbols from HYPRE, Sundials, MUMPS, etc. Only > ML > was broken in the last few days. > >> On Oct 28, 2009, at 4:27 PM, Matthew Knepley wrote: >>> Wenever did this, and satill don't. We use -rpath, so that you can >>> track back to the associated shared library, if it exists. > > Use of RPATH is orthogonal to this, --download-* builds static libs > which get bundled into libpetsc*.so. > > Jed >
ML symbols in petscksp.so
We do do this for Mac (libpetsc*.dylib) and I think it mostly works. But I am not aware of anyone doing this intentionally for PETSc on Linux (though I think it is a good idea if it can be done). Bartry On Oct 28, 2009, at 4:27 PM, Matthew Knepley wrote: > On Wed, Oct 28, 2009 at 4:14 PM, Jed Brown wrote: > Matthew Knepley wrote: > > You always have to link the ML library if you configure for ML, > right? > > No, all the third party libs used to be put into the PETSc shared libs > (but not the static libs). The easiest way to do this is with > -Wl,--whole-archive though I haven't looked at the build system to see > if this is how it is actually being done. All the others still behave > this way, but ML is no longer included. > > Wenever did this, and satill don't. We use -rpath, so that you can > track back to > the associated shared library, if it exists. > > Matt > > So if you are using shared libs, you only need to link libpetsc*.so. > This is recommended practice with shared libs, you only explicitly > link > the interface libraries (those that your code actually calls into) and > let the linker handle the dependencies. Of course when using static > libs, you need to explicitly link all the dependencies. > > Jed > > > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which > their experiments lead. > -- Norbert Wiener
ML symbols in petscksp.so
On Wed, Oct 28, 2009 at 4:14 PM, Jed Brown wrote: > Matthew Knepley wrote: > > You always have to link the ML library if you configure for ML, right? > > No, all the third party libs used to be put into the PETSc shared libs > (but not the static libs). The easiest way to do this is with > -Wl,--whole-archive though I haven't looked at the build system to see > if this is how it is actually being done. All the others still behave > this way, but ML is no longer included. > Wenever did this, and satill don't. We use -rpath, so that you can track back to the associated shared library, if it exists. Matt > So if you are using shared libs, you only need to link libpetsc*.so. > This is recommended practice with shared libs, you only explicitly link > the interface libraries (those that your code actually calls into) and > let the linker handle the dependencies. Of course when using static > libs, you need to explicitly link all the dependencies. > > Jed > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091028/d42e85c7/attachment.html>
ML symbols in petscksp.so
You always have to link the ML library if you configure for ML, right? Matt On Wed, Oct 28, 2009 at 3:34 PM, Jed Brown wrote: > Something recently caused these symbols to get lost, meaning that users > have to explicitly link the static libml.a. > > Jed > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091028/12013374/attachment.html>
Move src/sys/viewerimpl.h to include/private ?
It can be moved over. Barry On Oct 28, 2009, at 12:32 PM, Jed Brown wrote: > I don't think external projects should have to include <../src/ > whatever> > because this doesn't work if PETSc is "installed" and it's a screwy > API > (even if most users don't see it). > > Any objections to this? > > > Jed >
Move src/sys/viewerimpl.h to include/private ?
Nope, get rid of it. Matt On Wed, Oct 28, 2009 at 12:32 PM, Jed Brown wrote: > I don't think external projects should have to include <../src/whatever> > because this doesn't work if PETSc is "installed" and it's a screwy API > (even if most users don't see it). > > Any objections to this? > > > Jed > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener -- next part -- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091028/e4957b27/attachment.html>
