DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 60RBnhBb2313259
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 60RBnhBb2313259
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=ndokh0Wj
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org DB9554BA900D
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1769514581;
	bh=t+VTwD4TkSCbkX6A4FPPGnbagevzdC99wm9BFFM5sbs=;
	h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=ndokh0WjodIwVcDBJbNs5uBfstUxeZQJtv0kfnGuu+otO/t1LU/9TJj9QK8W6ASDC
	xvUaa4/Lt09EyHVyZPIRF5FzWMxOaa3YD4KRkILhC5P83kHM5kGt7hP4JELWt3Wu3+
	ow2AxbDC4/wO86yF5FtxfSNrYeRkJOBaXPFEXtrE=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 7CC034BA2E25
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 7CC034BA2E25
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1769514562; cv=none;
	b=gHcNR1xysJL7M0cPA0XT/LPKZS19pAQI/GyRMSouaXlg8RqSHUQPJKNNZKBwuzqcudSt2J8KWkDf6WR/dKSrP4ZwzyG+uzvZH9BJSzRAiTWr9JrMeo2pbG2kJFgwh5HrMz3HSJjprXyd1ANmyPTjkRBws/bugtDPGD/8dfDsht8=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1769514562; c=relaxed/simple;
	bh=YMNskSxN0Ar7eJmB7OWfxmeoGTkFtZoTAkorUTNlTHo=;
	h=DKIM-Signature:Message-Id:From:To:Subject:Date:MIME-Version;
	b=edee3+gDN03v4rIR11VcNZ3chTNyTz7WZVZUMTsmxE6CxCpbjYeLkS2GXR/UOvCsQAeSA5PHesF/z5K3u5LxNz6pnLejRvfsvMHqW2cfohvV/ibdv5YDT7pXE+DdgQWAGXk+7VGeWHQiAkctruaXme1gv6dWzkJKg2wcX1qAkxQ=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 7CC034BA2E25
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20230601; t=1769514561; x=1770119361;
	h=mime-version:content-transfer-encoding:user-agent:references
	:in-reply-to:date:subject:to:from:message-id:x-gm-gg
	:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
	bh=iSXKVKOjFCHDtGtlnV4V7SrBscjQrwDhWSQafP1WHbI=;
	b=ZxhwDlI0PmDH2kjPIff/AVrxgJgweQs7H0GiZZhLPcVhqYBbIwgSRNgSYbMDazDetJ
	fUGTEGf+/SSUgymC/5P7CvSR60o9ZJfxMVSaJjFiqi26vy0cmCaJh7HmizF66OJrdTgg
	Xa+6FHAX7UEdNxRe/IEmH2CxVk4Y4PU+wAHQZwtpJdu60gpimO8mqs4CCdWo6jtNScx8
	E3xTrD0fcRZxUQEfGoznUsSa7pgW3/L9ZPHtvDfwQl/FssJkm8lnAYmAJ/vhIPDilSyi
	pcdC42TRJUok5UcvK3bOGOvznS7T2RTPT9/0dMZM+gLm9yu9lQeuBisYyo7vt0M+qaqq
	Wigw==
X-Gm-Message-State:	AOJu0Yx6PMBqjvCSLsoSJiJxPI/d0CDZaIxXTYs8dL5fn+UJWffLTzq/
	Jr0eZTp4XGN9VRQ1czKsa0jwximXwe3M/B3T4VgGSTCMi9rE0EqebZ7LmlA3oA==
X-Gm-Gg:	AZuq6aKEgb7Ppdq31B9wUKwT75/RG/7oXsGveE5bEy04dM7Cn/dNgxzA5DGBqdbdy59
	s9FyLDx9+jTct2JpS7402OwQuMsj0/LbFgZA2XiAAT0PDW3cn84DyJb7/cZy+hIavzalymCO/KY
	GqT1zX68iphW9r7NVjhTf2yCkfu9/vcAXKuBkp6cU+KOwkR/Ch0Y1NEtvdzNAro3qs3fSBUT+n+
	NhFShBDsy4bjsg3GGA8aVVqNe6KnuiH5tGLi7JqIXdT2ghoUkMPVJtmyVS0n4s5D/jxk3fF/TfY
	fDlB8m3Wfc/ERLPE5fau/kTw56EUcwlxOtbOG2gpXZmW67LctZnJy5MSIEeXWhy2sgyVF2lKnuV
	aSsUL+Hod0oItr82LIFR01FgUQ7zhATA87CbMFRt0xwsgWwSasAYw07LPOMkC9l28HzrdhuyGqy
	x9hH6qz2UKpvqqn77QQN7DPZ3wnR4v7l1ZkDA=
X-Received:	by 2002:a17:902:da8a:b0:2a7:9ded:9b4a with SMTP id
	d9443c01a7336-2a870dd55d1mr15825435ad.36.1769514561314;
	Tue, 27 Jan 2026 03:49:21 -0800 (PST)
Message-Id:	<1769513336875.1242228887.3774597352@gmail.com>
To:	Takashi Yano via Cygwin <cygwin AT cygwin DOT 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 DOT 942a6958f748ba52a619a72e AT nifty DOT ne DOT jp>
X-Mailer:	Vivaldi Mail
User-Agent:	Vivaldi Mail/7.7.3851.67
MIME-Version:	1.0
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
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:	kikairoya via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	kikairoya <kikairoya AT gmail DOT com>
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>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 60RBnhBb2313259

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

- Raw text -