Re: "/usr/bin/boxes" command fails to run, Windows 10, CYGWIN_NT-10.0 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64

2019-11-15 Thread Jari Aalto 
On 2019-11-14 21:31, Ken Brown wrote:
> On 11/14/2019 2:32 PM, Keith Christian wrote:
> > The "boxes" command fails to run on a Cygwin64 install two weeks ago.
> > 
> > echo "hello" | /usr/bin/boxes
> > boxes: No such file or directory
> 
> Running boxes under strace shows that it is trying to open a file named "-" 
> and 
> exiting because that file doesn't exist.
> 
> The version of boxes in the Cygwin distro is very old, so I don't think it's 
> worth the trouble to debug this.  I just downloaded and built the latest 
> release, and it seems to work fine.
> 
> I've added the boxes maintainer to the Cc in case he wants to update the 
> package.

Fixed. Latest release uploaded.

Thanks,
Jari

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

Re: "/usr/bin/boxes" command fails to run, Windows 10, CYGWIN_NT-10.0 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64

2019-11-15 Thread Keith Christian 
On Fri, Nov 15, 2019 at 1:15 AM Jari Aalto  wrote:
>
> On 2019-11-14 21:31, Ken Brown wrote:
> > On 11/14/2019 2:32 PM, Keith Christian wrote:
> > > The "boxes" command fails to run on a Cygwin64 install two weeks ago.
> > >
> > > echo "hello" | /usr/bin/boxes
> > > boxes: No such file or directory
> >
> > Running boxes under strace shows that it is trying to open a file named "-" 
> > and
> > exiting because that file doesn't exist.
> >
> > The version of boxes in the Cygwin distro is very old, so I don't think it's
> > worth the trouble to debug this.  I just downloaded and built the latest
> > release, and it seems to work fine.
> >
> > I've added the boxes maintainer to the Cc in case he wants to update the 
> > package.
>
> Fixed. Latest release uploaded.
>
> Thanks,
> Jari


Thanks, Jari!

=== Keith

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

"/usr/bin/tar.exe" hangs, Windows 10, CYGWIN_NT-10.0 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64

2019-11-15 Thread Keith Christian 
Tar in recent updates to Cygwin64 hangs.

When the tar command is run with strace, it generates voluminous
output but won't list tar file contents or extract the tar file (or
tar.gz, tar.xz, etc.)

tar --version
tar (GNU tar) 1.29
Packaged by Cygwin (1.29-1)
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.

ls -l /usr/bin/tar.exe
-rwxr-xr-x 1 kchris Domain Users 424979 Dec  8  2016 /usr/bin/tar.exe


Could someone check this please?

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

Re: "/usr/bin/tar.exe" hangs, Windows 10, CYGWIN_NT-10.0 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64

2019-11-15 Thread Ken Brown 
On 11/15/2019 9:19 AM, Keith Christian wrote:
> Tar in recent updates to Cygwin64 hangs.
> 
> When the tar command is run with strace, it generates voluminous
> output but won't list tar file contents or extract the tar file (or
> tar.gz, tar.xz, etc.)
> 
> tar --version
> tar (GNU tar) 1.29
> Packaged by Cygwin (1.29-1)
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later .
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by John Gilmore and Jay Fenlason.
> 
> ls -l /usr/bin/tar.exe
> -rwxr-xr-x 1 kchris Domain Users 424979 Dec  8  2016 /usr/bin/tar.exe
> 
> 
> Could someone check this please?

Works for me.  Could you have some anti-virus software that's interfering?  
Look 
for suspicious DLLs in the strace output.

Ken

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

Re: "/usr/bin/tar.exe" hangs, Windows 10, CYGWIN_NT-10.0 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64

2019-11-15 Thread Keith Christian 
On Fri, Nov 15, 2019 at 7:40 AM Ken Brown  wrote:
>
> On 11/15/2019 9:19 AM, Keith Christian wrote:
> > Tar in recent updates to Cygwin64 hangs.
> >
> > When the tar command is run with strace, it generates voluminous
> > output but won't list tar file contents or extract the tar file (or
> > tar.gz, tar.xz, etc.)
> >
> > tar --version
> > tar (GNU tar) 1.29
> > Packaged by Cygwin (1.29-1)
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later 
> > .
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
> >
> > Written by John Gilmore and Jay Fenlason.
> >
> > ls -l /usr/bin/tar.exe
> > -rwxr-xr-x 1 kchris Domain Users 424979 Dec  8  2016 /usr/bin/tar.exe
> >
> >
> > Could someone check this please?
>
> Works for me.  Could you have some anti-virus software that's interfering?  
> Look
> for suspicious DLLs in the strace output.
>
> Ken

Ken, thanks for replying.

These are the DLL's in the strace output, expanded with "ldd."  I
don't see anything out of the ordinary.

Is there a list of DLL's known to cause problems with Cygwin?

How would I better isolate the problem causing DLL?  Specific verbiage
in the strace output?  Should I run strace with the "-a" option?

 1  CRYPTBASE.DLL =>
/cygdrive/c/WINDOWS/SYSTEM32/CRYPTBASE.DLL (0x7fff42b5)
 2  KERNEL32.DLL =>
/cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7fff452d)
 3  KERNELBASE.dll =>
/cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7fff435f)
 4  RPCRT4.dll => /cygdrive/c/WINDOWS/System32/RPCRT4.dll
(0x7fff4607)
 5  SYSFER.DLL => /cygdrive/c/WINDOWS/System32/SYSFER.DLL
(0x5a0b)
 6  advapi32.dll =>
/cygdrive/c/WINDOWS/System32/advapi32.dll (0x7fff4553)
 7  bcryptPrimitives.dll =>
/cygdrive/c/WINDOWS/System32/bcryptPrimitives.dll (0x7fff4402)
 8  bcryptprimitives.dll =>
/cygdrive/c/WINDOWS/System32/bcryptprimitives.dll (0x7fff4402)
 9  cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3ba9e)
10  cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
11  msvcrt.dll => /cygdrive/c/WINDOWS/System32/msvcrt.dll
(0x7fff444c)
12  ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(0x7fff462a)
13  psapi.dll => /cygdrive/c/WINDOWS/System32/psapi.dll
(0x7fff4479)
14  rpcrt4.dll => /cygdrive/c/WINDOWS/System32/rpcrt4.dll
(0x7fff4607)
15  sechost.dll =>
/cygdrive/c/WINDOWS/System32/sechost.dll (0x7fff447a)


= Keith

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

Re: "/usr/bin/tar.exe" hangs, Windows 10, CYGWIN_NT-10.0 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64

2019-11-15 Thread Ken Brown 
On 11/15/2019 10:12 AM, Keith Christian wrote:
> On Fri, Nov 15, 2019 at 7:40 AM Ken Brown  wrote:
>>
>> On 11/15/2019 9:19 AM, Keith Christian wrote:
>>> Tar in recent updates to Cygwin64 hangs.
>>>
>>> When the tar command is run with strace, it generates voluminous
>>> output but won't list tar file contents or extract the tar file (or
>>> tar.gz, tar.xz, etc.)
>>>
>>> tar --version
>>> tar (GNU tar) 1.29
>>> Packaged by Cygwin (1.29-1)
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later 
>>> .
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>>
>>> Written by John Gilmore and Jay Fenlason.
>>>
>>> ls -l /usr/bin/tar.exe
>>> -rwxr-xr-x 1 kchris Domain Users 424979 Dec  8  2016 /usr/bin/tar.exe
>>>
>>>
>>> Could someone check this please?
>>
>> Works for me.  Could you have some anti-virus software that's interfering?  
>> Look
>> for suspicious DLLs in the strace output.
>>
>> Ken
> 
> Ken, thanks for replying.
> 
> These are the DLL's in the strace output, expanded with "ldd."  I
> don't see anything out of the ordinary.

I don't either.

> Is there a list of DLL's known to cause problems with Cygwin?

Not that I know of.  But there is the BLODA list 
(https://cygwin.com/faq/faq.html#faq.using.bloda).  Have you checked that?

If you want to post the strace output somewhere or send it to me off-list, I'll 
see if I notice anything unusual.  Posting it somewhere is better, so that 
others can look also.

Ken

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

Re: "/usr/bin/tar.exe" hangs, Windows 10, CYGWIN_NT-10.0 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64

2019-11-15 Thread Brian Inglis 
On 2019-11-15 08:12, Keith Christian wrote:
> On Fri, Nov 15, 2019 at 7:40 AM Ken Brown wrote:
>> On 11/15/2019 9:19 AM, Keith Christian wrote:
>>> Tar in recent updates to Cygwin64 hangs.
>>> When the tar command is run with strace, it generates voluminous
>>> output but won't list tar file contents or extract the tar file (or
>>> tar.gz, tar.xz, etc.)
>>> $ tar --version
>>> tar (GNU tar) 1.29
>>> Packaged by Cygwin (1.29-1)
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later 
>>> .
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> Written by John Gilmore and Jay Fenlason.
>>> $ ls -l /usr/bin/tar.exe
>>> -rwxr-xr-x 1 kchris Domain Users 424979 Dec  8  2016 /usr/bin/tar.exe
>>> Could someone check this please?

$ TZ=UTC ls -glo --full /bin/tar
-rwxr-xr-x 1 424979 2016-12-09 03:57:55.0 + /bin/tar

so not a recent Cygwin update.

>> Works for me.  Could you have some anti-virus software that's interfering?  
>> Look
>> for suspicious DLLs in the strace output.

> These are the DLL's in the strace output, expanded with "ldd."  I
> don't see anything out of the ordinary.
> 
> Is there a list of DLL's known to cause problems with Cygwin?
> 
> How would I better isolate the problem causing DLL?  Specific verbiage
> in the strace output?  Should I run strace with the "-a" option?

This is normal output:

$ ldd /bin/tar
ntdll.dll => /proc/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 
(0x7ff93d53)
KERNEL32.DLL => /proc/cygdrive/c/WINDOWS/System32/KERNEL32.DLL
(0x7ff93abf)
KERNELBASE.dll => /proc/cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(0x7ff93a31)
cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3d8c5)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3c823)

>  1  CRYPTBASE.DLL =>

>  4  RPCRT4.dll => /cygdrive/c/WINDOWS/System32/RPCRT4.dll
> (0x7fff4607)
>  5  SYSFER.DLL => /cygdrive/c/WINDOWS/System32/SYSFER.DLL
> (0x5a0b)
>  6  advapi32.dll =>
> /cygdrive/c/WINDOWS/System32/advapi32.dll (0x7fff4553)
>  7  bcryptPrimitives.dll =>
> /cygdrive/c/WINDOWS/System32/bcryptPrimitives.dll (0x7fff4402)
>  8  bcryptprimitives.dll =>
> /cygdrive/c/WINDOWS/System32/bcryptprimitives.dll (0x7fff4402)

> 11  msvcrt.dll => /cygdrive/c/WINDOWS/System32/msvcrt.dll
> (0x7fff444c)

> 13  psapi.dll => /cygdrive/c/WINDOWS/System32/psapi.dll
> (0x7fff4479)
> 14  rpcrt4.dll => /cygdrive/c/WINDOWS/System32/rpcrt4.dll
> (0x7fff4607)
> 15  sechost.dll =>

SYSFER.DLL is Broadcom/Symantec Endpoint Protection (SEP) AV/BLODA, which pulls
in all this other stuff, including MS VC RT, to clash with Cygwin, while
reporting back to corporate, hogging CPU and I/O to do so, slowing your system
to a crawl.

Uninstall it, bypass checking under the Cygwin tree, or don't use Cygwin.
If you feel a need for protection, Windows Defender is adequate; most AV
products are overkill, and kill system performance.

If this is in an org, complain (to your and their manager/VP) about the
interference stopping you doing your work, and make them fix it, so they
remember to do so in future, otherwise you may have problems and have to
complain and wait every time they upgrade.

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

Re: linker fails with multiple definitions after inline thread_local var within class

2019-11-15 Thread Brian Inglis 
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

Re: "/usr/bin/tar.exe" hangs, Windows 10, CYGWIN_NT-10.0 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64

2019-11-15 Thread Keith Christian 
On Fri, Nov 15, 2019 at 10:34 AM Brian Inglis
 wrote:
>
> On 2019-11-15 08:12, Keith Christian wrote:
> > On Fri, Nov 15, 2019 at 7:40 AM Ken Brown wrote:
> >> On 11/15/2019 9:19 AM, Keith Christian wrote:
> >>> Tar in recent updates to Cygwin64 hangs.
> >>> When the tar command is run with strace, it generates voluminous
> >>> output but won't list tar file contents or extract the tar file (or
> >>> tar.gz, tar.xz, etc.)
> >>> $ tar --version
> >>> tar (GNU tar) 1.29
> >>> Packaged by Cygwin (1.29-1)
> >>> Copyright (C) 2015 Free Software Foundation, Inc.
> >>> License GPLv3+: GNU GPL version 3 or later 
> >>> .
> >>> This is free software: you are free to change and redistribute it.
> >>> There is NO WARRANTY, to the extent permitted by law.
> >>> Written by John Gilmore and Jay Fenlason.
> >>> $ ls -l /usr/bin/tar.exe
> >>> -rwxr-xr-x 1 kchris Domain Users 424979 Dec  8  2016 /usr/bin/tar.exe
> >>> Could someone check this please?
>
> $ TZ=UTC ls -glo --full /bin/tar
> -rwxr-xr-x 1 424979 2016-12-09 03:57:55.0 + /bin/tar
>
> so not a recent Cygwin update.
>
> >> Works for me.  Could you have some anti-virus software that's interfering? 
> >>  Look
> >> for suspicious DLLs in the strace output.
>
> > These are the DLL's in the strace output, expanded with "ldd."  I
> > don't see anything out of the ordinary.
> >
> > Is there a list of DLL's known to cause problems with Cygwin?
> >
> > How would I better isolate the problem causing DLL?  Specific verbiage
> > in the strace output?  Should I run strace with the "-a" option?
>
> This is normal output:
>
> $ ldd /bin/tar
> ntdll.dll => /proc/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll 
> (0x7ff93d53)
> KERNEL32.DLL => /proc/cygdrive/c/WINDOWS/System32/KERNEL32.DLL
> (0x7ff93abf)
> KERNELBASE.dll => /proc/cygdrive/c/WINDOWS/System32/KERNELBASE.dll
> (0x7ff93a31)
> cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
> cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3d8c5)
> cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3c823)
>
> >  1  CRYPTBASE.DLL =>
>
> >  4  RPCRT4.dll => /cygdrive/c/WINDOWS/System32/RPCRT4.dll
> > (0x7fff4607)
> >  5  SYSFER.DLL => /cygdrive/c/WINDOWS/System32/SYSFER.DLL
> > (0x5a0b)
> >  6  advapi32.dll =>
> > /cygdrive/c/WINDOWS/System32/advapi32.dll (0x7fff4553)
> >  7  bcryptPrimitives.dll =>
> > /cygdrive/c/WINDOWS/System32/bcryptPrimitives.dll (0x7fff4402)
> >  8  bcryptprimitives.dll =>
> > /cygdrive/c/WINDOWS/System32/bcryptprimitives.dll (0x7fff4402)
>
> > 11  msvcrt.dll => /cygdrive/c/WINDOWS/System32/msvcrt.dll
> > (0x7fff444c)
>
> > 13  psapi.dll => /cygdrive/c/WINDOWS/System32/psapi.dll
> > (0x7fff4479)
> > 14  rpcrt4.dll => /cygdrive/c/WINDOWS/System32/rpcrt4.dll
> > (0x7fff4607)
> > 15  sechost.dll =>
>
> SYSFER.DLL is Broadcom/Symantec Endpoint Protection (SEP) AV/BLODA, which 
> pulls
> in all this other stuff, including MS VC RT, to clash with Cygwin, while
> reporting back to corporate, hogging CPU and I/O to do so, slowing your system
> to a crawl.
>
> Uninstall it, bypass checking under the Cygwin tree, or don't use Cygwin.
> If you feel a need for protection, Windows Defender is adequate; most AV
> products are overkill, and kill system performance.
>
> If this is in an org, complain (to your and their manager/VP) about the
> interference stopping you doing your work, and make them fix it, so they
> remember to do so in future, otherwise you may have problems and have to
> complain and wait every time they upgrade.
>
> --
> Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada


Brian,

Thanks very much for the information.  I should have run "strings" on
all of the DLL's and then I would have seen that.
This is a corporate PC so little chance of doing any uninstalls or modification.
At least I know why now, and you've given me some ideas about troublesome DLL's.

 Keith

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

Re: linker fails with multiple definitions after inline thread_local var within class

2019-11-15 Thread Arthur Norman 

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 wit

Re: linker fails with multiple definitions after inline thread_local var within class

2019-11-15 Thread Brian Inglis 
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

Re: linker fails with multiple definitions after inline thread_local var within class

2019-11-15 Thread Brian Inglis 
On 2019-11-15 20:35, Brian Inglis wrote:
> 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.

OTOH:   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697#c20

> 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