DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60O9UP2g3711791
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 60O9UP2g3711791
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=eZ23a2na
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 06EB84BA2E34
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1769247024;
	bh=tJhVHjerCkqFxt/qYt/wJNIXUTGwJzXAm+IF2RhAsKg=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=eZ23a2naLUNpEq2JvfcKyaphBa72QU5n+iKDj5S0bCD0Omq6d2PqEAj2/PW40E519
	 +TQg3hoED+7dlqR4hUc4jAT1Vd3rxUVODovsLtSNGhyIGCRvnqkxBiUG+y5U6EzV6e
	 3VOM6Z1XYCv4LBgeTNkGwAY1uKeiPMefjMV9RtVo=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D49CF4BA2E34
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D49CF4BA2E34
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1769246996; cv=none;
 b=Cxa7+Osr4OrVzGqPkEePxwoLBXFWAPQZ5+L72QbmzH4xHCFBgItxbe/B1fvLtdJn0RYSkCgKBl8RkHeh8UBtqm/YNoX+kOKM1VPgIbv+jnfjSOb6GlbeLL+BUd0VywlbPLQwl8v7BqsTVnXj5+swHwrKetnvym4cEkBtnlgVJeE=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1769246996; c=relaxed/simple;
 bh=9EvFw/hcntWtV9cghLzkH60tCytHvSTY1Ae5a9UraGM=;
 h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature;
 b=khztRN+azEKCBhOk6Hdzo05bZf5wJI7e1hO96mL3gGPJux6eObotfTnMWfcMEVPllHEVAZHtFXPzAxYxuMkUDWyFa60g/7Bhh0csOcrvzVJMzIjykgF06WKdHUNW3cePJopgeDbXTBWKVq7TDywb2ZVu7aI4P9D2Tlul72bDmrE=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D49CF4BA2E34
Date: Sat, 24 Jan 2026 18:29:52 +0900
To: cygwin AT cygwin DOT com
Subject: Re: Request to update libc++ related packages for current
 Clang/LLVM toolchain
Message-Id: <20260124182952.57fe14cbe385c0d33ac74613@nifty.ne.jp>
In-Reply-To: <1769162973466.1292911577.1255992200@gmail.com>
References: <20260122172003 DOT 9f1447b5885d76561c898c81 AT nifty DOT ne DOT jp>
 <1769162973466 DOT 1292911577 DOT 1255992200 AT gmail DOT com>
X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32)
Mime-Version: 1.0
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Takashi Yano via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

Hi Tomohiro,

On Fri, 23 Jan 2026 12:28:51 +0000
kikairoya via Cygwin <cygwin AT cygwin DOT com> wrote:
> 
> 2026年1月22日 17:20:03 (+09:00) で、Takashi Yano via Cygwin さんが書きました:
> 
> > >
> > > If you are planning to provide a package built with compiler-rt, especially
> > > one that contains a DLL, I would say, "Please don't do that." It's very
> > > different if someone decides to build their own application with compiler-rt
> > > and takes responsibility for doing so. Before providing such a package, the
> > > implementation of native TLS in cygwin1.dll is needed, as well as an update
> > > to the toolchains to use it (and, I guess, it is impossible to switch with
> > > keeping ABI). That changes the fundamental design of the distribution.
> > 
> > I attempted to build the entire compiler-rt (builtins) as a shared library,
> > similar to the suggestions in:
> > https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/emutls.c#L388-L389
> > , and could successfully solve the problem.
> > Could you please try 21.1.4-2 (Test)?
> > 
> 
> 
> I’m concerned this makes the situation worse than providing a static library. I guess
> that the upstream has never built it as a shared library. Consequently, that configuration
> appears to be largely untested.
> And then, what is the benefit of "specifying -rtlib=compiler-rt makes us cyggcc_s.dll free but
> requires a dependency on cygclang_rt.builtins-21-x86_64.dll" ? Is there another benefit?

I don't think I could get your point. The benefit of this test version is
solving the broken thread local variable reference between dlls and executable,
of course.

> Furthermore, if you really intend to provide a DLL linked with compiler-rt, the
> DLL comes with limitations that are hard to notice.
> (If this is not what you are planning, please feel free to ignore this.)
> - Linking the DLL without -rtlib=compiler-rt breaks the EmuTLS functionality silently. There is
>   no way to know that the linking needs compiler-rt except inspecting the DLL with ldd or objdump.

Why? If -rtlib=compiler-rt is not specified, the program uses libgcc_s
which is a shared library. Therefore, emutls works as expected except
for a bug in libstdc++:
https://cygwin.com/pipermail/cygwin/2025-November/258943.html

> - 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.

> Of course that might not matter if EmuTLS is never used, however, I worry about the
> assumptions that are not enforced or validators automatically would be broken silently.
> 
> Therefore, my conclusion remains unchanged -- "Please don't do that."

I have uploaded compiler-rt 21.1.4-3 (Test), where the shared library
is used only for __emutls_get_address(), and programs that do not use
emutls will be linked with compiler-rt statically.

> Just to note, we're now focusing on compiler-rt because my original attention is about
> EmuTLS, but the same discussion is applicable to libc++. A DLL that exports C++ interfaces
> and linked to libc++ (if such a DLL were to be provided, would it be cygLLVM-X.dll?) can't be
> linked together with another libstdc++-ed C++ library (e.g., boost).

No. cygLLVM-x.dll is a part of llvm package. The shared library in libc++
package is cygc++-1.dll. Anyway, I don't understand what is the problem
in that case.

$ clang++ -stdlib=libc++ -unwindlib=libunwind -rtlib=compiler-rt emutlstest.cc -o emudll.dll -DDLL=1 -shared && clang++ -stdlib=libstdc++ -unwindlib=libunwind -rtlib=compiler-rt emutlstest.cc -o emuexe.exe -DEXE=1 emudll.dll && ./emuexe.exe
1 0xa00000538 0xa00000538
1 0xa000268a8 0xa000268a8
$ clang++ -stdlib=libstdc++ -unwindlib=libunwind -rtlib=compiler-rt emutlstest.cc -o emudll.dll -DDLL=1 -shared && clang++ -stdlib=libc++ -unwindlib=libunwind -rtlib=compiler-rt emutlstest.cc -o emuexe.exe -DEXE=1 emudll.dll && ./emuexe.exe
1 0xa00000538 0xa00000538
1 0xa000109c8 0xa000109c8
$ clang++ -stdlib=libc++ -unwindlib=libgcc -rtlib=libgcc emutlstest.cc -o emudll.dll -DDLL=1 -shared && clang++ -stdlib=libstdc++ -unwindlib=libgcc -rtlib=libgcc emutlstest.cc -o emuexe.exe -DEXE=1 emudll.dll && ./emuexe.exe
1 0xa00000538 0xa00000538
1 0xa000269c8 0xa000269c8
$ clang++ -stdlib=libstdc++ -unwindlib=libgcc -rtlib=libgcc emutlstest.cc -o emudll.dll -DDLL=1 -shared && clang++ -stdlib=libc++ -unwindlib=libgcc -rtlib=libgcc emutlstest.cc -o emuexe.exe -DEXE=1 emudll.dll && ./emuexe.exe
1 0xa00000538 0xa00000538
1 0xa00010ae8 0xa00010ae8

Of course, the cases bellow do not work because executable and DLL
call different __emutls_get_address().

$ clang++ -stdlib=libc++ -unwindlib=libunwind -rtlib=compiler-rt emutlstest.cc -o emudll.dll -DDLL=1 -shared && clang++ -stdlib=libc++ -unwindlib=libgcc -rtlib=libgcc emutlstest.cc -o emuexe.exe -DEXE=1 emudll.dll && ./emuexe.exe
0 0xa00000538 0xa00000558
0 0xa00010ba8 0xa00010c58
$ clang++ -stdlib=libc++ -unwindlib=libgcc -rtlib=libgcc emutlstest.cc -o emudll.dll -DDLL=1 -shared && clang++ -stdlib=libc++ -unwindlib=libunwind -rtlib=compiler-rt emutlstest.cc -o emuexe.exe -DEXE=1 emudll.dll && ./emuexe.exe
0 0xa00000538 0xa00000558
0 0xa00010b18 0xa00010c58


Furthermore, the following test case also works.

$ cat hello.cc
#include <iostream>
#ifdef DLL
void func()
{
        std::cout << "Hello(dll)" << std::endl;
}
#endif
#ifdef EXE
extern void func();
int main()
{
        std::cout << "Hello(main)" << std::endl;
        func();
        return 0;
}
#endif
$ clang++ -stdlib=libc++ -rtlib=compiler-rt -unwindlib=libunwind -DDLL hello.cc -shared -o hello.dll && clang++ -stdlib=libstdc++ -rtlib=libgcc -unwindlib=libgcc -DEXE hello.cc hello.dll -o hello.exe && ./hello.exe
Hello(main)
Hello(dll)
$ clang++ -stdlib=libstdc++ -rtlib=libgcc -unwindlib=libgcc -DDLL hello.cc -shared -o hello.dll && clang++ -stdlib=libc++ -rtlib=compiler-rt -unwindlib=libunwind -DEXE hello.cc hello.dll -o hello.exe && ./hello.exe
Hello(main)
Hello(dll)

-- 
Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>

-- 
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