From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71396 invoked by alias); 15 Nov 2019 18:39:01 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 71389 invoked by uid 89); 15 Nov 2019 18:39:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=volunteers, retest, conforming, tip X-HELO: smtp-out-so.shaw.ca Received: from smtp-out-so.shaw.ca (HELO smtp-out-so.shaw.ca) (64.59.136.137) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Nov 2019 18:38:59 +0000 Received: from [192.168.1.114] ([24.64.172.44]) by shaw.ca with ESMTP id VgUii1BE317ZDVgUjiUZW4; Fri, 15 Nov 2019 11:38:58 -0700 Reply-To: Brian.Inglis@SystematicSw.ab.ca Subject: Re: linker fails with multiple definitions after inline thread_local var within class To: cygwin@cygwin.com References: From: Brian Inglis Openpgp: preference=signencrypt Message-ID: <769583d7-b1d7-fbc3-15ec-d377163c9d7f@SystematicSw.ab.ca> Date: Fri, 15 Nov 2019 22:07:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00096.txt.bz2 On 2019-11-15 00:55, Arthur Norman wrote: >> You appear to be running into a conflict with Cygwin managing Windows TLS, as >> Cygwin does its own messing around to support Unix/Linux/POSIX/g++ semantics for >> TLS and everything else under Windows. You should either use the supplied API, >> or write a Windows program that allows you to control TLS within Windows rules >> on what you can do with it. Otherwise you will have to get deep into the >> changeable and not directly supported underbelly of the Cygwin implementation. > > Than you for the prompt response, but while the motivation for my example > involved the Windows native TLS API the sample code that fails to link for me > does not touch that at all and tried to be generic C++ code. Where it > superficially appears that the cygwin TLS initialization code fails to pick up > the "inline" attribute that I believe it should inherit from the fact that the > TLS fields and methods that I use are inline and hence allowed to be > defined/declared multiple times. So does my sample code that fails breach the > C++ standard or is this a Cygwin limitation please? I notice that you are not independently compiling your source files and have no include guard in t.h. Could I suggest that you add the include guard to t.h and retest. If you still have an issue, try independently compiling your source files, then linking them as a separate step, to see if that works. You could also test reproducing the issue on another gcc platform, under a Unix VM, or a WSL Linux distro. You would have to check the C++17 standard, gcc docs, and/or mailing list, or bugzilla, to see if using that feature in that manner is supported, or if there are issues, limitations, or restrictions on doing so. It may be more useful to ask about such language/build interaction issues first on forums such as StackOverflow and/or language mailing lists, before posting here, as Cygwin and gcc are implemented in C++, so most issues are likely to have been noticed and fixed, but language/build issues are not often discussed, as all support is from volunteers, and language issues are off topic. There may be little response here unless someone has encountered the same issue using the same features. General points: Support by gcc of standards often lags; library feature support is dependent on libstdc++, newlib, and Cygwin winsup; and the Cygwin gcc release is a couple of versions behind the head/tip: https://gcc.gnu.org/projects/cxx-status.html#cxx17 https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017 Specifying the language standard -std=c++17 requires your sources to be strictly conforming, as it disables a lot of the GNU, POSIX, and Cygwin features and support that extend and relax the standards, sometimes with GNU rather than standard semantics, with issues, limitations, or restrictions, or may not yet be available. Features may not work, and may not issue a diagnostic, if that is not required, or just not yet implemented, perhaps dependent on support in binutils or other parts of the tool chain. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple