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

[Matthew Knepley]

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?
>
> What are you trying to do?

setCompilers.LDFLAGS or compilers.LDFLAGS is available. However, Toby has
just
merged his parallel configure branch into 'next' which has rules for
accessing these
variables since we want to be threadsafe. You use the 'with' operator.

  Thanks,

     Matt

> Dmitry
>
> On Mon, Oct 12, 2015, 08:43 Matthew Knepley <knepley at gmail.com> wrote:
>
>> On Sun, Oct 11, 2015 at 12:38 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>>
>>> not sure about autoconf  - but we do:
>>>
>>> c-compile-only: CPPFLAGS CFLAGS COPTFLAGS
>>> clinker:      LDFLAGS? CFLAGS COPTFLAGS () LIB
>>>
>>> Perhaps configure should somehow preserve LDFLAGS option to configure
>>> - and make it accessiable to package.py somehow.
>>
>>
>> Compile-only flags go in CPPFLAGS. Flags for both the compiler and linker
>> go in CFLAGS/COPTFLAGS.
>> Flags only for the linker go in LDFLAGS.
>>
>> This is what Satish and I mapped out, and its all necessary for some
>> compiler.
>>
>>    Matt
>>
>>
>>>
>>> Satish
>>>
>>> On Sun, 11 Oct 2015, Barry Smith wrote:
>>>
>>> >
>>> >   Matt,
>>> >
>>> >   In c.py Linker.getFlags() is defined as
>>> >
>>> >
>>> >     def getFlags(self):
>>> >     '''Returns a string with the flags specified for running this
>>> processor.'''
>>> >     if not hasattr(self, '_flags'):
>>> >       flagsName = self.flagsName[:]
>>> >       if self.name == self.compiler.name:
>>> >         flagsName.extend(self.compiler.flagsName)
>>> >       if hasattr(self, 'configCompilers'):
>>> >         flags = ' '.join([getattr(self.configCompilers, name) for name
>>> in flagsName])
>>> >       else:
>>> >         flags = ' '.join([self.argDB[name] for name in flagsName])
>>> >       return flags
>>> >
>>> > in other words if the name of the linker is the same as the name of
>>> the compiler it sticks all the compiler flags on as linker flags. WTF?
>>> Compiler flags are compiler flags, not linker flags; it is amazing this
>>> doesn't do more damage.
>>> >
>>> >  How to fix this? Do any of the compiler flags need to be made into
>>> linker flags?
>>> >
>>> >
>>> > Barry
>>> >
>>> >
>>> > > On Oct 9, 2015, at 1:48 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>>> > >
>>> > >
>>> > >> LDFLAGS="-Wall -Wwrite-strings -Wno-strict-aliasing
>>> -Wno-unknown-pragmas -Qunused-arguments -g3"
>>> > >
>>> > > Wrt clang+gfortran - the trigger is: -Qunused-arguments [which is a
>>> > > clang flag - that gets passed to flinker aswell?]
>>> > >
>>> > > balay at es^~/junk $ gfortran -Qunused-arguments cmd.f
>>> > > gfortran: error: unrecognized command line option
>>> ‘-Qunused-arguments’
>>> > > balay at es^~/junk $
>>> > >
>>> > > Satish
>>> > >
>>> > >
>>> > > On Fri, 9 Oct 2015, Barry Smith wrote:
>>> > >
>>> > >>
>>> > >>   Well that's what the tests are for, to find such problems.
>>> > >>
>>> > >>   Perhaps it should not be in GNUPackage but only in the individual
>>> xxx.py packages that require it? But how do we know which packages need it
>>> and even then will be compatible on all systems.
>>> > >>
>>> > >>   Dmitry, please send the exact error that you got that inspired
>>> you to add this to the Gnumake package.
>>> > >>
>>> > >>  Barry
>>> > >>
>>> > >>> On Oct 9, 2015, at 1:24 PM, Satish Balay <
>>> pullrequests-reply at bitbucket.org> wrote:
>>> > >>>
>>> > >>>
>>> > >>> Satish Balay commented on pull request #375:
>>> > >>> Pass LDFLAGS down to GNUPackage externalpackages.
>>> > >>> Nightlybuilds broke due to this change [primarily --download-mpich
>>> - esp with clang+gfortran - and other combinations]
>>> > >>> View this pull request or add a comment by replying to this email.
>>> > >>> Unsubscribe from pull request emails for this repository.
>>> > >>
>>> > >>
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which their
>> experiments lead.
>> -- Norbert Wiener
>>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20151012/9121979b/attachment.html>