[llvm-dev] Dealing with llvm::errs() and friends in dynamic libs on Windows
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 ~raw_fd_ostream()
> that calls report_fatal_error().
>
> It doesn't help that outs(), errs() etc. are not returning raw_fd_ostream,
> so you cannot clear the error codes manually (without dynamic_cast):
>
> struct LLVMCleanup
> {
> ~LLVMCleanup()
> {
> for (auto stream : {&llvm::errs(), &llvm::outs()})
> {
> if (auto fdStream =
> dynamic_cast<llvm::raw_fd_ostream*>(stream))
> fdStream->clear_error();
> }
> }
> };
>
> 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