<div dir="ltr"><div class="gmail_quote">On Tue, 10 Mar 2015 at 09:36 Luca Bruno <<a href="mailto:lucab@debian.org">lucab@debian.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday 09 March 2015 03:51:46 Angus Lees wrote:<br>> I think we should add `DESTDIR := $(CURDIR)/debian/tmp` to the top of<br>
> debian/rules to get consistent behaviour - or if we're going to accept the<br>
> rust-gdb split then that will also workaround the issue "for free".  I'll<br>
> commit the former right now in fact.<br>
<br>
I was actually passing --destdir to dh_auto_install as a workaround locally,<br>
but if nodocs profile builds with your commit that's equally ok.<br></blockquote><div><br></div><div>Oh duh, _that's_ what was rewriting DESTDIR.  It takes about 2 hours for me to run a test rebuild, and this explains why my first 2 attempts hadn't worked<span style="font-size:13.1999998092651px"> :/</span></div><div><br></div><div>Heh, I'll upload a `dh_auto_install --destdir=$(DEB_DESTDIR)` change as soon as this test run completes - unless you beat me to it :P</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> > - Set buildflags according to policy (fixes relro lintian issue)<br>
> ><br>
> > Please thoroughly test this before committing, as I have this feeling that<br>
> > stuff will possibly break in subtle ways.<br>
><br>
> Yeah, I agree - if you've got any ideas for additional test cases, I'd be<br>
> happy to try them out.  It passes the full "make check" suite, which<br>
> exercises the compiler quite extensively - including both small executables<br>
> produced and of course the rustc executable itself (which is built with<br>
> these additional flags).<br>
<br>
Cool! I am more concerned about cargo and other libs, which may happen to mix<br>
flags. But at this point, I don't have specific cases in mind, so don't bother<br>
too much.<br>
<br>
I saw your buildflags patch, just two quick notes:<br>
 * CFLAGS and CXXFLAGS seems to be usually included by mk/cfg/*.mk files,<br>
   except for x86_64-unknown-linux-gnu. I don't know the reason behind that,<br>
   but I suspect your <a href="http://platform.mk" target="_blank">platform.mk</a> may results in double flags on other<br>
   platforms.<br></blockquote><div><br></div><div>It looks like x86_64-linux-gnu and *-apple-ios don't have CFLAGS in the platform makefiles.  I'm guessing they were perhaps the first few platforms, so perhaps it's just cargo-cult coding and no-one has cleaned it up yet (?).  I might send a patch upstream to do so...</div><div> </div><div>The flags should be safe if they appear multiple times, but I agree it would be nice not to duplicate them.  I originally modified the mk/cfg/* files and can change the patch to do that way again if you'd like, but the current one was (I think) the cleaner form and the one I'm intending to propose upstream.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 * is there a reason for "Forwarded: no" or is it just a matter of (lack of)<br>
   time? I would be interested in getting upstream review on this and the<br>
   rationale behind the different handling in amd64.<br></blockquote><div><br></div><div>Yeah, I meant Forwarded: "no" as in "not-yet", not "not-needed".  I'll send something upstream now that we've confirmed it works.</div><div><br></div><div>Oh and re your concern about effects on cargo and other libs - the flags only affect the current binaries being built(*).  There should be no change to binaries that are in turn built by this rustc (and indeed, other downstream Debian rust packages will need to duplicate some form of my env settings - just like they would need to for C/C++).</div><div><br></div><div>(*) with a few exceptions.  For example `-z relro` makes additional memory sections read-only at run-time for any code using the dylib, but afaiui rust uses the runtime linker in quite a normal way and so shouldn't be upset by this.</div><div><br></div><div> - Gus</div></div></div>