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

[Barry Smith]

> On Oct 12, 2015, at 11:58 AM, Dmitry Karpeyev <dkarpeev at gmail.com> 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.


   Please send us the configure.log for such a failure.

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

   No, clearly it was not so innocent since the nightlys have been broken now for several nights.


>  In fact, it seems to be the consistent thing to do so that everything is built using the same linker flags." 
> 
> 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.

  Ok, pass down the LDFLAGS but ONLY if the user provided LDFLAGS otherwise we should not be passing in a LDFLAGS="'" to the sub packages

  Barry

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