Mail Archives: cygwin/2019/11/15/13:39:53
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
- Raw text -