[llvm-dev] Dealing with llvm::errs() and friends in dynamic libs on Windows (original) (raw)

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 10 10:52:08 PDT 2018

I think the easiest way for you to deal with this will be to redirect FDs 1 and 2 to the NUL device, or to a pipe or wherever you'd like LLVM or any other third party libraries to send their output.

On Sun, Sep 9, 2018 at 9:30 AM Janus Lynggaard Thorborg via llvm-dev < llvm-dev at lists.llvm.org> wrote:

Hello,

outs() and errs() are routinely used around llvm and cannot really be disabled. It would seem that in certain types of Windows applications, stderr and stdout are not opened by default, which is an assumption of llvm. This leaves errs() and outs() with an error code, because writing calls will fail due to invalid fd handles. Thus, when an llvm lib is unloaded, it will terminate the entire process due to a non-zero EC in ~rawfdostream() that calls reportfatalerror(). It doesn't help that outs(), errs() etc. are not returning rawfdostream, so you cannot clear the error codes manually (without dynamiccast): struct LLVMCleanup { ~LLVMCleanup() { for (auto stream : {&llvm::errs(), &llvm::outs()}) { if (auto fdStream = dynamiccastllvm::rawfdostream*(stream)) fdStream->clearerror(); } } }; Above is my currently working fix (if I sprinkle it in enough places) but it is a pretty fragile solution. Is there some special initialization or handling that I'm missing? My program is itself a dynamic lib, so I don't control state of stderr or stdout. I would rather not terminate my host process because diagnostic prints failed. Thanks - and regards, Janus

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180910/9108f764/attachment.html>

More information about the llvm-dev mailing list