[petsc-dev] [Bitbucket] Pull request #375: Pass LDFLAGS down to GNUPackage externalpackages. (petsc/petsc)

[Dmitry Karpeyev]

Yeah, I think in the end Satish's fix is the right one: I will let HYPRE
(or any other GNUPackage) figure out what to do with LDFLAGS,
including whether they are safe, etc.  Should LDFLAGS be taken from
compilers or setCompilers?

On Mon, Oct 12, 2015 at 12:04 PM Satish Balay <balay at mcs.anl.gov> wrote:

> On Mon, 12 Oct 2015, Dmitry Karpeyev wrote:
>
> > On Mon, Oct 12, 2015 at 11:39 AM Satish Balay <balay at mcs.anl.gov> wrote:
> >
> > > On Mon, 12 Oct 2015, Barry Smith wrote:
> > >
> > > >
> > > > > On Oct 12, 2015, at 10:55 AM, Satish Balay <balay at mcs.anl.gov>
> wrote:
> > > > >
> > > > > On Mon, 12 Oct 2015, Barry Smith wrote:
> > > > >
> > > > >>
> > > > >>> On Oct 12, 2015, at 8:53 AM, Matthew Knepley <knepley at gmail.com>
> > > wrote:
> > > > >>>
> > > > >>> On Mon, Oct 12, 2015 at 8:45 AM, Dmitry Karpeyev <
> dkarpeev at gmail.com>
> > > wrote:
> > > > >>> How does one extract just LDFLAGS while building a GNUPackage
> object?
> > > > >>
> > > > >>   I cannot imagine in general this is what you want, because it
> will
> > > only work when the user provides the "correct" LDFLAGS and how are they
> > > suppose to know what the correct LDFLAGS are? I think you should pass
> in
> > > the "safe" part of getLinkerFlags(), that is the linker flags that are
> not
> > > compiler flags as I said in my previous email.
> > > > >
> > > > >
> > > > > I don't think we know what the 'safe LDFLAGS' are. As we don't know
> > > what each package does with LDFLAGS..
> > > >
> > > >    All the compiler flags are NOT safe. So we remove all the unsafe
> ones
> > > and hope for the best.
> > >
> > > I think Dmitry has to show us the use-case where he is having trouble.
> > >
> >
> > Quoting from an earlier email in this thread:
> > "Here's what prompted me to do this (I can't easily reproduce this [but
> the
> > MOOSE guys can]):
> > if one builds clang 3.7.0 from source with OpenMP support enabled
> > using the system clang from  the latest XCode on Yosemite or El Capitan,
> > then one can end up with a broken compiler.  Namely, clang cannot find
> > libomp. One workaround (a bad one, in my opinion) is to use an
> appropriate
> > DYLD_LIBRARY_PATH), but that doesn't always work, because it's not
> > inherited by child processes, etc.  Another approach (which is what I was
> > trying to do, is to set pass in appropriate LDFLAGS.  However, they need
> to
> > be passed down to all dependent packages, and HYPRE wasn't getting them.
> >
> > Now, one could argue that using a compiler broken in this way is the
> source
> > of all of these problems, but irrespective of this specific thing,
> passing
> > LDFLAGS down to all dependent packages seems like an innocent enough
> thing
> > to do, doesn't it?  In fact, it seems to be the consistent thing to do so
> > that everything is built using the same linker flags."
>
> OK - you want to pass in LDFLAGS option to petsc configure - and then
> would like this option passed in as LDFLAGS to hypre configure.
>
> The patch I posted would do this..
>
> Satish
>
> >
> > >
> > > PETSc configure currently has CFLAGS - and it passes them
> > > appropriately - and it works with all externalpackages. [as far as we
> > > know]
> > >
> > > We currently don't pass in LDFLAGS - but we can do that with the patch
> > > I mentioned.
> > >
> > > What you propose is to select some CFLAGS that are valid for linker -
> > > and pass them as LDFLAGS to externalpackages. I'm not convinced this
> > > is the correct thing to do.
> > >
> > > Satish
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20151012/043b3251/attachment.html>