<div class="gmail_quote">On Sat, Aug 18, 2012 at 8:27 AM, Michael Wild <span dir="ltr"><<a href="mailto:themiwi@gmail.com" target="_blank">themiwi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 08/18/2012 02:20 PM, David Cole wrote:<br>
><br>
><br>
> On Sat, Aug 18, 2012 at 6:57 AM, Michael Wild <<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>>> wrote:<br>
><br>
> On 08/17/2012 05:25 PM, David Cole wrote:<br>
> ><br>
> ><br>
> > On Fri, Aug 17, 2012 at 11:16 AM, Rolf Eike Beer <<a href="mailto:eike@sf-mail.de">eike@sf-mail.de</a><br>
> <mailto:<a href="mailto:eike@sf-mail.de">eike@sf-mail.de</a>><br>
</div><div><div class="h5">> > <mailto:<a href="mailto:eike@sf-mail.de">eike@sf-mail.de</a> <mailto:<a href="mailto:eike@sf-mail.de">eike@sf-mail.de</a>>>> wrote:<br>
> ><br>
> > Am Freitag, 17. August 2012, 14:17:33 schrieb Michael Wild:<br>
> > > Yes, e.g. i386 works fine:<br>
> > ><br>
> ><br>
> <a href="https://buildd.debian.org/status/fetch.php?pkg=freefoam&arch=i386&ver=0.1.0%" target="_blank">https://buildd.debian.org/status/fetch.php?pkg=freefoam&arch=i386&ver=0.1.0%</a><br>
> > > 2Bdfsg-1&stamp=1345172639<br>
> > ><br>
> > > It seems that only the more exotic (non-Intel) ones have<br>
> this issue. I<br>
> > > forgot to mention that mipsel and sparc have the same<br>
> problem. Except<br>
> > > for mipsel they are all big-endian...<br>
> ><br>
> > You are looking at the totally wrong place I guess ;)<br>
> ><br>
> > i386 command:<br>
> ><br>
> > cd<br>
> ><br>
> /build/buildd-freefoam_0.1.0+dfsg-1-i386-5n1wds/freefoam-0.1.0+dfsg/obj-<br>
> > i486-linux-gnu/src/Pstream/dummy && /usr/bin/g++<br>
> > -DdummyPstream_EXPORTS -DDP<br>
> > -DNoRepository -Dlinux -g -O2 -fstack-protector<br>
> > --param=ssp-buffer-size=4 -<br>
> > Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fpermissive -<br>
> > D_FORTIFY_SOURCE=2 -fPIC -I/build/buildd-freefoam_0.1.0+dfsg-1-<br>
> > i386-5n1wds/freefoam-0.1.0+dfsg/obj-i486-linux-gnu/include -o<br>
> > CMakeFiles/dummyPstream.dir/dummyIPstreamImpl.C.o -c<br>
> /build/buildd-<br>
> > freefoam_0.1.0+dfsg-1-<br>
> ><br>
> i386-5n1wds/freefoam-0.1.0+dfsg/src/Pstream/dummy/dummyIPstreamImpl.C<br>
> ><br>
> > powerpc build:<br>
> ><br>
> > cd<br>
> ><br>
> /build/buildd-freefoam_0.1.0+dfsg-1-powerpc-810bTJ/freefoam-0.1.0+dfsg/obj-<br>
> > powerpc-linux-gnu/src/Pstream/dummy && /usr/bin/g++<br>
> > -DdummyPstream_EXPORTS -<br>
> > DDP -DNoRepository -g -O2 -fstack-protector<br>
> > --param=ssp-buffer-size=4 -Wformat<br>
> > -Werror=format-security -D_FORTIFY_SOURCE=2 -fpermissive<br>
> > -D_FORTIFY_SOURCE=2 -<br>
> > fPIC -I/build/buildd-freefoam_0.1.0+dfsg-1-<br>
> > powerpc-810bTJ/freefoam-0.1.0+dfsg/obj-powerpc-linux-gnu/include<br>
> > -D -o<br>
> > CMakeFiles/dummyPstream.dir/dummyIPstreamImpl.C.o -c<br>
> /build/buildd-<br>
> > freefoam_0.1.0+dfsg-1-<br>
> ><br>
> powerpc-810bTJ/freefoam-0.1.0+dfsg/src/Pstream/dummy/dummyIPstreamImpl.C<br>
> ><br>
> > The important difference is:<br>
> ><br>
> > the PowerPC build has a stray "-D" in it, so g++ takes the<br>
> following<br>
> > -o as<br>
> > define and the following object file name as input instead of<br>
> as output.<br>
> ><br>
> ><br>
> > NICE EYE!!!!!<br>
><br>
> How very embarrassing! Thanks for helping me out with this one.<br>
><br>
><br>
> Just curious: was it a misspelled variable name? Would you have gotten a<br>
> warning if you used "--warn-unused-vars" on the cmake command line?<br>
><br>
<br>
</div></div>Not misspelled, it was a unhandled situation. When I originally wrote<br>
that code years ago I consciously decided to only handle i386 and x86_64<br>
and figured I'd deal with other architectures when the situation crops<br>
up. Well, I completely forgot about that, and here it is ;-) And yes,<br>
that flag would have fired, but then I also rely on undefined variables...<br>
<span class="HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span></blockquote></div><br><div><br></div><div>:-)</div><div><br></div><div>Thanks for the explanation.</div><div><br></div><div>Time to deal with some new architectures...</div><div><br></div><div>One technique I like to use for stuff like this is to be explicit about it with a super-helpful error message as early as possible, like we do in the "git too old" case for ExternalProject:</div>
<div><div><br></div><div> if(git_version VERSION_LESS 1.6.5)</div><div> message(FATAL_ERROR "error: git version 1.6.5 or later required for 'git submodule update --recursive': git_version='${git_version}'")</div>
<div> endif()</div></div><div><br></div><div>I firmly believe (though I have no direct evidence) that using this technique saves us from some small but distracting number of bug reports, and actually helps the people who encounter these conditions to solve problems themselves without any further information.</div>
<div><br></div><div>Glad you got to the bottom of this one. Sometimes it just takes a few extra sets of eyeballs.</div><div><br></div><div><br></div><div>Cheers,</div><div>David</div><div><br></div>