PIC

[Barry Smith]

>   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 at mcs.anl.gov> writes:
> 
> > On Wed, 14 Dec 2005, Matthew Knepley wrote:
> >
> >> Barry Smith <bsmith at 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 at 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 at 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
> >> 
> >
> >
> >
> 
>