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

Barry Smith bsmith at mcs.anl.gov
Sun Oct 11 12:59:39 CDT 2015


 
   or

>  args.append('LDFLAGS="'+self.removeCompilerFlags(self.getLinkerFlags())+'"')


> On Oct 11, 2015, at 12:55 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> Perhaps the following is the fix Dmitry needs..
> 
> Satish
> 
> --------
> diff --git a/config/BuildSystem/config/package.py b/config/BuildSystem/config/package.py
> index ebe3d15..4917ce5 100644
> --- a/config/BuildSystem/config/package.py
> +++ b/config/BuildSystem/config/package.py
> @@ -1034,7 +1034,7 @@ class GNUPackage(Package):
>     args.append('CFLAGS="'+self.removeWarningFlags(self.getCompilerFlags())+'"')
>     args.append('AR="'+self.setCompilers.AR+'"')
>     args.append('ARFLAGS="'+self.setCompilers.AR_FLAGS+'"')
> -    args.append('LDFLAGS="'+self.getLinkerFlags()+'"')
> +    args.append('LDFLAGS="'+self.setCompilers.LDFLAGS+'"')
>     self.popLanguage()
>     if hasattr(self.compilers, 'CXX'):
>       self.pushLanguage('Cxx')
> 
> 
> On Sun, 11 Oct 2015, Satish Balay 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.
>> 
>> 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.		                     
>>>>> 
>>>>> 
>>> 
>>> 
>> 




More information about the petsc-dev mailing list