DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60RBnhBb2313259
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7CC034BA2E25
Message-Id: <1769513336875.1242228887.3774597352@gmail.com>
To: Takashi Yano via Cygwin <cygwin@cygwin.com>
Subject: Re: Request to update libc++ related packages for current
 Clang/LLVM toolchain
Date: Tue, 27 Jan 2026 11:49:20 +0000
In-Reply-To: <20260126123722.942a6958f748ba52a619a72e@nifty.ne.jp>
References: <20260126123722.942a6958f748ba52a619a72e@nifty.ne.jp>
User-Agent: Vivaldi Mail/7.7.3851.67
MIME-Version: 1.0
Precedence: list
From: kikairoya via Cygwin <cygwin@cygwin.com>
Reply-To: kikairoya <kikairoya@gmail.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit


2026年1月26日 12:37:22 (+09:00) で、Takashi Yano via Cygwin さんが書きました:

> > To be clear, I'm not asking you to fix the TLS functionality of compiler-rt; I'm
> > just asking you to not package a DLL built with -rtlib=compiler-rt (and also
> > -stdlib=libc++). 
> > 
> > Such a library implicitly enforces the use of specific compiler options, making
> > it incompatible with other libraries, even if compiler-rt is provided as a
> > shared library.
> 
> Ok. Are you talking about a specific package, or is this meant as
> a general statement?


My subject is all packages which might be planned to rely on another package
that is intended to replace the any "standard" libraries implicitly linked by
gcc (namely, -lstdc++, -lgcc_s, -lintl, etc.).


> Ah, I got it. Providing alternative itself is a some kind of benefit.
> And also the program built with compiler-rt (and libunwind) will be
> free from external DLLs except in the case where the emutls is used
> (as far as using 21.1.4-3 that returns to static linking in most cases).

Thanks. That's exactly what I has presumed and what I think.


> > Regarding building a package with -rtlib=compiler-rt, either verification that
> > the problem does not affect programmers in practice or a clear justification is
> > needed, since there is at least one downside.
> > To verify that a package built with -rtlib=compiler-rt doesn't cause a problem
> > with the TLS, it would be enough to check that if no module (not only DLLs; EXEs
> > also can export symbols) in the package exports a symbol beginning with
> > __emutls_. However, I believe this kind of check should be automated for *all*
> > packages by default, regardless of who maintains it or whether the package uses
> > compiler-rt; otherwise, the check will easily be overlooked. Of course, the
> > checker must always pass for a module which is linked to libgcc_s.
> 
> Do you assume the check would be implemented in cygport?


Yes. It could be part of build, install, or package step. Unfortunately, I don't
have any experience with or knowledge of cygport to suggest anything particular.


> > > > - GCC doesn't support -rtlib=compiler-rt. That effectively enforces the use of clang.
> > > > - A single module (EXE or DLL) can link against only one of the TLS implementations, either the
> > > >   one from libgcc_s or the one from compiler-rt. A TLS variable that relies on the other
> > > >   implementation would be broken (again, silently).
> > > 
> > > These are not related to the aproach whether compiler-rt provides shared
> > > library or not, I think. Even if compiler-rt provides static library,
> > > above two problems still exist.
> > > 
> > 
> > Yes, I explained that building compiler-rt as a shared library doesn't solve the
> > problem.
> 
> If you meant "the problem" is the incomatibility between compiler-rt and
> libgcc_s, you are right. However, at least, it solves the problem that the
> program using emutls across the executable and DLL does not work as expected,
> which occured even using only compiler-rt.


From the perspective of an end-programmer who wants to use compiler-rt, the
shared compiler-rt looks like the solution, whether split or not.
From the perspective of a packager or an user who wants to use the package,
there shouldn't be practical difference between the shared and static versions
-- as discussed, any package that exports or imports TLS variables shouldn't
rely on compiler-rt due to its incompatibility with libgcc. That said, for a
TLS-free package, the static or split version might be preferable, as it reduces
DLL dependency.
I have focused on the latter perspective in my argument, but I believe we are in
agreement on each aspect.
Regarding the split compiler-rt, it would be great if you could upstream the
modification, as this affects mingw or msys2 users.


> > I'm worried that you might build the next version of the llvm package (or other
> > library packages you maintain) with -stdlib=libc++ and
> > -rtlib=compiler-rt. That's all I'm asking with "Please don't do that."
> > Consider to the case of someone is developing an LLVM plugin helped with
> > Boost. Both of the LLVM headers and the Boost headers include standard C++
> > libraries. If the llvm package were built with libc++, how would they specify
> > the -stdlib flag to compile a .cpp file that includes both of LLVM and Boost
> > headers?
> 
> I’ve eventually come to understand your concern. I have no plant to
> build llvm package with libc++/compiler-rt/linunwind.

Thanks! That's good to know.


> But, I'm planning to provide clangd
> https://cygwin.com/pipermail/cygwin-apps/2026-January/044769.html
> which using libc++ as follows,
> $ ldd /usr/bin/clangd
>         ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7fff41180000)
>         KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7fff40ab0000)
>         KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7fff3e650000)
>         cygc++-1.dll => /usr/bin/cygc++-1.dll (0x46a270000)
>         cygwin1.dll => /usr/bin/cygwin1.dll (0x7fff202e0000)
>         cygz.dll => /usr/bin/cygz.dll (0x394930000)
>         cygzstd-1.dll => /usr/bin/cygzstd-1.dll (0x394760000)
>         cygunwind-1.dll => /usr/bin/cygunwind-1.dll (0x5cafa0000)
> because libstdc++ with libgcc_s has a problem:
> https://cygwin.com/pipermail/cygwin/2025-November/258943.html
> 
> This package does not provide libraries neither static nor DLL.
> Do you think this also has a risk you concern?


Any package that only provides exe files only wouldn't cause the problem what I
mentioned, assuming the exe files export nothing and import no TLS variables.
Although libc++ and libunwind themselves should be verified as safe to be built
with compiler-rt, I won't complain about an exe-only package that relies on
libc++.

However, I'm concerned about your reasoning. It implies that other packages,
including the llvm package, should be built with libc++ and compiler-rt. I
believe that the correct approach is to either apply a workaround to cygwin1.dll
(i.e., revert) or fix libstdc++.  If a workaround is needed for this specific
case, -DLLVM_ENABLE_THREADS=OFF might help.

Also, unrelated to this discussion, is there a reason not to use
-DLLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR=... with clang.cygport? That way,
clangd.exe can be built together with the clang package. Are clang-tidy and its
plugin functionalities intentionally omitted?


> Thanks for the test cases below. The problem in all cases is that the
> instance created by libstdc++/libc++ is manipulated with libc++/libstdc++.
> Is this supposed to happen when using boost, for example?


This is not a problem specific to any particular library. Rather, it's a general
ABI matching problem.
FYI, there are many real-world examples that can't mix libstdc++ and libc++:

llvm/IR/Value.h
https://github.com/llvm/llvm-project/blob/00fb401a902105a164bb1ecaa63ce8ba1677c9c2/llvm/include/llvm/IR/Value.h#L294

opencv/core/types.hpp
https://github.com/opencv/opencv/blob/774c7e01b3f559140b731b6ca95f3a36e8f52386/modules/core/include/opencv2/core/types.hpp#L563

FL/FL.H
https://github.com/fltk/fltk/blob/38fbd41896559cbeb8b922805753c4532bd0861b/FL/Fl.H#L247

boost/program_options/options_description.hpp
https://github.com/boostorg/program_options/blob/902aaedaaa157a92e649c3b1324c92f5a264a805/include/boost/program_options/options_description.hpp#L104

-- 
Tomohiro Kashiwada (@kikairoya)


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple