error in handling download external packages
After we have compiled the external package libraries we copy them over to the install site, ok. But we also blindly copy over ALL of its include files over to the install site so that the PETSc interface for that package can be built. But then we leave all those includes there even though they are not needed by the user of the installed PETSc. Possible correction: put those includes in another directory that is used for building PETSc but not used when compiling user code. Somehow need to pass the appropriate -I only when building PETSc and not for user code. Barry Even when we do not install the package, that is we use one someone already installed, we point to its include files in our makefile system and continue to point to them (with -I stuff) when users build code.
who updated the MUMPS package in petsc-dev
It seems to be severely broken Warning: Label 887 at (1) defined but not used smumps_load.F:2311.4: 049 CONTINUE 1 Warning: Label 49 at (1) defined but not used smumps_load.F:1922.4: 666 CONTINUE 1 Warning: Label 666 at (1) defined but not used smumps_ooc.F:201.29: OOC_VADDR=>id%OOC_VADDR 1 Error: 'ooc_vaddr' at (1) is not a member of the 'smumps_struc' structure smumps_ooc.F:219.30: ALLOCATE(id%OOC_NB_FILES(OOC_NB_FILE_TYPE), stat=allocok) 1 Error: Syntax error in ALLOCATE statement at (1) smumps_ooc.F:537.12: id%OOC_TOTAL_NB_NODES(I)=I_CUR_HBUF_NEXTPOS(I)-1 1 Error: Unclassifiable statement at (1) smumps_ooc.F:569.34: DO I=1,id%OOC_NB_FILES(I1) 1 Error: Syntax error in DO statement at (1) smumps_ooc.F:583.12: ENDDO 1 Error: Expecting END IF statement at (1) smumps_ooc.F:618.32: Why won't it build for me? I am using gfortran. Has this been tested? Could this issue please be resolved. Barry
who updated the MUMPS package in petsc-dev
Works for me. Satish -- [petsc:externalpackages/MUMPS_4.8.3/src] petsc> rm smumps_load.o smumps_ooc.o rm: remove regular file `smumps_load.o'? y rm: remove regular file `smumps_ooc.o'? y [petsc:externalpackages/MUMPS_4.8.3/src] petsc> make smumps_load.o smumps_ooc.o /sandbox/petsc/petsc-dev/linux-mumps/bin/mpif90 -g -fPIC -fPIC -g -I/sandbox/petsc/petsc-dev/linux-mumps/include -Dmetis -Dpord -I. -I../include -c smumps_load.F /sandbox/petsc/petsc-dev/linux-mumps/bin/mpif90 -g -fPIC -fPIC -g -I/sandbox/petsc/petsc-dev/linux-mumps/include -Dmetis -Dpord -I. -I../include -c smumps_ooc.F [petsc:externalpackages/MUMPS_4.8.3/src] petsc> /sandbox/petsc/petsc-dev/linux-mumps/bin/mpif90 -show gfortran -g -fPIC -fPIC -g -I/sandbox/petsc/petsc-dev/linux-mumps/include -I/sandbox/petsc/petsc-dev/linux-mumps/include -L/sandbox/petsc/petsc-dev/linux-mumps/lib -lmpichf90 -Wl,-rpath -Wl,/sandbox/petsc/petsc-dev/linux-mumps/lib -lmpichf90 -lmpich -lpthread -lrt [petsc:externalpackages/MUMPS_4.8.3/src] petsc> gfortran -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) [petsc:externalpackages/MUMPS_4.8.3/src] petsc> - On Wed, 22 Oct 2008, Barry Smith wrote: > > > It seems to be severely broken > > Warning: Label 887 at (1) defined but not used > smumps_load.F:2311.4: > > 049 CONTINUE > 1 > Warning: Label 49 at (1) defined but not used > smumps_load.F:1922.4: > > 666 CONTINUE > 1 > Warning: Label 666 at (1) defined but not used > smumps_ooc.F:201.29: > > OOC_VADDR=>id%OOC_VADDR >1 > Error: 'ooc_vaddr' at (1) is not a member of the 'smumps_struc' structure > smumps_ooc.F:219.30: > > ALLOCATE(id%OOC_NB_FILES(OOC_NB_FILE_TYPE), stat=allocok) > 1 > Error: Syntax error in ALLOCATE statement at (1) > smumps_ooc.F:537.12: > >id%OOC_TOTAL_NB_NODES(I)=I_CUR_HBUF_NEXTPOS(I)-1 > 1 > Error: Unclassifiable statement at (1) > smumps_ooc.F:569.34: > >DO I=1,id%OOC_NB_FILES(I1) > 1 > Error: Syntax error in DO statement at (1) > smumps_ooc.F:583.12: > > ENDDO > 1 > Error: Expecting END IF statement at (1) > smumps_ooc.F:618.32: > > > Why won't it build for me? I am using gfortran. Has this been tested? > Could this issue please be resolved. > > Barry > >
who updated the MUMPS package in petsc-dev
Barry, smumps_* are in single precision of mumps, which I've never tested it. I'll check it later, Hong On Wed, 22 Oct 2008, Barry Smith wrote: > > > It seems to be severely broken > > Warning: Label 887 at (1) defined but not used > smumps_load.F:2311.4: > > 049 CONTINUE > 1 > Warning: Label 49 at (1) defined but not used > smumps_load.F:1922.4: > > 666 CONTINUE > 1 > Warning: Label 666 at (1) defined but not used > smumps_ooc.F:201.29: > > OOC_VADDR=>id%OOC_VADDR > 1 > Error: 'ooc_vaddr' at (1) is not a member of the 'smumps_struc' structure > smumps_ooc.F:219.30: > > ALLOCATE(id%OOC_NB_FILES(OOC_NB_FILE_TYPE), stat=allocok) >1 > Error: Syntax error in ALLOCATE statement at (1) > smumps_ooc.F:537.12: > > id%OOC_TOTAL_NB_NODES(I)=I_CUR_HBUF_NEXTPOS(I)-1 > 1 > Error: Unclassifiable statement at (1) > smumps_ooc.F:569.34: > > DO I=1,id%OOC_NB_FILES(I1) >1 > Error: Syntax error in DO statement at (1) > smumps_ooc.F:583.12: > >ENDDO > 1 > Error: Expecting END IF statement at (1) > smumps_ooc.F:618.32: > > > Why won't it build for me? I am using gfortran. Has this been tested? > Could this issue please be resolved. > > Barry > >
who updated the MUMPS package in petsc-dev
Barry, Can you do 'rm -rf PETSC_ARCH externalpackages' and retry? [also make sure to pull BuildSystem] Satish On Wed, 22 Oct 2008, Satish Balay wrote: > Works for me.
who updated the MUMPS package in petsc-dev
Already tried this, but I'll try again Barry On Oct 22, 2008, at 9:59 AM, Satish Balay wrote: > Barry, > > Can you do 'rm -rf PETSC_ARCH externalpackages' and retry? > > [also make sure to pull BuildSystem] > > Satish > > On Wed, 22 Oct 2008, Satish Balay wrote: > >> Works for me. >
who updated the MUMPS package in petsc-dev
I'm not trying to use smumps; I just asked config/configure.py to download mumps and build it in the usual way. Barry On Oct 22, 2008, at 9:48 AM, Hong Zhang wrote: > Barry, > > smumps_* are in single precision of mumps, which I've never tested it. > I'll check it later, > > Hong > > On Wed, 22 Oct 2008, Barry Smith wrote: > >> >> >> It seems to be severely broken >> >> Warning: Label 887 at (1) defined but not used >> smumps_load.F:2311.4: >> >> 049 CONTINUE >> 1 >> Warning: Label 49 at (1) defined but not used >> smumps_load.F:1922.4: >> >> 666 CONTINUE >> 1 >> Warning: Label 666 at (1) defined but not used >> smumps_ooc.F:201.29: >> >>OOC_VADDR=>id%OOC_VADDR >> 1 >> Error: 'ooc_vaddr' at (1) is not a member of the 'smumps_struc' >> structure >> smumps_ooc.F:219.30: >> >>ALLOCATE(id%OOC_NB_FILES(OOC_NB_FILE_TYPE), stat=allocok) >> 1 >> Error: Syntax error in ALLOCATE statement at (1) >> smumps_ooc.F:537.12: >> >> id%OOC_TOTAL_NB_NODES(I)=I_CUR_HBUF_NEXTPOS(I)-1 >> 1 >> Error: Unclassifiable statement at (1) >> smumps_ooc.F:569.34: >> >> DO I=1,id%OOC_NB_FILES(I1) >> 1 >> Error: Syntax error in DO statement at (1) >> smumps_ooc.F:583.12: >> >> ENDDO >> 1 >> Error: Expecting END IF statement at (1) >> smumps_ooc.F:618.32: >> >> >> Why won't it build for me? I am using gfortran. Has this been tested? >> Could this issue please be resolved. >> >> Barry >> >> >
who updated the MUMPS package in petsc-dev
Which version of gfortran? I can try to reproduce.. Satish On Wed, 22 Oct 2008, Barry Smith wrote: > > Already tried this, but I'll try again > > Barry > > On Oct 22, 2008, at 9:59 AM, Satish Balay wrote: > > > Barry, > > > > Can you do 'rm -rf PETSC_ARCH externalpackages' and retry? > > > > [also make sure to pull BuildSystem] > > > > Satish > > > > On Wed, 22 Oct 2008, Satish Balay wrote: > > > > > Works for me. > > > >
who updated the MUMPS package in petsc-dev
Satish, You where correct. Removing the stuff in arch/include/*mumps* solved the problem. Hmm, removing the externalpackages/directory should be enough, I wonder why. Barry On Oct 22, 2008, at 10:34 AM, Barry Smith wrote: > > Already tried this, but I'll try again > > Barry > > On Oct 22, 2008, at 9:59 AM, Satish Balay wrote: > >> Barry, >> >> Can you do 'rm -rf PETSC_ARCH externalpackages' and retry? >> >> [also make sure to pull BuildSystem] >> >> Satish >> >> On Wed, 22 Oct 2008, Satish Balay wrote: >> >>> Works for me. >> >
error in handling download external packages
For one - I think each external package should have its own 'make install' - this should copy its public include files to the prefix location. [currently we do 'cp' for some packages - and this might copy both internal and public include files to the install location]. The current model is to have the same 'prefix' provided to PETSc be the prefix for all external packages. Placing package includes in a separate location breaks this mode. [and then we have to figure out which packages user will include via petsc include - like mpi.h etc, and ones that are not directly included - perhaps like mumps.h] So I don't see the benefit [except for reduced number of files in prefix/include] by hiding the includes in a different location - and complicating the install model. The current model benifits users in the sense that - if they were to have some usercode that uses externalpackages directly aswell - then they can rely on PETSc install of these packages.. Satish Satish On Wed, 22 Oct 2008, Barry Smith wrote: > > After we have compiled the external package libraries we copy them over to > the install site, ok. > But we also blindly copy over ALL of its include files over to the install > site so that the PETSc interface > for that package can be built. But then we leave all those includes there even > though they are not > needed by the user of the installed PETSc. > > Possible correction: put those includes in another directory that is used for > building PETSc but not used > when compiling user code. Somehow need to pass the appropriate -I only when > building PETSc > and not for user code. > > Barry > > Even when we do not install the package, that is we use one someone already > installed, we point > to its include files in our makefile system and continue to point to them > (with -I stuff) when users > build code. >
who updated the MUMPS package in petsc-dev
On Wed, 22 Oct 2008, Barry Smith wrote: > > Satish, > > You where correct. Removing the stuff in arch/include/*mumps* solved the > problem. > Hmm, removing the externalpackages/directory should be enough, I wonder why. Because of the presence of includes from previous version of mumps in PETSC_ARCH/include. [This -Iarch/include is passed in to mumps build as a depencency for other dependent package - perhaps MPI dependency] Satish
error in handling download external packages
On Oct 22, 2008, at 10:55 AM, Satish Balay wrote: > For one - I think each external package should have its own 'make > install' - this should copy its public include files to the prefix > location. [currently we do 'cp' for some packages - and this might > copy both internal and public include files to the install location]. We should only doing the cp/mv for packages that do not have their own proper make install. (I don't know if we use it when we should not anywhere). We should try to improve this and eliminate at least some of the private include files from getting over. > > > The current model is to have the same 'prefix' provided to PETSc be > the prefix for all external packages. We should probably have support for using a different prefix for all of the externals, this wouldn't be hard to do. (but use the same by default). Of course, this doesn't really solve the problem anyways since we would still have to point to this other directory when compiling user code because of the mpi.h as you point out. > Placing package includes in a > separate location breaks this mode. [and then we have to figure out > which packages user will include via petsc include - like mpi.h etc, > and ones that are not directly included - perhaps like mumps.h] > > So I don't see the benefit [except for reduced number of files in > prefix/include] by hiding the includes in a different location - and > complicating the install model. > > The current model benifits users in the sense that - if they were to > have some usercode that uses externalpackages directly aswell - then > they can rely on PETSc install of these packages.. This is true. I wasn't saying we had to solve this problem, but I do think it is a problem. A users code could easily pick up the wrong include for something since we now have hundreds in our arch/include location. > > > Satish > > Satish On Wed, 22 Oct 2008, Barry Smith wrote: > >> >> After we have compiled the external package libraries we copy them >> over to >> the install site, ok. >> But we also blindly copy over ALL of its include files over to the >> install >> site so that the PETSc interface >> for that package can be built. But then we leave all those includes >> there even >> though they are not >> needed by the user of the installed PETSc. >> >> Possible correction: put those includes in another directory that >> is used for >> building PETSc but not used >> when compiling user code. Somehow need to pass the appropriate -I >> only when >> building PETSc >> and not for user code. >> >> Barry >> >> Even when we do not install the package, that is we use one someone >> already >> installed, we point >> to its include files in our makefile system and continue to point >> to them >> (with -I stuff) when users >> build code. >> >
error in handling download external packages
On Wed, 22 Oct 2008, Barry Smith wrote: > I wasn't saying we had to solve this problem, but I do think it > is a problem. A users code could easily pick up the wrong include > for something since we now have hundreds in our arch/include location. I guess part of the problem is namespace issue [This would be the primary reason for picking up the wrong include]. In that sense include/packagename/pkginc.h might be a valid thing. But the package has to support this internally [as in 'make install' provides include/pkgname/pkginclude'. And the recommended usage from user code would be: #inlcude "package/pkginc.h" [this model is not in sync with curent PETSc model of supporing both install in PETSC_DIR-src and 'make install with prefix']. It might be better to identify the namespace conflicts and ask the packages to fix the names.. The other kind of conflict is: user installs superlu separately - and then tries to use PETSc installed with --download-superlu. These 2 versions of superlu will conflict with each other.. The fix in this case is to not use the duplicate install of superlu anyway... Satish
who updated the MUMPS package in petsc-dev
This is what got my rant started on sticking package includes in there :-( Barry On Oct 22, 2008, at 10:59 AM, Satish Balay wrote: > On Wed, 22 Oct 2008, Barry Smith wrote: > >> >> Satish, >> >> You where correct. Removing the stuff in arch/include/*mumps* >> solved the >> problem. >> Hmm, removing the externalpackages/directory should be enough, I >> wonder why. > > Because of the presence of includes from previous version of mumps in > PETSC_ARCH/include. [This -Iarch/include is passed in to mumps build > as a depencency for other dependent package - perhaps MPI dependency] > > Satish >
who updated the MUMPS package in petsc-dev
On Wed, 22 Oct 2008, Barry Smith wrote: > This is what got my rant started on sticking package includes in there :-( moving includes to a sub-dir will help slightly with 'external package' upgrades - but not completely. - For one - some old files could still lay arround [causing problems during PETSc build - but not package build] - the current f arch/conf/packagename test [to rebuilding of a package] wont't work. [ it checks only compiler options - not the package version]. Ideally we should have a better check on when to invoke a 'recompile/install' on the external packages. [maybe also stash externaldir name? - or some md5checksum if the sources change - but not the dirname?] etc.. And before this recompile is done - we should do a proper 'uninstall' of the package. We have an uninstall script for 'prefix' install of PETSc libraries. Perhaps we can somehow extend this to do a proper 'package-uninstall' for individual externalpackages.. [to be used during this externalpackage-reinstall step] Satish
error in handling download external packages
I have a problem with hiding the package includes. If I tell PETSc to install ParMetis, I think I should be able to use ParMetis however I want. I do not just want to use it through the PETSc interface. I have done this numerous times. I think most users think this way as well. What is the motivation for hiding the includes? Thanks, Matt On Wed, Oct 22, 2008 at 11:18 AM, Satish Balay wrote: > On Wed, 22 Oct 2008, Barry Smith wrote: > >> I wasn't saying we had to solve this problem, but I do think it >> is a problem. A users code could easily pick up the wrong include >> for something since we now have hundreds in our arch/include location. > > I guess part of the problem is namespace issue [This would be the > primary reason for picking up the wrong include]. In that sense > include/packagename/pkginc.h might be a valid thing. But the package > has to support this internally [as in 'make install' provides > include/pkgname/pkginclude'. And the recommended usage from user code > would be: > > #inlcude "package/pkginc.h" > > [this model is not in sync with curent PETSc model of supporing both > install in PETSC_DIR-src and 'make install with prefix']. It might be > better to identify the namespace conflicts and ask the packages to fix > the names.. > > The other kind of conflict is: user installs superlu separately - and > then tries to use PETSc installed with --download-superlu. These 2 > versions of superlu will conflict with each other.. The fix in this > case is to not use the duplicate install of superlu anyway... > > Satish > > -- 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
who updated the MUMPS package in petsc-dev
On Wed 2008-10-22 11:34, Satish Balay wrote:
> On Wed, 22 Oct 2008, Barry Smith wrote:
>
> > This is what got my rant started on sticking package includes in there :-(
>
> moving includes to a sub-dir will help slightly with 'external
> package' upgrades - but not completely.
The MPI wrappers should find `mpi.h' and if you installed an MPI then
wouldn't you be using the wrappers? If you're not using wrappers then
certainly that -I needs to be there. For other headers, it doesn't seem
like too much to ask a user who uses an external package directly to add
their own -I flag.
> And before this recompile is done - we should do a proper 'uninstall'
> of the package. We have an uninstall script for 'prefix' install of
> PETSc libraries. Perhaps we can somehow extend this to do a proper
> 'package-uninstall' for individual externalpackages.. [to be used
> during this externalpackage-reinstall step]
Beware of Hypre's make uninstall which is rm -rf $prefix/{lib,include}!
Some packages install lots of un-namespaced headers (fortran.h,
timing.h, misc.h, matrix.h, qr.h -- SPAI and Hypre seem to be the big
offenders here) so the uninstall would have to be somewhat manual and
re-tuned for new releases, but getting reconfigure to work properly
through package upgrades is worthwhile. I also think it's good to get
these headers out of the user's default namespace.
Jed
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20081022/846854dc/attachment.pgp>
error in handling download external packages
On Oct 22, 2008, at 12:16 PM, Matthew Knepley wrote: > I have a problem with hiding the package includes. If I tell PETSc > to install > ParMetis, I think I should be able to use ParMetis however I want. I > do not > just want to use it through the PETSc interface. I have done this > numerous > times. I think most users think this way as well. What is the > motivation for > hiding the includes? Per our previous decisions, not hiding the includes, but having an option of putting all their includes in a different place then the PETSc include directory. Now if they have PETSc install ParMetis the includes are ALWAYS put in the same place as the PETSc ones. Barry So someone use the ParMetis, but not using PETSc needs to have a -I/somewhere/petsc-install-location/include instead of a -I/somehere/parmetis-install-location/include > > > Thanks, > >Matt > > On Wed, Oct 22, 2008 at 11:18 AM, Satish Balay > wrote: >> On Wed, 22 Oct 2008, Barry Smith wrote: >> >>> I wasn't saying we had to solve this problem, but I do think it >>> is a problem. A users code could easily pick up the wrong include >>> for something since we now have hundreds in our arch/include >>> location. >> >> I guess part of the problem is namespace issue [This would be the >> primary reason for picking up the wrong include]. In that sense >> include/packagename/pkginc.h might be a valid thing. But the package >> has to support this internally [as in 'make install' provides >> include/pkgname/pkginclude'. And the recommended usage from user code >> would be: >> >> #inlcude "package/pkginc.h" >> >> [this model is not in sync with curent PETSc model of supporing both >> install in PETSC_DIR-src and 'make install with prefix']. It might be >> better to identify the namespace conflicts and ask the packages to >> fix >> the names.. >> >> The other kind of conflict is: user installs superlu separately - and >> then tries to use PETSc installed with --download-superlu. These 2 >> versions of superlu will conflict with each other.. The fix in this >> case is to not use the duplicate install of superlu anyway... >> >> Satish >> >> > > > > -- > 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 >
