From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122606 invoked by alias); 15 Nov 2019 22:25:48 -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 122599 invoked by uid 89); 15 Nov 2019 22:25:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,LIKELY_SPAM_BODY,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy=pain, advertising, alert, moan X-HELO: ppsw-32.csi.cam.ac.uk Received: from ppsw-32.csi.cam.ac.uk (HELO ppsw-32.csi.cam.ac.uk) (131.111.8.132) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Nov 2019 22:25:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cam.ac.uk; s=20180806.ppsw; h=Content-Type:MIME-Version:References:Message-ID: In-Reply-To:Subject:cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CRl6uCV+8+Aig5c7vone3I8cECszu3cjNdAEeXhJBvY=; b=J7BCUx6H2GKW8QIt9/8+Nf4hia UxK7YVsNYRwm2BoNzcIM3z3XKCGm1qcupbmNInpd8pKNDNsGLLEVcExuU0nU3bDf2PPG7sofY0Byx RebUkFqy7CA3vEiX7hXvkRQ6rF/E7QtU+E2nra4lKFJ5hwdO+CQk17h7EmwIvgIbvxgQ=; Received: from host86-169-144-100.range86-169.btcentralplus.com ([86.169.144.100]:3721 helo=panamint) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:465) with esmtpsa (PLAIN:acn1) (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1iVk2C-000KHq-0n (Exim 4.92.3) (return-path ); Fri, 15 Nov 2019 22:25:44 +0000 Date: Sat, 16 Nov 2019 03:35:00 -0000 From: Arthur Norman To: Brian Inglis cc: cygwin@cygwin.com Subject: Re: linker fails with multiple definitions after inline thread_local var within class In-Reply-To: <769583d7-b1d7-fbc3-15ec-d377163c9d7f@SystematicSw.ab.ca> Message-ID: References: <769583d7-b1d7-fbc3-15ec-d377163c9d7f@SystematicSw.ab.ca> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="48675572-325-1573856745=:112204" X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00098.txt.bz2 --48675572-325-1573856745=:112204 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-length: 6259 > 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. I attach a versiuon of the test with an include guard and with t1.cpp and t2.cpp compiled in separate invocations of g++ - I still see the multiple definition. ${1:-g++} -std=c++17 -I. -c t1.cpp ${1:-g++} -std=c++17 -I. -c t2.cpp ${1:-g++} -std=c++17 t1.o t2.o -o t /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ld: t2.o:t2.cpp:(.text+0x86): multiple definition of `TLS init function for Data::valref'; t1.o:t1.cpp:(.text+0x4a): first defined here collect2: error: ld returned 1 exit status ./t As per my original posting before enquiring here I had tried on a 64-bit ubuntu machine, on a Macbook (where it is clang not g++, but I invoke the compiler as g++) and on a Raspberry pi. The original code I had pain with was with include guards and all files compiled independently via make - the test casee I submitted had perhaps tried to hard to shorten and simplify. I also tried both 32 and 64-bit mingw compilers under cygwin - making that easier is why the test script goes ${1:-g++} so I can override the compiler selection to be x86_64-w64-mingw32-g++ or the i686 variant. Those both show the multiple definition problem. I had also spent some time trying to check in a file c++17-draft-standard.pdf and doing web research on rules regarding static thread_local fields in classes. There is plenty to alert me to the fact that I need to be vary sensitive to issues about exactly when initializers get invoked and in which order, and I spent some time trying to convince myself I had my mind clear on that - but anyway even if I was wrong on that count it would not cause multiple-definitions and linker failure. But I have tried reading up and thinking about initialization order too, but that is not the issue in this query! I have also experimented with g++ options such as -ftls-model=... and -mtls-dialect and not observed any altering the gross behavior. So at present the cygwin g++, i686-w32-mingw32-g++ and x86_64-w64-mingw32-g++ are the cases where this linker clash arises for me but no others, and I have failed to achieve a web-search explaining this as a valid limitation. But I am painfully aware that the C++ standard is complicated enough that I could have missed spottting a paragraph and that my web-searches may not have found the correct keywords to use! > 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. My practical response to this clearly has to be to work around it - but it still seems proper to alert cygwin people to a potential issue on their platform! The relevant code in my real example already conditionalizes on whether the C++ compiletr being used does or does not claim to support inline variables and whether or not it is liable to be on top of Windows - I want it to build and run happily for others more or less regardless - but I am also fairly fussed about performance (which is a reason for C++ not Java, Python etc etc!). > 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. Thank you - that is useful and I will try again directly with gcc-central. It looks as if even if this issue mainly hits on Cygwin that there are at least not a lot of others who have experienced it and felt like jumping in. > 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: > Accepted. But __cpp_inline_variables being defined is advertising support for same! And the gcc page you cite below declares it ok from gcc 7 onwards, and indeed I had looked at the first one! > 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. -std=c++17 and -std=gnu++17 does not change things for me. Indeed my original project was using gnu++17 but to report it I dropped back to -std=c++11 and dropped the -Wall (which does not moan about anything). > 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. > Agreed and accepted quite happily. And it is pretty clear that implementing thread-local on less that helpful platforms involved a deal of pain - the Windows native scheme used in a naive way may not help with destructors and linker support for you is "interestingly" different from that for Linux etc. I think I hope for two things - the first is to see if my code violated some part of the C++ specification that I have not found and hence the tool-chain is entitled to reject it. I tried doing my homework first but the C++ specification is Big and Complicated! The second is that if this is an issue that it has been reported so that it can get addressed in due course. Thank you! Arthur --48675572-325-1573856745=:112204 Content-Type: APPLICATION/octet-stream; name=tltest.sh Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=tltest.sh Content-length: 4079 IyEgL2Jpbi9iYXNoCiMgV2hlbiBJIHJ1biB0aGlzIG9uIFVidW50dS14ODZf NjQsIE1hY2ludG9zaChjbGFuZykgb3IgYSBSYXNwYmVycnkgcGkKIyB0aGUg Y29kZSBsaW5rcyBhbmQgd2hlbiBpdCBydW5zIGl0IGp1c3QgcHJpbnRzIDk5 OSAtIHdoaWNoIGlzIHRoZSBiZWhhdmlvdXIKIyB0aGF0IEkgZXhwZWN0LiBP biBib3RoIEN5Z3dpbiBhbmQgdXNpbmcgeDg2XzY0LXc2NC1taW5ndzMyLWcr KyAgKGFuZCBpNjg2KQojIEkgZ2V0IGEgbGlua2VyIGRpYWdub3N0aWMgb2Yg dGhlIGZvcm0KIyAuL3RsdGVzdC5zaAojIC91c3IvbGliL2djYy94ODZfNjQt cGMtY3lnd2luLzguMy4wLy4uLy4uLy4uLy4uL3g4Nl82NC1wYy1jeWd3aW4v YmluL2xkOgojICAgL3RtcC9jY3pWVGNaMS5vOnQyLmNwcDooLnRleHQrMHg4 Nik6IG11bHRpcGxlIGRlZmluaXRpb24gb2YKIyAgIGBUTFMgaW5pdCBmdW5j dGlvbiBmb3IgRGF0YTo6dmFscmVmJzsKIyAgIC90bXAvY2N5TFFsUmIubzp0 MS5jcHA6KC50ZXh0KzB4NGEpOiBmaXJzdCBkZWZpbmVkIGhlcmUKIyBjb2xs ZWN0MjogZXJyb3I6IGxkIHJldHVybmVkIDEgZXhpdCBzdGF0dXMKIwojIEkg YmVsaWV2ZSB0aGF0IGdpdmVuIHRoZSBzcGVjaWZpY2F0aW9uIG9mIEMrKzE3 ICJpbmxpbmUiIHZhcmlhYmxlcyB0aGlzCiMgaXMgaW5jb3JyZWN0LCBidXQg dGhlcmUgYXJlIGJldHRlciBleHBlcnRzIHdobyBtYXkgYmUgYWJsZSB0byBl eHBsYWluCiMgb3RoZXJ3aXNlLgojCiMgV2hlbiBwZW9wbGUgcmFpc2UgaXNz dWVzIGhlcmUgSSBvZnRlbiBzZWUgb3RoZXIgYXNraW5nICJXaHkgYXJlIHlv dSBkb2luZwojIHRoYXQ/Ii4gVGhpcyBpcyBhIGN1dC1kb3duIHZlcnNpb24g b2YgbXkgcmVhbCBjb2RlIHdoZXJlIHJhdGhlciB0aGFuCiMgc3RvcmluZyBh IHJlZmVyZW5jZSB0byB0aGUgdGhyZWFkX2xvY2FsIFJlY29yZCB0aGF0IEkg YW0gaW50ZXJlc3RlZCBpbgojIGluIGEgc2ltcGxlIGFycmF5ICh0dmVjKSBh dCBhIGZpeGVkIG9mZnNldCAoMSkgSSBzdG9yZSBhbmQgcmV0cmlldmUgYQoj IHJlZmVyZWNlIHRvIGl0IHVzaW5nIFRsc0FsbG9jKCksIFRsc0dldFZhbHVl IGFuZCBUbHNTZXRWYWx1ZSAtIHRob3NlIGJlaW5nCiMgdGhlIE1pY3Jvc29m dCBBUEkgZm9yIHRocmVhZC1sb2NhbCBhY2Nlc3MsIGFuZCBmb3IgbXkgcHVy cG9zZXMgbXkKIyBtZWFzdXJlbWVudHMgc3VnZ2VzdCB0aGF0IHVzaW5nIHRo ZW0gZ2l2ZXMgbWUgdXNlZnVsIHBlcmZvcm1hbmNlIGdhaW5zCiMgb3ZlciB0 aGUgZW11dGxzIGNvZGUgdGhhdCBnKysgY3JlYXRlcyBvbiB0aGUgcmVsZXZh bnQgcGxhdGZvcm1zLgojIEFuZCBJIGFtIHRoZW4gKHRyeWluZyB0bykgYnVp bGQgYSBoZWFkZXItb25seSBsaWJyYXJ5IChmb3Igd2hpY2ggdC5oIGlzCiMg dGhlIHN1cnJvZ2F0ZSBoZXJlKSB3aGljaCBjYW4gYmUgaW5jbHVkZWQgZnJv bSBzZXZlcmFsIG90aGVyIGNvbXBpbGF0aW9uCiMgdW5pdHMgYnV0IGJ5IHZp cnR1ZSBvZiAiaW5saW5lIHZhcmlhYmxlcyIgaXRzIHByaXZhdGUgKGluY2x1 ZGluZyB0aHJlYWQtCiMgbG9jYWwpIGRhdGUgY2FuIGJlIGRlZmluZWQgd2l0 aGluIHRoYXQgaGVhZGVyIGZpbGUgIHNvIHRoYXQgdGhlIGZpbGVzIHRoYXQK IyAjaW5jbHVkZSB0aGUgaGVhZGVyLW9ubHkgbGlicmFyeSBkbyBub3QgbmVl ZCB0byBjb250YWluIGFueXRoaW5nIGJleW9uZAojIHVzZXMgb2YgaXQuIFRv IGlsbHVzdHJhdGUgdGhpcyBJIGhhdmUgdHdvIHNvdXJjZSBmaWxlcyB3aGlj aCBlYWNoIGluY2x1ZGUKIyB0LmggYnV0IHRoZSBiYWQgYmVoYXZpb3VyIGRv ZXMgbm90IG5lZWQgYW55IG90aGVyIGNvZGUgaW4gdGhlIGZpcnN0IG9uZSEK IyBUaGUgc2Vjb25kIGp1c3QgY29udGFpbnMgYSB0aW55IG1haW4gcHJvZ3Jh bSB0aGF0IGluc3BlY3RzIGRhdGEgZnJvbSB0aGUKIyBsaWJyYXJ5IGRhdGEu CgojIEhhdmUgSSBtaXN1bmRlcnN0b29kIEMrKyBhbmQgc28gYW0gSSBkb2lu ZyBzb21ldGhpbmcgd3Jvbmcgb3IgaXMgdGhpcwojIGEgZysrL1dpbmRvd3Mg YnVnPwoKY2F0IDw8WFhYID4gdC5oCiNpZm5kZWYgdF9pbmNsdWRlZAojZGVm aW5lIHRfaW5jbHVkZWQgMQoKI2luY2x1ZGUgPGNzdGRpbnQ+CgppbmxpbmUg dm9pZCAqdHZlY1s0XTsKCmNsYXNzIFJlY29yZAp7CnB1YmxpYzoKICAgIGlu dCB2YWwgPSA5OTk7Cn07CgpjbGFzcyBEYXRhX1JlZgp7ICAgc3RhdGljIGlu bGluZSB0aHJlYWRfbG9jYWwgUmVjb3JkIHZhbDsKcHVibGljOgogICAgc3Rh dGljIFJlY29yZCogZ2V0KCkgIC8vIEdldCByZWZlcmVuY2UgdG8gUmVjb3Jk IHZpYSB0dmVjW10KICAgIHsgICByZXR1cm4gKFJlY29yZCopdHZlY1sxXTsK ICAgIH0KICAgIERhdGFfUmVmKCkgICAgICAgICAgICAvLyBTdGFzaCBpdCBp biB0dmVjW10gZm9yIGxhdGVyIHVzZQogICAgeyAgIHR2ZWNbMV0gPSAodm9p ZCAqKSZ2YWw7CiAgICB9Cn07CgpjbGFzcyBEYXRhCnsgICBzdGF0aWMgaW5s aW5lIHRocmVhZF9sb2NhbCBEYXRhX1JlZiB2YWxyZWY7CnB1YmxpYzoKICAg IHN0YXRpYyBSZWNvcmQgJmdldCgpCiAgICB7ICAgcmV0dXJuICp2YWxyZWYu Z2V0KCk7IC8vIG5vdGUgdGhhdCBnZXQoKSBpcyBzdGF0aWMgaW4gRGF0YV9S ZWYKICAgIH0KfTsKI2VuZGlmIC8vIHRfaW5jbHVkZWQKWFhYCmNhdCA8PFhY WCA+IHQxLmNwcAojaW5jbHVkZSA8aW9zdHJlYW0+CiNpbmNsdWRlICJ0Lmgi ICAvLyBGaXJzdCBjb3B5CgpYWFgKY2F0IDw8WFhYID4gdDIuY3BwCiNpbmNs dWRlIDxpb3N0cmVhbT4KI2luY2x1ZGUgInQuaCIgIC8vIFNlY29uZCBjb3B5 CgppbnQgbWFpbigpCnsgICBzdGQ6OmNvdXQgPDwgRGF0YTo6Z2V0KCkudmFs IDw8IHN0ZDo6ZW5kbDsKICAgIHJldHVybiAwOwp9ClhYWAoKJHsxOi1nKyt9 IC1zdGQ9Z251KysxNyAtSS4gLWMgdDEuY3BwCiR7MTotZysrfSAtc3RkPWdu dSsrMTcgLUkuIC1jIHQyLmNwcAokezE6LWcrK30gLXN0ZD1nbnUrKzE3IHQx Lm8gdDIubyAtbyB0Ci4vdAoKIyBlbmQgb2YgdGVzdCBzY3JpcHQ= --48675572-325-1573856745=:112204 Content-Type: text/plain; charset=us-ascii Content-length: 219 -- 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 --48675572-325-1573856745=:112204--