search for: efa5262b

On Thu, Jun 21, 2012 at 12:21 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > Hi, > > Yes, stlport was a pain to deploy and maintain + it calls normal operator > new/delete (there is no way to put them into a separate namespace). > Ok, but putting the raw symbols into a "namespace" with the linker shouldn't be subject to these limitations. Note that in some

Hi, Yes, stlport was a pain to deploy and maintain + it calls normal operator new/delete (there is no way to put them into a separate namespace). Note that in some codebases we build asan/tsan runtimes from source. How the build process will look with that object file mangling? How easy it is to integrate it into a custom build process? Soon I will start integrating tsan into Go language. For

...ove, it should be possible to resolve > any weak symbols? > Well, most likely yes. There may be additional limitations that I don't know yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120621/efa5262b/attachment.html>