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

[Satish Balay]

On Sun, 11 Oct 2015, Dmitry Karpeyev wrote:

> I'll try both.

There is no current implementation of 'removeCompilerFlags()'

> I assume these don't break all of 'next'? :-) I guess I
> still don't understand why LinkerFlags includes compiler flags. Clearly,
> though, LinkerFlags != LDFLAGS. Weird.

Well if only things were this simple. Whats the a Linker? [that these
flgs correspond to] Is there a universal linker?

We have 'cc', 'ld' etc - but do we ever use 'ld' directly?

And what does LDFLAGS really mean? CLINKER_FLAGS or FLINKER_FLAGS [or
CXX?]. Or a union (or intersection) of flags for all these langs?

[to answer your question wrt configure - pushlanguage(c) &&
getLinerFlags => CLINKER_FLAGS. Similar for other langs..]

Satish

> 
> On Sun, Oct 11, 2015, 12:59 Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
> >
> >    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.
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>
> >
> >
>