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

[Satish Balay]

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
> >
>