<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 12, 2015 at 8:45 AM, Dmitry Karpeyev <span dir="ltr"><<a href="mailto:dkarpeev@gmail.com" target="_blank">dkarpeev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">How does one extract just LDFLAGS while building a GNUPackage object?</p>
<p dir="ltr"></p></blockquote><div>What are you trying to do?</div><div><br></div><div>setCompilers.LDFLAGS or compilers.LDFLAGS is available. However, Toby has just</div><div>merged his parallel configure branch into 'next' which has rules for accessing these<br></div><div>variables since we want to be threadsafe. You use the 'with' operator.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Dmitry</p>
<br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 12, 2015, 08:43 Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 11, 2015 at 12:38 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">not sure about autoconf - but we do:<br>
<br>
c-compile-only: CPPFLAGS CFLAGS COPTFLAGS<br>
clinker: LDFLAGS? CFLAGS COPTFLAGS () LIB<br>
<br>
Perhaps configure should somehow preserve LDFLAGS option to configure<br>
- and make it accessiable to package.py somehow.</blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Compile-only flags go in CPPFLAGS. Flags for both the compiler and linker go in CFLAGS/COPTFLAGS.</div><div>Flags only for the linker go in LDFLAGS.</div><div><br></div><div>This is what Satish and I mapped out, and its all necessary for some compiler.</div><div><br></div><div> Matt</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888"><br>
Satish<br>
</font></span><div><div><br>
On Sun, 11 Oct 2015, Barry Smith wrote:<br>
<br>
><br>
> Matt,<br>
><br>
> In c.py Linker.getFlags() is defined as<br>
><br>
><br>
> def getFlags(self):<br>
> '''Returns a string with the flags specified for running this processor.'''<br>
> if not hasattr(self, '_flags'):<br>
> flagsName = self.flagsName[:]<br>
> if <a href="http://self.name" rel="noreferrer" target="_blank">self.name</a> == <a href="http://self.compiler.name" rel="noreferrer" target="_blank">self.compiler.name</a>:<br>
> flagsName.extend(self.compiler.flagsName)<br>
> if hasattr(self, 'configCompilers'):<br>
> flags = ' '.join([getattr(self.configCompilers, name) for name in flagsName])<br>
> else:<br>
> flags = ' '.join([self.argDB[name] for name in flagsName])<br>
> return flags<br>
><br>
> 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.<br>
><br>
> How to fix this? Do any of the compiler flags need to be made into linker flags?<br>
><br>
><br>
> Barry<br>
><br>
><br>
> > On Oct 9, 2015, at 1:48 PM, Satish Balay <<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>> wrote:<br>
> ><br>
> ><br>
> >> LDFLAGS="-Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -Qunused-arguments -g3"<br>
> ><br>
> > Wrt clang+gfortran - the trigger is: -Qunused-arguments [which is a<br>
> > clang flag - that gets passed to flinker aswell?]<br>
> ><br>
> > balay@es^~/junk $ gfortran -Qunused-arguments cmd.f<br>
> > gfortran: error: unrecognized command line option ‘-Qunused-arguments’<br>
> > balay@es^~/junk $<br>
> ><br>
> > Satish<br>
> ><br>
> ><br>
> > On Fri, 9 Oct 2015, Barry Smith wrote:<br>
> ><br>
> >><br>
> >> Well that's what the tests are for, to find such problems.<br>
> >><br>
> >> 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.<br>
> >><br>
> >> Dmitry, please send the exact error that you got that inspired you to add this to the Gnumake package.<br>
> >><br>
> >> Barry<br>
> >><br>
> >>> On Oct 9, 2015, at 1:24 PM, Satish Balay <<a href="mailto:pullrequests-reply@bitbucket.org" target="_blank">pullrequests-reply@bitbucket.org</a>> wrote:<br>
> >>><br>
> >>><br>
> >>> Satish Balay commented on pull request #375:<br>
> >>> Pass LDFLAGS down to GNUPackage externalpackages.<br>
> >>> Nightlybuilds broke due to this change [primarily --download-mpich - esp with clang+gfortran - and other combinations]<br>
> >>> View this pull request or add a comment by replying to this email.<br>
> >>> Unsubscribe from pull request emails for this repository.<br>
> >><br>
> >><br>
><br>
> </div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><br><br clear="all"><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</font></span></div></div></blockquote></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>