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

[Dmitry Karpeyev]

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

>
> 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/d14582db/attachment.html>