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
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 gives
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
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 method
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 native dll
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
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
20:32, Ken Brown via Cygwin-apps wrote:
Here are patches...
* 0002-gobject-introspection-1.54.1-4.patch:
python3.8 is used explicitly.
Shebangs of g-ir-doc-tool and g-ir-scanner are '/usr/bin/env
python3.8'
_giscanner.dll is linked with libpython3.8.dll
* 0001-Fix
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,
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've
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/include
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 is 'c
bute__((__aligned__(__alignof(__float128;' at '__float128'
This is 'expected', since (this version of?) g-ir-compiler doesn't know
about __float128 as a built-in type.
There's no input which can legitimately make gcc terminate with segv, so
trying to blame this on gobject-introspection is inc
On 23/05/2021 00:44, Lemures Lemniscati via Cygwin-apps wrote:
And with them, following build and test by cygport has succeeded
both in x86_64 and i686, on my local machine.
cygport gobject-introspection.cygport download finish all test
But on scallywag, only x86_64 build is successful:
nked with python2, but the shbang names 'python',
> >> which is now python3.
> >>
> >> I have been working on rebuilding this package, but not quite there yet.
> >>
> >> You can work around this by fixing the shebang in /usr/bin/g-ir-scanner to
&g
is linked with python2, but the shbang names 'python', which is
now python3.
I have been working on rebuilding this package, but not quite there yet.
You can work around this by fixing the shebang in /usr/bin/g-ir-scanner to
explicitly name python3.
Here are patches...
* 0002-gobject-introspect
en Brown via Cygwin-apps wrote:
>
> >>
> >> Here are patches...
> >>
> >> * 0002-gobject-introspection-1.54.1-4.patch:
> >> python3.8 is used explicitly.
> >> Shebangs of g-ir-doc-tool and g-ir-scanner are '/usr/bin/env
> >> py
le.am 2020-08-04
09:49:26.122659100 -0400
@@ -68,7 +68,7 @@ endif
libregress_la_LDFLAGS = $(AM_LDFLAGS)
-if OS_WIN32
+if PLATFORM_WIN32
AM_LDFLAGS += -no-undefined
endif
@@ -155,7 +155,7 @@ barapp_SOURCES = $(srcdir)/barapp.c $(sr
barapp_LDADD = $(top_builddir)/libgirepository-1.0.la
barapp_LD
is used explicitly.
Shebangs of g-ir-doc-tool and g-ir-scanner are '/usr/bin/env
python3.8'
_giscanner.dll is linked with libpython3.8.dll
* 0001-Fix-a-patch-for-giscanner-shlibs.py-to-pass-a-pep8-c.patch:
This has no effect while building.
But needed in order to avoid
is linked with python2, but the shbang names 'python', which is
now python3.
I have been working on rebuilding this package, but not quite there yet.
You can work around this by fixing the shebang in /usr/bin/g-ir-scanner to
explicitly name python3.
Here are patches...
* 0002-gobject-introspect
ction package.
>
> _giscanner.dll is linked with python2, but the shbang names 'python', which
> is now python3.
>
> I have been working on rebuilding this package, but not quite there yet.
>
> You can work around this by fixing the shebang in /usr/bin/g-ir-scanner to
On 19.05.2021 21:32, Ken Brown via Cygwin-apps wrote:
Trying to build harfbuzz, I get the following python failure with
python-3.8
Traceback (most recent call last):
File "/usr/bin/g-ir-scanner", line 65, in
...
from giscanner._giscanner import collect_attributes
I
On 19/05/2021 20:32, Ken Brown via Cygwin-apps wrote:
Trying to build harfbuzz, I get the following python failure with
python-3.8
Traceback (most recent call last):
File "/usr/bin/g-ir-scanner", line 65, in
from giscanner.scannermain import scanner_main
File "/
Trying to build harfbuzz, I get the following python failure with python-3.8
Traceback (most recent call last):
File "/usr/bin/g-ir-scanner", line 65, in
from giscanner.scannermain import scanner_main
File "/usr/lib/gobject-introspection/giscanner/scannerma
itations 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 were hoping to not have the need to add platform
ulator
> 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 maintainers be willing
> to invest the required time.
I'm not sure what pac
td::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, thanx for the tips
Best regards,
Kristian
> Rega
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?
eatures 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 run just fine un
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
ble, 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 finally gave up.
I don't think g++ will be any easier than emacs, an
> 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
> > [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
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
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?
[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
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
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,
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
[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
>
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
[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
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
ary 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]
> >>>
> >
nistic 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 systems, but at
least you ca
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
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
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
> 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
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
fined 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 better, but then you can’t mix
wi
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
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]
>
>
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]
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
>
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
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
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 -fprofi
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/include/lib
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's
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 simple
/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
'../../cdo-1.9.9rc2
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
ny 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
unate, 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.
In the case of Cygwin it is quite certainly a bug as Cygwin is not a
Windows target
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, this ca
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" GC
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
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
0, which I
just took two days to build:
e608313@HOR711318E ~/Bedrock
$ CC=gcc GXX=g++ make
g++ -g -std=c++14 -fpic -O2 -Wall -Werror -Wformat-security
-DGIT_REVISION=ce62c88 -I/home/e608313/Bedrock
-I/home/e608313/Bedrock/mbedtls/include -MMD -MF libstuff/libstuff.d -MT
libstuff/libstuff.h.gch -
gt; Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
>From what I've seen, the errors are independent of the compiler
version. I'm betting on the same errors showing up with g++-6 as with
g++ 7.4 (Cygwin's default compiler).
On 5/18/2019 8:19 AM, Jose Isaias Cabrera wrote:
> I am finished and now to start building Bedrockdb. Thanks.
By the way, you're not the only person building Bedrockdb on Cygwin. Someone
has posted about 10 fixes in the last few days:
https://github.com/Expensify/Bedrock/issues
It looks
Csaba Raduly, on Saturday, May 18, 2019 02:50 AM, wrote...
>On Sat, May 18, 2019 at 7:14 AM Brian Inglis wrote:
>>
>> On 2019-05-17 21:18, Jose Isaias Cabrera wrote:
>> > After more than 8 hours running, building gcc-6.4.0, this error popped up:
>> > In file included from
Brian Inglis, on Saturday, May 18, 2019 01:14 AM, wrote...
On 2019-05-17 21:18, Jose Isaias Cabrera wrote:
> After more than 8 hours running, building gcc-6.4.0, this error popped up:
> In file included from ../.././libjava/jni-libjvm.cc:14:0:
> ../.././libjava/include/jvm.h:795:3: error:
Doug Henderson, Saturday, May 18, 2019 01:12 AM, wrote...
>On Wed, 15 May 2019 at 14:58, Jose Isaias Cabrera <> wrote:
>You seem to be having some difficulty getting an older version of the
>compiler running. Perhaps it might be useful to go back to the
>beginning and see if there is an
Sent: Friday, May 17, 2019 11:18 PM
To: cygwin@cygwin.com; m...@cs.umass.edu
Subject: Re: How to install gcc and g++ 6 on cygwin which are not on the
setup.exe
After more than 8 hours running, building gcc-6.4.0, this error popped up:
In file included from ../.././libjava/jni-libjvm.cc:14:0
On Sat, May 18, 2019 at 7:14 AM Brian Inglis wrote:
>
> On 2019-05-17 21:18, Jose Isaias Cabrera wrote:
> > After more than 8 hours running, building gcc-6.4.0, this error popped up:
> > In file included from ../.././libjava/jni-libjvm.cc:14:0:
> > ../.././libjava/include/jvm.h:795:3: error:
1 - 100 of 1158 matches
Mail list logo
