<div dir="ltr">Didn't realized we even supported using GCC to build libc++.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 10, 2014 at 11:45 AM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">> <span style="font-family:arial,sans-serif;font-size:13px">Has anyone actually run the tests against GCC recently? IIRC it requires some local modifications anyway.</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></span><div><font face="arial, sans-serif">I do it occasionally. Most parts work out of the box. I haven't tried using sanitizers with GCC though.</font></div><div><font face="arial, sans-serif">Don't forget the CMake build also uses -nodefaultlibs so it's not just the test suite that would require special handling of GCC.</font></div><span class="HOEnZb"><font color="#888888"><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">/Eric</font></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 10, 2014 at 12:43 PM, Dan Albert <span dir="ltr"><<a href="mailto:danalbert@google.com" target="_blank">danalbert@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yes, that is the downside.<div><br></div><div>Has anyone actually run the tests against GCC recently? IIRC it requires some local modifications anyway.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 10, 2014 at 11:40 AM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>> <span style="font-family:arial,sans-serif;font-size:13px">The reason we use -nodefaultlibs is to avoid linking the system's libc++. There's a -nostdinc++, maybe there should be a -nostdlib++? Or perhaps -stdlib=none?</span></span><div><span style="font-family:arial,sans-serif;font-size:13px">-nostdlib already exists but it acts like -nodefaultlibs and it drops the startup files as well. </span></div><div><font face="arial, sans-serif">I would support -stdlib=none but I'm hesitant to start depending on Clang only flags. It would be nice to not have to special case GCC.</font></div><span><font color="#888888"><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">/Eric</font></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 10, 2014 at 12:37 PM, Dan Albert <span dir="ltr"><<a href="mailto:danalbert@google.com" target="_blank">danalbert@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The reason we use -nodefaultlibs is to avoid linking the system's libc++. There's a -nostdinc++, maybe there should be a -nostdlib++? Or perhaps -stdlib=none?<div><br></div><div>That would let us stop preventing the driver from doing its job...</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Nov 10, 2014 at 11:26 AM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Thanks for the heads up about the dead link. I've attached the output to this email.<div><br></div><div>I spent some time last night trying to fix this problem in Clang but I had no luck :(</div><div>Moving the compiler-rt library before the linker inputs only created more issues.</div><span><font color="#888888"><div><div><br></div><div>/Eric</div></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 10, 2014 at 11:40 AM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> writes:<br>
> Hello,<br>
><br>
> I'm working on making libc++ generate code coverage data. This means that<br>
> libclang_rt.profile.x86_64.a is put into the link command before '-lc' and<br>
> other dependencies.<br>
> I suspect this change in library order causes the linker errors I see while<br>
> running the tests.<br>
><br>
> I have a couple of questions:<br>
>  - Should -ftest-coverage be passed when linking libc++?<br>
>  - Is there a way to link libclang_rt.profile.x86_64.a after the given linker<br>
>    flags<br>
><br>
> This file shows the ld invocation with and without -nodefaultlibs as well as<br>
> the error produced when<br>
> linking tests w/ -nodefaultlibs<br>
> <a href="http://pastebin.com/QWagJpsW" target="_blank">http://pastebin.com/QWagJpsW</a><br>
<br>
</div></div>There's nothing there? Mailing this text directly seems simpler than a<br>
pastebin to me.<br>
<br>
This issue and a few other things I've seen recently make me think that<br>
compiler-rt and -nodefaultlibs don't interact very well in general. I<br>
guess there's work to be done in the area.<br>
<br>
</blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>