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

[Barry Smith]

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

  Barry

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