<div dir="ltr"><div>So, I just raised a related issue on the IRC, and he conclusion was that this email thread is probably the right place to bring this up... <br><br></div><div>Would it be possible to make llvm-config --cxxflags actually just produce flags essential to compilinging and linking some arbitrary source outside of llvm, without a strict requirement of "identical flags to the ones used by the llvm Makefile"?<br><br></div><div>In my case, the main concern is that CXX in my Makefile needs to match that which was used to build llvm, since llvm-config --cxxflags produces -Wfoo and -Wbar that is useful for compiler X (clang in my case) but doesn't "work" in compiler Y (e.g. some version of gcc). So it's required for my project (that lives outside the llvm tree at the moment) to know which compiler was used to build llvm.<br><br></div><div><br>--<br></div><div>Mats<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 August 2015 at 21:34, Hans Wennborg via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Aug 8, 2015 at 4:02 AM, David Chisnall via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> On 7 Aug 2015, at 23:17, Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> I don't have any strong opinions.  Did this actually break anyone's use<br>
>> case or is it just a hypothetical problem?  It doesn't seem like there<br>
>> is much value in fixing this until llvm-config is also fixed.<br>
><br>
> The current 3.7 code breaks for the codebase that I use for teaching.  It uses RTTI in the AST construction, so can’t be compiled with -fno-rtti, but does need to use Module, IRBuilder, and friends, so not being able to link against an LLVM that’s built without RTTI is annoying (it means that the students can’t use LLVM packages on any OS).<br>
<br>
</span>This sounds pretty unfortunate, and if David is running into it then<br>
others probably will too (and those users might find the errors more<br>
confusing).<br>
<br>
If this is possible to fix by adding anchor functions to the various<br>
Instruction subclasses, that seems like a good fix (new functions is<br>
probably better than adding out-of-line ctors/dtors).<br>
<br>
In any case, to get such a fix merged to 3.7, the code owner would<br>
need to approve it. I don't think there is a specific owner for the<br>
IR, which means it falls under Chris's catch-all, so I'd like to hear<br>
what he thinks.<br>
<br>
(This sub-thread started here:<br>
<a href="http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html</a>)<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>         <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>