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

[Matthew Knepley]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20151012/8606fe5f/attachment.html>