DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 60NCTGtx2957518
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5E9884BCA404
Message-Id: <1769162973466.1292911577.1255992200@gmail.com>
To: cygwin AT cygwin DOT com
Subject: Re: Request to update libc++ related packages for current
 Clang/LLVM toolchain
Date: Fri, 23 Jan 2026 12:28:51 +0000
In-Reply-To: <20260122172003.9f1447b5885d76561c898c81@nifty.ne.jp>
References: <20260122172003 DOT 9f1447b5885d76561c898c81 AT nifty DOT ne DOT jp>
User-Agent: Vivaldi Mail/7.7.3851.67
MIME-Version: 1.0
Precedence: list
From: kikairoya via Cygwin <cygwin AT cygwin DOT com>
Reply-To: kikairoya <kikairoya AT gmail DOT com>
Content-Type: text/plain; charset="utf-8"
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>
Content-Transfer-Encoding: 8bit


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?

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

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

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


> Actually, profiler itself was included, but did not work at all. Both the
> compiler-rt package and the llvm package had their own issues. I have
> uploaded llvm 21.1.4-2 (Test) and compiler-rt 21.1.4-2 (Test), so please
> test the profiler as well.
> 

That's great. Thanks.
-- 
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