On 2024-11-03 11:07, Csaba Ráduly via Cygwin wrote:
On 03/11/2024 15:07, Brian Inglis via Cygwin wrote:
One upstream refuses to support distros that do not support C++20 compilers,
so curl and wget2 will hopefully continue to build with their current package!
Both curl and wget2 are C-only, so
On 03/11/2024 15:07, Brian Inglis via Cygwin wrote:
One upstream refuses to support distros that do not support C++20
compilers,
so curl and wget2 will hopefully continue to build with their current
package!
Both curl and wget2 are C-only, so they are not affected by the ABI
change of std::st
ygwin or online docs mentioning this, until the poster
linked:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html,
when I realised there are docs provided only for gcc/g++, objc/objc++, gccint,
gfortran, libgccjit, libgomp, libquadmath, but nothing for libstdc++, not
Dimitry Andric via Cygwin writes:
> I think most Linux distributions have switched fully to the new ABI by
> now, and dropped support for the old ABI, so they configure their
> gcc's with _GLIBCXX_USE_CXX11_ABI=1 by default.
They also have the luxury of full distro rebuilds every once in a while.
;>317 # define _GLIBCXX_USE_DUAL_ABI 1
>>318
>>319 #if ! _GLIBCXX_USE_DUAL_ABI
>>320 // Ignore any pre-defined value of _GLIBCXX_USE_CXX11_ABI
>>321 # undef _GLIBCXX_USE_CXX11_ABI
>>322 #endif
>>323
>>324 #ifndef _GLIBCXX_U
Ignore any pre-defined value of _GLIBCXX_USE_CXX11_ABI
321 # undef _GLIBCXX_USE_CXX11_ABI
322 #endif
323
324 #ifndef _GLIBCXX_USE_CXX11_ABI
325 # define _GLIBCXX_USE_CXX11_ABI 0
326 #endif
Also, g++ -v shows --with-default-libstdcxx-abi=gcc4-compatible, so I gues
On 30/10/2024 17:00, Dimitry Andric via Cygwin wrote:
#include
#include
constexpr bool foo()
{
std::string str2{"abcwe"};
return str2.size()==5;
}
static_assert(foo());
int main()
{
assert(foo());
}
Seems like _GLIBCXX_USE_CXX11_ABI is not defined by default.
Csaba
--
Life is comp
7 # define _GLIBCXX_USE_DUAL_ABI 1
318
319 #if ! _GLIBCXX_USE_DUAL_ABI
320 // Ignore any pre-defined value of _GLIBCXX_USE_CXX11_ABI
321 # undef _GLIBCXX_USE_CXX11_ABI
322 #endif
323
324 #ifndef _GLIBCXX_USE_CXX11_ABI
325 # define _GLIBCXX_USE_CXX11_ABI 0
326 #endi
On 30 Oct 2024, at 16:06, Brian Inglis via Cygwin wrote:
> Trying to update a package using c++ (requires gcc 12.4+ for adequate c++
> 2020 support) and getting confusing error messages.
>
> It appears that noexcept in the header files may here redefined by the
> compiler or headers as __GLIBC_
sue?
It's used in the gcc c++ headers, defined in c++config.h and part of the
gcc-g++ package. The packaging on Fedora puts this file into the
libstdc++-devel package, which is more helpful, I guess.
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ:
ting cache config.cache
14:22:17.579247 00:00:00.022036 checking for gcc... gcc
14:22:18.401451 00:00:00.822204 checking whether the C compiler works... yes
14:22:19.047309 00:00:00.645858 checking for C compiler default output file
name... a.exe
14:22:19.081731 00:00:00.034422 checking for s
On Mon, 1 Jul 2024 17:43:53 +0900
Takashi Yano wrote:
> On Sun, 30 Jun 2024 22:55:22 +0900
> Takashi Yano wrote:
> > On Sun, 30 Jun 2024 20:33:19 +0900
> > jojelino wrote:
> > > On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:
> > > > Reran cygport --debug upload and command hanging was ssh-add
On Sun, 30 Jun 2024 22:55:22 +0900
Takashi Yano wrote:
> On Sun, 30 Jun 2024 20:33:19 +0900
> jojelino wrote:
> > On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:
> > > Reran cygport --debug upload and command hanging was ssh-add -l!
> > >
> >296 72109 [main] ssh-add 63275 win32env_to_cy
On Sun, 30 Jun 2024 20:33:19 +0900
jojelino wrote:
> On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:
> > Reran cygport --debug upload and command hanging was ssh-add -l!
> >
>296 72109 [main] ssh-add 63275 win32env_to_cygenv: 0xA000232E0:
> TERM_PROGRAM=mintty
>189 72298 [main] s
On 6/29/2024 2:39 PM, Brian Inglis via Cygwin wrote:
Reran cygport --debug upload and command hanging was ssh-add -l!
296 72109 [main] ssh-add 63275 win32env_to_cygenv: 0xA000232E0:
TERM_PROGRAM=mintty
189 72298 [main] ssh-add 63275 win32env_to_cygenv: 0xA00023300:
TERM_PROGRAM_VERSION
Greetings, Brian Inglis via Cygwin!
>> I have experienced otherwise inexplicable hangs of ssh that have been
>> resolved
>> by killing ssh-agent and restarting it. This doesn't happen very often, so
>> it is
>> usually mystifying when it does occur -- until I remember.
> I have *NEVER* had *ANY
On 6/29/2024 8:21 PM, Norton Allen via Cygwin wrote:
On 6/29/2024 5:29 PM, Brian Inglis via Cygwin wrote:
On 2024-06-29 14:20, Norton Allen via Cygwin wrote:
On 6/29/2024 1:39 AM, Brian Inglis via Cygwin wrote:
Installed cygwin test to try to diagnose another issue - but not
involved there.
On 6/29/2024 5:29 PM, Brian Inglis via Cygwin wrote:
On 2024-06-29 14:20, Norton Allen via Cygwin wrote:
On 6/29/2024 1:39 AM, Brian Inglis via Cygwin wrote:
Installed cygwin test to try to diagnose another issue - but not
involved there.
Attempting to cygport upload - just hung without star
On 2024-06-29 14:20, Norton Allen via Cygwin wrote:
On 6/29/2024 1:39 AM, Brian Inglis via Cygwin wrote:
Installed cygwin test to try to diagnose another issue - but not involved there.
Attempting to cygport upload - just hung without start ftp connection.
Reran cygport --debug upload and comman
On 6/29/2024 1:39 AM, Brian Inglis via Cygwin wrote:
Hi folks,
Installed cygwin test to try to diagnose another issue - but not
involved there.
Attempting to cygport upload - just hung without start ftp connection.
Reran cygport --debug upload and command hanging was ssh-add -l!
Confirmed by r
Hi folks,
Installed cygwin test to try to diagnose another issue - but not involved there.
Attempting to cygport upload - just hung without start ftp connection.
Reran cygport --debug upload and command hanging was ssh-add -l!
Confirmed by rerunning command ssh-add -l from bash.
Killed eventually
On 2023-09-24 11:21, Martin Wege via Cygwin wrote:
Hello,
I tried to setuid an executable, so that it runs as user "SYSTEM", but
it does not work.
I tried this as an user with administrator rights:
chown SYSTEM:SYSTEM foo.exe
chmod u+s,g+s foo.exe
But running ./foo then just runs
Hello,
I tried to setuid an executable, so that it runs as user "SYSTEM", but
it does not work.
I tried this as an user with administrator rights:
chown SYSTEM:SYSTEM foo.exe
chmod u+s,g+s foo.exe
But running ./foo then just runs it as the current user.
What am I doing wrong?
Than
Mümin A. via Cygwin wrote:
Hi,
reminder..
Mümin A. , 11 Tem 2023 Sal, 09:47 tarihinde şunu
yazdı:
Hi,
I'm facing a problem while linking my native dll library into the g++
compiler.
There is a name mangling problem when calling a msvc function from g++
compiler therefore linker giv
Hi,
reminder..
Mümin A. , 11 Tem 2023 Sal, 09:47 tarihinde şunu
yazdı:
>
> Hi,
>
> I'm facing a problem while linking my native dll library into the g++
> compiler.
>
> There is a name mangling problem when calling a msvc function from g++
> compiler therefore li
On 11/07/2023 08:47, Mümin A. via Cygwin wrote:
Hi,
I'm facing a problem while linking my native dll library into the g++
compiler.
There is a name mangling problem when calling a msvc function from g++
compiler therefore linker gives an error undefined reference.
Is there any meth
Hi,
I'm facing a problem while linking my native dll library into the g++
compiler.
There is a name mangling problem when calling a msvc function from g++
compiler therefore linker gives an error undefined reference.
Is there any method to directly link and call a function from nativ
On Feb 10 11:42, Norton Allen via Cygwin wrote:
> On 2/9/2023 4:09 PM, Corinna Vinschen wrote:
> > On Feb 9 13:25, Norton Allen via Cygwin wrote:
> > > On 2/8/2023 4:05 PM, Norton Allen via Cygwin wrote:
> > > > [...]
> > > > The problem:
> > &g
users on one
machine can share full control over a particular directory hierarchy.
On Linux I have usually been able to make things work with:
$ mkdir shared_dir
$ chgrp shared_group shared_dir
$ chmod g+ws shared_dir
$ umask 2
User shells are configured with umask 2 so files they
sers on one
> > machine can share full control over a particular directory hierarchy.
> >
> > On Linux I have usually been able to make things work with:
> >
> > $ mkdir shared_dir
> > $ chgrp shared_group shared_dir
> > $ chmod g+ws shared_dir
>
usually been able to make things work with:
$ mkdir shared_dir
$ chgrp shared_group shared_dir
$ chmod g+ws shared_dir
$ umask 2
User shells are configured with umask 2 so files they create have
group write. Users belong to shared_group. Files and subdirs created
under shared_dir are all
shared_dir
$ chgrp shared_group shared_dir
$ chmod g+ws shared_dir
$ umask 2
User shells are configured with umask 2 so files they create have group
write. Users belong to shared_group. Files and subdirs created under
shared_dir are all in group shared_group. Files moved in retain their
On 7/10/2022 10:33 PM, Eliot Moss wrote:
On 7/10/2022 10:17 PM, Chris Wagner wrote:
On 6/29/2022 9:18 AM, Norton Allen wrote:
On one machine I have, chmod g+s fails to set the sticky bit.
The >>> command
does not return any error, but ls -l continues to show the bit
not set.
$
On 7/10/2022 10:17 PM, Chris Wagner wrote:
On 6/29/2022 9:18 AM, Norton Allen wrote:
On one machine I have, chmod g+s fails to set the sticky bit. The >>> command
does not return any error, but ls -l continues to show the bit not set.
$ mkdir foo
$ chgrp flight foo
$ c
On 6/29/2022 9:18 AM, Norton Allen wrote:
On one machine I have, chmod g+s fails to set the sticky bit. The
>>> command
does not return any error, but ls -l continues to show the bit not
set.
$ mkdir foo
$ chgrp flight foo
$ chmod g+ws foo
$ ls -ld foo
drwx
Greetings, Norton Allen!
> On 6/29/2022 9:18 AM, Norton Allen wrote:
>> On 6/29/2022 7:39 AM, Andrey Repin wrote:
>>> Greetings, Norton Allen!
>>>
>>>> On one machine I have, chmod g+s fails to set the sticky bit. The >>>
>>>> command
On 6/29/2022 9:18 AM, Norton Allen wrote:
On 6/29/2022 7:39 AM, Andrey Repin wrote:
Greetings, Norton Allen!
On one machine I have, chmod g+s fails to set the sticky bit. The
command
does not return any error, but ls -l continues to show the bit not set.
$ mkdir foo
$ chgrp flight
On 6/29/2022 7:39 AM, Andrey Repin wrote:
Greetings, Norton Allen!
On one machine I have, chmod g+s fails to set the sticky bit. The command
does not return any error, but ls -l continues to show the bit not set.
$ mkdir foo
$ chgrp flight foo
$ chmod g+ws foo
$ ls -ld foo
Greetings, Norton Allen!
> On one machine I have, chmod g+s fails to set the sticky bit. The command
> does not return any error, but ls -l continues to show the bit not set.
> $ mkdir foo
> $ chgrp flight foo
> $ chmod g+ws foo
> $ ls -ld foo
> drwxrw
On one machine I have, chmod g+s fails to set the sticky bit. The
command does not return any error, but ls -l continues to show the bit
not set.
$ mkdir foo
$ chgrp flight foo
$ chmod g+ws foo
$ ls -ld foo
drwxrwxr-x+ 1 nort flight 0 Jun 29 06:50 foo
I ran strace, and it looks
Greetings, Kevin Schnitzius!
> On Wednesday, January 19, 2022, 12:46:26 AM EST, Marco Atzeri
> Works fine from bash. It reproes from cmd.exe
Then your CMD environment is not set identical to your bash env.
Simple fix - use bash.
--
With best regards,
Andrey Repin
Wednesday, January 26, 2022
please use a decent mail program
On 19.01.2022 21:58, Kevin Schnitzius via Cygwin wrote:
On Wednesday, January 19, 2022, 12:46:26 AM EST, Marco Atzeri wrote:
This works for me from CLI
g++ -Wall prova.cc -o prova
So how are you setting your NetBeans ?
g++ --version> g++ (GCC) 11.
On Wednesday, January 19, 2022, 12:46:26 AM EST, Marco Atzeri
wrote:>> On 19.01.2022 02:06, slipbits wrote:> > g++
(GCC) 10.2.0> > Win 7-64> > Netbeans 12.5> >> > g++ reported a compiler error
in not finding stddef.h referenced in> > stdlib.h. I
On 19.01.2022 02:06, slipbits wrote:
g++ (GCC) 10.2.0
Win 7-64
Netbeans 12.5
g++ reported a compiler error in not finding stddef.h referenced in
stdlib.h. I've looked in /usr/include and /usr/include/c++/v1. I found
an stddef.h in /usr/include/c++/v1. Should I copy this to /usr/in
g++ (GCC) 10.2.0
Win 7-64
Netbeans 12.5
g++ reported a compiler error in not finding stddef.h referenced in
stdlib.h. I've looked in /usr/include and /usr/include/c++/v1. I found
an stddef.h in /usr/include/c++/v1. Should I copy this to /usr/include?
The command being executed
X features as Windows limitations are
> removed.
I'm aware of that and I'm asking these question because I'm working on an
open source project as well (so this is pure voluntarily as well:-),
targeting *nix-system, but we have a task to make it working on Windows as
well and we wer
that
many rather would like it to become more ... like an emulator
> And it wouldn't help you. Or we could ask all Cygwin package maintainers
> to try to patch their packages so that they recognize Win32 paths, but
> that's simply not feasible, nor would many package maintaine
dependant
I guess we need to go out of std::filesystem::canonical though because that
is what fails (and unfortunately I guess there's a real bug in the (real)
g++ distro of because the
std::filesystem::path::generic-functions doesn't work as the standard
mandates either)
Once again,
On 11/24/20 2:01 PM, sten.kristian.ivars...@gmail.com wrote:
[snip]
std::filesystem POSIX mode is common to all POSIX platforms where
backslashes are NOT directory separators. How do you make them accept
your demands? How are you going to force POSIX platforms allow
Windows specific code?
I'v
ng more POSIX
features as Windows limitations are removed.
Other projects gcc-g++, libstdc++ may have sponsored or employed contributors.
They all have their respective standards focus and are uninterested in
non-standard-compliant changes and any non-POSIX build changes.
But they build and
For the specific case C:\Temp, I found this:
cygpath -ua 'C:\Temp'
-> /cygdrive/c/Temp
cygpath -ua /cygdrive/c/Temp
-> /cygdrive/c/Temp
cygpath -ua '\Temp'
-> /cygdrive/c/Temp
cygpath -ua '/Temp'
-> /Temp
Now Cygwin is open source, so you, too, could grab the code in cygpath and
c
hat they recognize Win32 paths, but that's simply
not feasible, nor would many package maintainers be willing to invest the
required time.
I tried it once with emacs, which I maintain, in response to a user request. I
failed miserably. Every change I made broke something else, and I final
> On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote:
>
> > all the std::filesystem implementations I've seen for Windows
>
> The implementation on top of Cygwin is not "for Windows", it's "for
> Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to do.
> And that's where w
> > [snip]
> >
> >> std::filesystem POSIX mode is common to all POSIX platforms where
> >> backslashes are NOT directory separators. How do you make them accept
> >> your demands? How are you going to force POSIX platforms allow
> >> Windows specific code?
> >
> > I've been trying to say over and o
On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote:
all the std::filesystem implementations I've seen for Windows
The implementation on top of Cygwin is not "for Windows", it's "for Cygwin", i.e., "for Posix". And
for Cygwin that's the right thing to do. And that's where we keep talk
On 11/24/20 11:35 AM, sten.kristian.ivars...@gmail.com wrote:
[snip]
std::filesystem POSIX mode is common to all POSIX platforms where
backslashes are NOT directory separators. How do you make them accept your
demands? How are you going to force POSIX platforms allow Windows specific
code?
I'
[snip]
> std::filesystem POSIX mode is common to all POSIX platforms where
> backslashes are NOT directory separators. How do you make them accept your
> demands? How are you going to force POSIX platforms allow Windows specific
> code?
I've been trying to say over and over again that our code do
On 11/24/20 9:32 AM, sten.kristian.ivars...@gmail.com wrote:
That's not what Cygwin is for, you ignore everything while conveniently
claiming to be looking for "insightful thoughts". You still haven't
answered where is it in the POSIX standard requires backslashes to be used
as separator or how
> On 11/23/20 8:35 AM, sten.kristian.ivars...@gmail.com wrote:
> >> On 11/20/20 8:31 AM, Kristian Ivarsson via Cygwin wrote:
> that, for me, /c works.) Likewise, I would expect the normative
> path separator to be / not \, and an absolute path to start with /.
> Windows offers sever
On 11/23/20 8:35 AM, sten.kristian.ivars...@gmail.com wrote:
On 11/20/20 8:31 AM, Kristian Ivarsson via Cygwin wrote:
that, for me, /c works.) Likewise, I would expect the normative path
separator to be / not \, and an absolute path to start with /.
Windows offers several kinds of symlinks, wit
On 11/20/20 8:31 AM, Kristian Ivarsson via Cygwin wrote:
that, for me, /c works.) Likewise, I would expect the normative path
separator to be / not \, and an absolute path to start with /. Windows
offers several kinds of symlinks, with varying semantics, so the detailed
behavior of that would b
[snip]
> > Applications might wanna extract type, name, parent-folder, etc but do
> > rarely care about what kind of separator it has (/ or \) and the style
> > of the root directory etc and it would be very neat if the cygwin
> > std::filesystem-library became more agnostic in these regards
> Not
On 2020-11-20 02:37, Kristian Ivarsson via Cygwin wrote:
[snip]
As stated earlier, it seems like using mingw g++/libstdc++ (from the
cygwin-package-manager) it seems like it works better, but then you
can’t mix with other posix/cygwin mechanism (that uses cygstdc++)
without breaking ODR (and
[snip]
> >> As stated earlier, it seems like using mingw g++/libstdc++ (from the
> >> cygwin-package-manager) it seems like it works better, but then you
> >> can’t mix with other posix/cygwin mechanism (that uses cygstdc++)
> >> without breaking ODR (and pro
> Ok, first, I admit that I was not familiar with the details of
> std::filesystem. However, after looking at it, I remain unsurprised that
> the Cygwin and Mingw versions might be different. (I would also not be
> surprised if there is a real bug in there.)
At least semantic bugs considering th
Ok, first, I admit that I was not familiar with the details of std::filesystem. However, after
looking at it, I remain unsurprised that the Cygwin and Mingw versions might be different. (I would
also not be surprised if there is a real bug in there.) The behavior I would _expect_ is that the
defects and flaws in the cygwin-package and pretty much every
lexical- and canonical operation works in mysterious ways (or not
at all)
https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32
As stated earlier, it seems like using mingw g++/libstdc++ (from the
cygwin-package-manager) it seems
as a part of C++17 seems to have some
> >>>> defects and flaws in the cygwin-package and pretty much every
> >>>> lexical- and canonical operation works in mysterious ways (or not
> >>>> at all)
> >>> [snip]
> >>>
> >>
g but we expect a deterministic behaviour from that library regardless of
operating system, such as and absolute path should be an absolute path
regardless
That's the sole purpose of std::filesystem, i.e. to be platform independent
(though all file-features is not applicable on all operating
On 2020-11-18 17:08, Doug Henderson via Cygwin wrote:
On Wed, 18 Nov 2020 at 13:50, Kristian Ivarsson wrote:
The only purpose CYGWIN have is to make/build posix-applications runnable
on Windows and applications usually have user defined input, such as paths
etc, and on Windows that input is usu
On Wed, 18 Nov 2020 at 13:50, Kristian Ivarsson via Cygwin
wrote:
>
>
> The only purpose CYGWIN have is to make/build posix-applications runnable on
> Windows and applications usually have user defined input, such as paths etc,
> and on Windows that input is usually Windows-native-paths unless
On 11/18/2020 4:18 PM, Kristian Ivarsson wrote:
I would agree that if you want an executable that acts and feels more like a
Windows native application, then mingw is probably what you want. Cygwin is if
you want something that acts and feels more like a Posix thing ... which means
it will
On 11/18/2020 3:46 PM, Kristian Ivarsson via Cygwin wrote:
Is there any other use cases for CYGWIN than to build applications running in
Windows ? Do people use CYGWIN (shell) to operate or monitor their applications
? For all other use cases than the development (the shell) I cannot see why
C
> I would agree that if you want an executable that acts and feels more like a
> Windows native application, then mingw is probably what you want. Cygwin is
> if you want something that acts and feels more like a Posix thing ... which
> means it will be oriented to Posix style paths.
To be ab
I would agree that if you want an executable that acts and feels more like a Windows native
application, then mingw is probably what you want. Cygwin is if you want something that acts and
feels more like a Posix thing ... which means it will be oriented to Posix style paths.
EM
--
Problem rep
ibrary can always go from undefined to defined without breaking changes,
so does anyone know what the effort could be to fix this, i.e. make it work
transparently/agnostic ?
As stated earlier, it seems like using mingw g++/libstdc++ (from the
cygwin-package-manager) it seems like it works bett
On 11/18/2020 11:24 AM, René Berber via Cygwin wrote:
Cygwin handles the file system with no problem, but using Posix-like notation, not Windows-like.
End of story.
And I'll add, this is by design: Cygwin's goal is to provide a programming (and command line)
environment as much like Posix as
On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote:
On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:
The filesystem-library as a part of C++17 seems to have some defects
and flaws in the cygwin-package and pretty much every lexical- and
canonical operation works in mysterious
> On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:
>
> > The filesystem-library as a part of C++17 seems to have some defects
> > and flaws in the cygwin-package and pretty much every lexical- and
> > canonical operation works in mysterious ways (or not at all)
> [snip]
>
> https://cygw
On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote:
The filesystem-library as a part of C++17 seems to have some defects and
flaws in the cygwin-package and pretty much every lexical- and canonical
operation works in mysterious ways (or not at all)
[snip]
https://cygwin.com/cygwin-ug-ne
Hi folks
The filesystem-library as a part of C++17 seems to have some defects and
flaws in the cygwin-package and pretty much every lexical- and canonical
operation works in mysterious ways (or not at all)
Following output with g++cygwin
$ uname -a
CYGWIN_NT-10.0 JOKK 3.1.7(0.340/5/3) 2020
On Sun, Apr 12, 2020 at 12:04 PM JonY via Cygwin wrote:
>
> Please file a bug entry on https://gcc.gnu.org/bugzilla/, and attach the
> preprocessed source code.
>
> Do something like:
> g++ -DHAVE_CONFIG_H -MF .deps/cdo-cdo.Tpo -E -o cdo-cdo.ii
> ../../cd
On 4/12/20 11:39 AM, John Selbie wrote:
> I would file a bug, but that link you provided takes me to a sign-up page
> that says, "Account creation restricted. Please contact ... response
> within 24 hours..."
>
> A quick cursory glace of GCC sources would suggest the issue is in
> \gcc\coverage.c
I would file a bug, but that link you provided takes me to a sign-up page
that says, "Account creation restricted. Please contact ... response
within 24 hours..."
A quick cursory glace of GCC sources would suggest the issue is in
\gcc\coverage.c. This is a snippit of a function that builds the ma
On 4/12/20 10:59 AM, John Selbie via Cygwin wrote:
> Sure, but this bug is unique to cygwin. Why would that be there bug?
>
Because Cygwin does not modify gcc to use Windows paths.
signature.asc
Description: OpenPGP digital signature
--
Problem reports: https://cygwin.com/problems.html
F
Sure, but this bug is unique to cygwin. Why would that be there bug?
On Sun, Apr 12, 2020 at 2:57 AM JonY via Cygwin wrote:
> On 4/12/20 7:27 AM, John Selbie via Cygwin wrote:
> > TLDR: With gcc/g++ 9.2.0 and 9.30 on Cygwin, when you use
> > -fprofile-generate and -fprofile-di
ad/21529/cdo-1.9.9rc2.tar.gz
>
> ./configure
> make
>
>
> Entering directory '/cygdrive/d/cyg_pub/devel/cdo/cdo-1.9.9rc2_build/src'
> g++ -DHAVE_CONFIG_H -I. -I../../cdo-1.9.9rc2/src
> -I../../cdo-1.9.9rc2/libcdi/src -I../../cdo-1.9.9rc2/src/mpim_grid
> -I/usr/i
On 4/12/20 7:27 AM, John Selbie via Cygwin wrote:
> TLDR: With gcc/g++ 9.2.0 and 9.30 on Cygwin, when you use
> -fprofile-generate and -fprofile-dir together, the target path for the
> .gcda file is corrupted with a backslash instead of having a forward slash
> used.
>
> Here&#x
TLDR: With gcc/g++ 9.2.0 and 9.30 on Cygwin, when you use
-fprofile-generate and -fprofile-dir together, the target path for the
.gcda file is corrupted with a backslash instead of having a forward slash
used.
Here's a sample run where profile guided optimization is getting enabled
for a s
g_pub/devel/cdo/cdo-1.9.9rc2_build/src'
g++ -DHAVE_CONFIG_H -I. -I../../cdo-1.9.9rc2/src
-I../../cdo-1.9.9rc2/libcdi/src -I../../cdo-1.9.9rc2/src/mpim_grid
-I/usr/include/libxml2 -g -O2 -fopenmp -MT cdo-cdo.o -MD -MP -MF
.deps/cdo-cdo.Tpo -c -o cdo-cdo.o `test -f 'cdo.cc' || echo
Hi cygwin users,
today I saw an issue when trying to use profile guided optimization of g++
(9.3.0) inside cygwin 3.1.4 with path specified
uname -a gives
CYGWIN_NT-10.0 3.1.4(0.340/5 /3) 2020-02-19 x86_64 Cygwin
More specificaly if I try to give a path argument like
-fprofile-generate
Relevant package versions (all the current latest):
* Cygwin: 3.1.4
* binutils: 2.43+1git.de9c1b7cfe-1
* gcc-core, gcc-g++, libgcc1, libstdc++6: 9.3.0-1
Sample program (foo.cc):
#include
using namespace std;
int
main(void)
{
cout << "OK" << endl;
retur
s for implicit int.
>>
>> It is unfortunate, and arguably a bug, that this means that
>> "g++ -std=c++11 -pedantic" fails to diagnose implicit int errors.
>> I'm not sure whether this is a bug in gcc or in the way Windows
>> versions of gcc are buil
arguably a bug, that this means that
> "g++ -std=c++11 -pedantic" fails to diagnose implicit int errors.
> I'm not sure whether this is a bug in gcc or in the way Windows
> versions of gcc are built.
In the case of Cygwin it is quite certainly a bug as Cygwin is not a
Windows t
apparently inhibits any diagnostics for implicit int.
It is unfortunate, and arguably a bug, that this means that
"g++ -std=c++11 -pedantic" fails to diagnose implicit int errors.
I'm not sure whether this is a bug in gcc or in the way Windows
versions of gcc are built.
Meanwhile, th
See https://stackoverflow.com/q/56519330/827263 posted by user Fureeish
g++ on Cygwin does not diagnose an implicit int error.
The same version of g++ on Ubuntu correctly diagnoses the error.
(I had initially thought that g++ was defaulting to "-fpermissive",
but that would change
duckduckgo for,
>> >
>> > cygwin how to uninstall gcc after building it
>> >
>> > and found nothing that could help me. Right now I have two installs of
>> > gcc: v7.4.and v6.4.0.
>
>That is not necessarily a problem. "Hand-built" GCC u
g it
> >
> > and found nothing that could help me. Right now I have two installs of
> > gcc: v7.4.and v6.4.0.
That is not necessarily a problem. "Hand-built" GCC usually gets
installed into /usr/local (so g++-6 is /usr/local/bin/g++), whereas
the built-in GCC is
On 5/18/19 9:24 PM, Jose Isaias Cabrera wrote:
How do I uninstall the installation that I created with the building of gcc6? I
did a search on duckduckgo for,
cygwin how to uninstall gcc after building it
and found nothing that could help me. Right now I have two installs of gcc:
v7.4.and v6
From: cygwin-ow...@cygwin.com on behalf of Jose
Isaias Cabrera
Sent: Saturday, May 18, 2019 07:15 PM
To: Ken Brown; cygwin@cygwin.com
Subject: Re: How to install gcc and g++ 6 on cygwin which are not on the
setup.exe
Ken Brown, on Saturday, May 18, 2019 11:54 AM, wrote...
>On 5/18/2019 8:19
1 - 100 of 1073 matches
Mail list logo
