- petsc-dev - mailman3.cels.anl.gov

postpone PETSc 2.3.1 release until the new year
by Barry Smith 15 Dec '05

15 Dec '05

I would like to postpone the PETSc 2.3.1 release until the new year. Barry Still too many problems with config/configure.py and incorrect/incomplete documentation.

1 0

vacation
by Barry Smith 15 Dec '05

15 Dec '05

I will be taking vacation from Wednesday December 21 until the new year. I will likely NOT be reading email during that time. Barry

1 0

Re: PIC
by Aron Ahmadia 14 Dec '05

14 Dec '05

Cool, please post the relevant python code when you're done, I'm interested

1 0

Re: PIC
by Matthew Knepley 14 Dec '05

14 Dec '05

Aron Ahmadia <aja2111(a)columbia.edu> writes: >> Because the "can I" is VERY erratic. I can build some shared libraries, but >> cannot build others. I do not understand the difference between these >> libraries >> at the moment, however I DO know that absence of the PIC option causes the >> error. > > Matt, I've used PIC before to sidestep errors associated with linking > libraries in the wrong order in the call to the linker. Have you ruled this > out as your problem for the non-PIC libraries? Yes, its a 64-bit problem where they REQUIRE PIC for shared libraries. We jsut need a workable model of library construction and use. I am talking it through with Satish. > And how the heck do you build shared libraries that aren't PIC? You can't. Matt -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0

Re: PIC
by Barry Smith 14 Dec '05

14 Dec '05

> This also succeeds, unless I misunderstand greatly the error. The libraries get built, fine. Now you generate the executable. That FAILS! As I have been saying all the time! It fails NOT because the library is not shared but because one cannot use that library WITH shared libraries! The new test is suppose to check that it can link and generate the executable, BUT not run the executable to see what message you get. The new test could be called checkCanBeUsedWithSharedLibrary() and it would shared almost all the code with checkShared() except actually running the executable and checking the result. Is it clear now, or am I still messed up? Barry On Wed, 14 Dec 2005, Matthew Knepley wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > > > On Wed, 14 Dec 2005, Matthew Knepley wrote: > > > >> Barry Smith <bsmith(a)mcs.anl.gov> writes: > >> > >> > Hmmm, why should you have a PIC test? Who cares if something > >> > has PIC or not? You only thing you care about is that you CAN > >> > do what you want to do with it? (In this case I think it is simply > >> > that you can build an executable using a shared library PLUS the > >> > given library you are testing.) > >> > > >> > Barry > >> > > >> > configure is suppose to be "can I ...?" not "is something ...?" > >> > >> Because the "can I" is VERY erratic. I can build some shared libraries, but > >> cannot build others. > > > > My understanding is that it can build a basic shared library (stand alone > > with a couple of symbols) BUT cannot build a shared library (and use it) in conjunction > > with the MPI libraries. So I fail to understand why you cannot just test this????? > > This is not my understanding. The checkShared() from MPI.py DOES EXACTLY build a shared > library (two in fact) linked to MPI. These succeed just fine. > > > Make a new test that is, exactly the FIRST part of the test > > > > def checkShared(self, inclu.... > > > > up to the code where > > > > if not checkLink(includes, body, cleanup = 0, codeBegin = codeBegin, codeEnd = codeEnd, shared = 1): > > if os.path.isfile(configObj.compilerObj): os.remove(configObj.compilerObj) > > self.setCompilers.LIBS = oldFlags > > raise RuntimeError('Could not complete shared library check\nCould not create a shared library using the currently configured shared linker.\nSuggest running with --with-shared=0 if you do not need shared libraries. Otherwise send configure.log to petsc-maint(a)mcs.anl.gov') > > > > but instead of throwing the silly exception you return 0 here. But if the link > > succeeds you continue the test until > > This does succeed. > > > ''' % (boolType, checkCode) > > if finiFunction: > > body += ' if (isInitialized) '+finiFunction+'();\n' > > body += ' return (int) isInitialized;\n' > > codeEnd = '\n}\n' > > if not checkLink(includes, body, cleanup = 0, codeBegin = codeBegin, codeEnd = codeEnd, shared = 1): > > if os.path.isfile(configObj.compilerObj): os.remove(configObj.compilerObj) > > self.setCompilers.LIBS = oldFlags > > raise RuntimeError('Could not complete shared library check\nCould not create a shared library using the currently configured shared linker.\nSuggest running with --with-shared=0 if you do not need shared libraries. Otherwise send configure.log to petsc-maint(a)mcs.anl.gov') > > return 0 > > > > here instead of the exception return 1 or 0 based on whether the link succeeds. > > Do not do the rest of the test. > > This also succeeds, unless I misunderstand greatly the error. > > Matt > > > I may be missing something but I don't understand why this has to be > > such a difficult thing. We know exactly where things go wrong (based on the log files) > > so we write a test specifically for that problem and report failure or success why > > make life more complicated. > > > > Barry > > > >>I do not understand the difference between these libraries > >> at the moment, however I DO know that absence of the PIC option causes the error. > >> Furthermore, checking this option allows a precise error message rather than a > >> guess. Lastly, this is in the configure spirit I believe, because we often test > >> the "what" of things, like endianness or the size of void *. > >> > >> Matt > >> > > > > > > > >

1 0

Re: PIC
by Aron Ahmadia 14 Dec '05

14 Dec '05

> Because the "can I" is VERY erratic. I can build some shared libraries, but > cannot build others. I do not understand the difference between these > libraries > at the moment, however I DO know that absence of the PIC option causes the > error. Matt, I've used PIC before to sidestep errors associated with linking libraries in the wrong order in the call to the linker. Have you ruled this out as your problem for the non-PIC libraries? And how the heck do you build shared libraries that aren't PIC? ~~A

1 0

Re: PIC
by Matthew Knepley 14 Dec '05

14 Dec '05

Barry Smith <bsmith(a)mcs.anl.gov> writes: > On Wed, 14 Dec 2005, Matthew Knepley wrote: > >> Barry Smith <bsmith(a)mcs.anl.gov> writes: >> >> > Hmmm, why should you have a PIC test? Who cares if something >> > has PIC or not? You only thing you care about is that you CAN >> > do what you want to do with it? (In this case I think it is simply >> > that you can build an executable using a shared library PLUS the >> > given library you are testing.) >> > >> > Barry >> > >> > configure is suppose to be "can I ...?" not "is something ...?" >> >> Because the "can I" is VERY erratic. I can build some shared libraries, but >> cannot build others. > > My understanding is that it can build a basic shared library (stand alone > with a couple of symbols) BUT cannot build a shared library (and use it) in conjunction > with the MPI libraries. So I fail to understand why you cannot just test this????? This is not my understanding. The checkShared() from MPI.py DOES EXACTLY build a shared library (two in fact) linked to MPI. These succeed just fine. > Make a new test that is, exactly the FIRST part of the test > > def checkShared(self, inclu.... > > up to the code where > > if not checkLink(includes, body, cleanup = 0, codeBegin = codeBegin, codeEnd = codeEnd, shared = 1): > if os.path.isfile(configObj.compilerObj): os.remove(configObj.compilerObj) > self.setCompilers.LIBS = oldFlags > raise RuntimeError('Could not complete shared library check\nCould not create a shared library using the currently configured shared linker.\nSuggest running with --with-shared=0 if you do not need shared libraries. Otherwise send configure.log to petsc-maint(a)mcs.anl.gov') > > but instead of throwing the silly exception you return 0 here. But if the link > succeeds you continue the test until This does succeed. > ''' % (boolType, checkCode) > if finiFunction: > body += ' if (isInitialized) '+finiFunction+'();\n' > body += ' return (int) isInitialized;\n' > codeEnd = '\n}\n' > if not checkLink(includes, body, cleanup = 0, codeBegin = codeBegin, codeEnd = codeEnd, shared = 1): > if os.path.isfile(configObj.compilerObj): os.remove(configObj.compilerObj) > self.setCompilers.LIBS = oldFlags > raise RuntimeError('Could not complete shared library check\nCould not create a shared library using the currently configured shared linker.\nSuggest running with --with-shared=0 if you do not need shared libraries. Otherwise send configure.log to petsc-maint(a)mcs.anl.gov') > return 0 > > here instead of the exception return 1 or 0 based on whether the link succeeds. > Do not do the rest of the test. This also succeeds, unless I misunderstand greatly the error. Matt > I may be missing something but I don't understand why this has to be > such a difficult thing. We know exactly where things go wrong (based on the log files) > so we write a test specifically for that problem and report failure or success why > make life more complicated. > > Barry > >>I do not understand the difference between these libraries >> at the moment, however I DO know that absence of the PIC option causes the error. >> Furthermore, checking this option allows a precise error message rather than a >> guess. Lastly, this is in the configure spirit I believe, because we often test >> the "what" of things, like endianness or the size of void *. >> >> Matt >> > > > -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0

Re: PIC
by Barry Smith 14 Dec '05

14 Dec '05

On Wed, 14 Dec 2005, Matthew Knepley wrote: > Barry Smith <bsmith(a)mcs.anl.gov> writes: > > > Hmmm, why should you have a PIC test? Who cares if something > > has PIC or not? You only thing you care about is that you CAN > > do what you want to do with it? (In this case I think it is simply > > that you can build an executable using a shared library PLUS the > > given library you are testing.) > > > > Barry > > > > configure is suppose to be "can I ...?" not "is something ...?" > > Because the "can I" is VERY erratic. I can build some shared libraries, but > cannot build others. My understanding is that it can build a basic shared library (stand alone with a couple of symbols) BUT cannot build a shared library (and use it) in conjunction with the MPI libraries. So I fail to understand why you cannot just test this????? Make a new test that is, exactly the FIRST part of the test def checkShared(self, inclu.... up to the code where if not checkLink(includes, body, cleanup = 0, codeBegin = codeBegin, codeEnd = codeEnd, shared = 1): if os.path.isfile(configObj.compilerObj): os.remove(configObj.compilerObj) self.setCompilers.LIBS = oldFlags raise RuntimeError('Could not complete shared library check\nCould not create a shared library using the currently configured shared linker.\nSuggest running with --with-shared=0 if you do not need shared libraries. Otherwise send configure.log to petsc-maint(a)mcs.anl.gov') but instead of throwing the silly exception you return 0 here. But if the link succeeds you continue the test until ''' % (boolType, checkCode) if finiFunction: body += ' if (isInitialized) '+finiFunction+'();\n' body += ' return (int) isInitialized;\n' codeEnd = '\n}\n' if not checkLink(includes, body, cleanup = 0, codeBegin = codeBegin, codeEnd = codeEnd, shared = 1): if os.path.isfile(configObj.compilerObj): os.remove(configObj.compilerObj) self.setCompilers.LIBS = oldFlags raise RuntimeError('Could not complete shared library check\nCould not create a shared library using the currently configured shared linker.\nSuggest running with --with-shared=0 if you do not need shared libraries. Otherwise send configure.log to petsc-maint(a)mcs.anl.gov') return 0 here instead of the exception return 1 or 0 based on whether the link succeeds. Do not do the rest of the test. I may be missing something but I don't understand why this has to be such a difficult thing. We know exactly where things go wrong (based on the log files) so we write a test specifically for that problem and report failure or success why make life more complicated. Barry >I do not understand the difference between these libraries > at the moment, however I DO know that absence of the PIC option causes the error. > Furthermore, checking this option allows a precise error message rather than a > guess. Lastly, this is in the configure spirit I believe, because we often test > the "what" of things, like endianness or the size of void *. > > Matt >

1 0

Re: PIC
by Matthew Knepley 14 Dec '05

14 Dec '05

Barry Smith <bsmith(a)mcs.anl.gov> writes: > Hmmm, why should you have a PIC test? Who cares if something > has PIC or not? You only thing you care about is that you CAN > do what you want to do with it? (In this case I think it is simply > that you can build an executable using a shared library PLUS the > given library you are testing.) > > Barry > > configure is suppose to be "can I ...?" not "is something ...?" Because the "can I" is VERY erratic. I can build some shared libraries, but cannot build others. I do not understand the difference between these libraries at the moment, however I DO know that absence of the PIC option causes the error. Furthermore, checking this option allows a precise error message rather than a guess. Lastly, this is in the configure spirit I believe, because we often test the "what" of things, like endianness or the size of void *. Matt -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0

Re: PIC
by Barry Smith 13 Dec '05

13 Dec '05

Hmmm, why should you have a PIC test? Who cares if something has PIC or not? You only thing you care about is that you CAN do what you want to do with it? (In this case I think it is simply that you can build an executable using a shared library PLUS the given library you are testing.) Barry configure is suppose to be "can I ...?" not "is something ...?" On Tue, 13 Dec 2005, Matthew Knepley wrote: > I have been on Google tonight, and still cannot find any information > about testing for PIC code. This has to be the worst compiler decision > ever, except maybe static/shared libraries. Anybody with test ideas? > > Matt >

1 0