X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id
	:references:mime-version:content-type; q=dns; s=default; b=cgQPG
	k2eq+nEgTLWBN9SlRahLfYR3IuE35mGeDTOuvRXEdE0uXl5N6bDL9oqDTXiBv/HS
	v6M+3eAfShqJA6Zy9q1Xn7Y5TRt87OcHT0c97CC91lvhdolkYPlM9KpIlFo/h+E3
	16CZ5MUk3iIMaYc+y32GllYtme2pjjKoJGYmrw=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:cc:subject:in-reply-to:message-id
	:references:mime-version:content-type; s=default; bh=PZIYe0xUqFJ
	IAdvyM8EGj5GFrpU=; b=Hesubdy8LVwkY5lleEPiFMkb+BnI72APc9nlGp6HZKy
	NUl13r7g1zPI4WdB4qx6sKOsYV70Qso8lahVK4VzfQMllMW59OAE5bxSper8JoE1
	f5Dpv74lfhSTzwE3E6U5FYnt7Kk2ScSJZLZVkqgmI1GIEftcZP3VorQIMRiAllkA
	=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
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=;
Date:	Fri, 15 Nov 2019 22:25:45 +0000 (GMT Standard Time)
From:	Arthur Norman <acn1 AT cam DOT ac DOT uk>
To:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
cc:	cygwin AT cygwin DOT 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:	<alpine.WNT.2.00.1911151945330.112204@panamint>
References:	<alpine DOT WNT DOT 2 DOT 00 DOT 1911141816490 DOT 14912 AT panamint> <f5b26568-67dc-1dfe-a35b-248f1644aed9 AT SystematicSw DOT ab DOT ca> <alpine DOT WNT DOT 2 DOT 00 DOT 1911150742490 DOT 125704 AT panamint> <769583d7-b1d7-fbc3-15ec-d377163c9d7f AT SystematicSw DOT ab DOT ca>
User-Agent:	Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version:	1.0
X-IsSubscribed:	yes

--48675572-325-1573856745=:112204
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

> 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: <alpine DOT WNT DOT 2 DOT 00 DOT 1911152225450 DOT 112204 AT panamint>
Content-Description: 
Content-Disposition: attachment; filename=tltest.sh

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


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

- Raw text -