public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
Cc: cygwin@cygwin.com
Subject: Re: linker fails with multiple definitions after inline thread_local var within class
Date: Sat, 16 Nov 2019 03:54:00 -0000	[thread overview]
Message-ID: <b2d8a9db-a736-4b5a-bd83-d131b24e094a@SystematicSw.ab.ca> (raw)
In-Reply-To: <alpine.WNT.2.00.1911151945330.112204@panamint>

On 2019-11-15 15:25, Arthur Norman wrote:
>> 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.

Sorry missed that.

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

That points to a common problem with the loader generating Windows PEs: it is
possible that is a Windows limitation.
As ld is part of binutils, you might want to try searching and posting on that
mailing list, conveniently located just next door:

	https://sourceware.org/binutils/
	http://sourceware.org/ml/binutils/
	http://lists.gnu.org/archive/html/bug-binutils/

before looking further at gcc.

Please emphasize clearly that this works successfully with ELF executables on
Unix platforms, and list those; and ld fails only with Windows (PE) executables
using Cygwin and Mingw 32/64 tool chains, and list those; and include the test
code, commands and results on each platform, to clearly demonstrate the issue.
Use a specific subject to get appropriate attention and a relevant response e.g.
"ld fails only for Windows PE with multiple definition of TLS init function".

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

  reply	other threads:[~2019-11-16  3:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-14 18:41 Arthur Norman
2019-11-14 23:45 ` Brian Inglis
2019-11-15  8:14   ` Arthur Norman
2019-11-15 22:07     ` Brian Inglis
2019-11-16  3:35       ` Arthur Norman
2019-11-16  3:54         ` Brian Inglis [this message]
2019-11-16 10:48           ` Brian Inglis
2019-11-17 21:05             ` Arthur Norman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b2d8a9db-a736-4b5a-bd83-d131b24e094a@SystematicSw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).