Bruno Haible via Cygwin writes:
> The gcc-gdc package (currently in version 11.5.0) [1] lacks
> the *.d files of the standard library (libphobos, including druntime).
As noted in the announcement, libphobos doesn't build on Cygwin even if
you try to force it in configure.
Regards,
Achim.
--
+<[
On 2023-01-08 01:06, Brian Inglis wrote:
On Sat, 7 Jan 2023 14:50:02 -0500, Lee wrote:
The "-mno-cygwin" gcc option went away years ago. Correct?
It still shows up in the output of 'man gcc':
$ man gcc | grep mno-cygwin
x86 Windows Options -mconsole -mcygwin -mno-cygwin -mdll
-m
On 1/15/2023 4:38 AM, Alexander Grund via Cygwin wrote:
Hi,
consider the following MWE:
|$ touch bar/foo.h $ cat bar/main.cpp #include "foo.h" int main(){} With this most simple setup
calling GCC with `g++ "bar\main.cpp"` results in GCC failing to find the include file. However
using `g++ "ba
Alexander Grund via Cygwin writes:
> consider the following MWE:
>
> |$ touch bar/foo.h $ cat bar/main.cpp #include "foo.h" int main(){}
> |With this most simple setup calling GCC with `g++ "bar\main.cpp"`
> |results in GCC failing to find the include file. However using `g++
> |"bar/main.cpp"` wor
Am 15.01.2023 um 14:51 schrieb Hans-Bernhard Bröker via Cygwin:
Am 15.01.2023 um 13:38 schrieb Alexander Grund via Cygwin:
The build system, finding it is running on Windows, will pass paths
with backward slashes to the compiler.
And that's wrong. Cygwin is not, for practical intents and
Am 15.01.2023 um 13:38 schrieb Alexander Grund via Cygwin:
The build system, finding it is running on Windows, will pass paths with
backward slashes to the compiler.
And that's wrong. Cygwin is not, for practical intents and purposes,
Windows. It just runs on top of it.
Yes, backslashed
On Sat, 7 Jan 2023 14:50:02 -0500, Lee wrote:
The "-mno-cygwin" gcc option went away years ago. Correct?
It still shows up in the output of 'man gcc':
$ man gcc | grep mno-cygwin
x86 Windows Options -mconsole -mcygwin -mno-cygwin -mdll
-mnop-fun-dllimport -mthread -municode -mw
>>> In a gcc build script terminating with the instruction
>>> gcc -w -static -o myexe -O3 ./myarchive.a -lreadline -lncurses -lm
>>> I have suddenly started getting very many instances of both of
>>> ld: /usr/src/debug/readline-8.2-2/terminal.c:nn various: undefined
>>> reference to `
On Thu, 15 Dec 2022 08:06:01 +, Fergus Daly wrote:
In a gcc build script terminating with the instruction
gcc -w -static -o myexe -O3 ./myarchive.a -lreadline -lncurses -lm
I have suddenly started getting very many instances of both of
ld: /usr/src/debug/readline-8.2-2/terminal.c:nn v
>> In a gcc build script terminating with the instruction
>> gcc -w -static -o myexe -O3 ./myarchive.a -lreadline -lncurses -lm
>> I have suddenly started getting very many instances of both of
>> ld: /usr/src/debug/readline-8.2-2/terminal.c:nn various: undefined
>> reference to `{various}
On Dec 8 16:02, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> Sorry for pressing this, I must be slow today.
>
> > just won't run correctly anymore on W7/8
>
> Won't or may not?
Won't
Corinna
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://
Sorry for pressing this, I must be slow today.
> just won't run correctly anymore on W7/8
Won't or may not?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com
On Dec 8 14:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > for 3.5 (late 2023) we announced the deprecation of Windows 7 and 8
> > since the first 3.3.0 release in October 2021.
>
> I saw that. It did not look alarming. It basically was like "you'll be on
> your own".
>
> > Su
> for 3.5 (late 2023) we announced the deprecation of Windows 7 and 8
> since the first 3.3.0 release in October 2021.
I saw that. It did not look alarming. It basically was like "you'll be on
your own".
> Supporting older OSes requires to keep workarounds in the code and
Understood. But you
On Dec 7 17:59, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > contains patches dropping W7 and W8 support:
>
> Hmm... I understood that "dropping support" was not something that
> would _require_ newer OS, but that it may not work (or not guaranteed
> to work, patches not checked for
> contains patches dropping W7 and W8 support:
Hmm... I understood that "dropping support" was not something that would
_require_ newer OS,
but that it may not work (or not guaranteed to work, patches not checked for
compatibility, etc)
on the older OSes... Are you saying that W7 and W8 would b
On Dec 7 15:05, Daniel Abrahamsson via Cygwin wrote:
> > On Dec 7 12:50, Corinna Vinschen via Cygwin wrote:
> > > On Dec 7 08:58, Daniel Abrahamsson via Cygwin wrote:
> > > > Hi,
> > > >
> > > > This morning I updated cygwin, and after that gcc started producing
> > > > errors like this:
> > >
On Dec 7 14:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > provided you run at least Windows 8.1
>
> Why would that be a requirement?
Test releases are created from the master branch which already
bumped version to 3.5.0 and contains patches dropping W7 and W8
support:
https://c
> On Dec 7 12:50, Corinna Vinschen via Cygwin wrote:
> > On Dec 7 08:58, Daniel Abrahamsson via Cygwin wrote:
> > > Hi,
> > >
> > > This morning I updated cygwin, and after that gcc started producing
> > > errors like this:
> > >
> > > > gcc -Wall -Wextra -Werror -pedantic -Wno-unused-paramet
> provided you run at least Windows 8.1
Why would that be a requirement?
Anton Lavrentiev
Contractor NIH/NLM/NCBI
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: htt
On Dec 7 12:50, Corinna Vinschen via Cygwin wrote:
> On Dec 7 08:58, Daniel Abrahamsson via Cygwin wrote:
> > Hi,
> >
> > This morning I updated cygwin, and after that gcc started producing errors
> > like this:
> >
> > > gcc -Wall -Wextra -Werror -pedantic -Wno-unused-parameter -g -pg
> > >
On Dec 7 08:58, Daniel Abrahamsson via Cygwin wrote:
> Hi,
>
> This morning I updated cygwin, and after that gcc started producing errors
> like this:
>
> > gcc -Wall -Wextra -Werror -pedantic -Wno-unused-parameter -g -pg -DVERBOSE
> > -c -o ../obj/.o .c
> > gcc -o ../bin/ ../obj/.o -pg
> > /
To Brian Inglis: thanks! Forwarded to newlib mailing list.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Ah, sorry! Now I see:
https://www.mail-archive.com/cygwin@cygwin.com/msg168488.html.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-
Hello. Is there any update on this? Thanks.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Am 27.10.2021 um 20:52 schrieb Thomas Wolff:
Am 27.10.2021 um 12:55 schrieb Hannes Domani:
Am Mittwoch, 27. Oktober 2021, 11:19:19 MESZ hat Thomas Wolff
Folgendes geschrieben:
I noticed that mintty did not compile anymore after upgrade to gcc 11,
but only on cygwin 32-bit.
I tried to min
Am 27.10.2021 um 12:55 schrieb Hannes Domani:
Am Mittwoch, 27. Oktober 2021, 11:19:19 MESZ hat Thomas Wolff
Folgendes geschrieben:
I noticed that mintty did not compile anymore after upgrade to gcc 11,
but only on cygwin 32-bit.
I tried to minimize the test case as much as possible withou
On 2021-10-27 03:19, Thomas Wolff wrote:
I noticed that mintty did not compile anymore after upgrade to gcc 11,
but only on cygwin 32-bit.
I tried to minimize the test case as much as possible without having the
bug vanish, to the attached standalone file.
Compile this with
cc -O2 -Wall -Werror
On Wed, Oct 27, 2021 at 7:56 PM Hannes Domani via Cygwin
wrote:
>
> Am Mittwoch, 27. Oktober 2021, 11:19:19 MESZ hat Thomas Wolff
> Folgendes geschrieben:
>
> > I noticed that mintty did not compile anymore after upgrade to gcc 11,
> > but only on cygwin 32-bit.
> > I tried to minimize the test
Am Mittwoch, 27. Oktober 2021, 11:19:19 MESZ hat Thomas Wolff
Folgendes geschrieben:
> I noticed that mintty did not compile anymore after upgrade to gcc 11,
> but only on cygwin 32-bit.
> I tried to minimize the test case as much as possible without having the
> bug vanish, to the attached sta
On 2021-06-12 14:45, Pavel M via Cygwin wrote:
Sample code (t903.c):
#include
int main(void)
{
printf("%.43f\n", 0x1.52f8a8e32e982p-140);
return 0;
}
Invocations:
# gcc on Windows 10 (Cygwin)
$ gcc t903.c -Wall -Wextra -std=c11 -pedantic -Wfatal-errors && ./a.exe
0.000
Pavel M via Cygwin writes:
> Sample code (t903.c):
> #include
> int main(void)
> {
> printf("%.43f\n", 0x1.52f8a8e32e982p-140);
> return 0;
> }
>
> Invocations:
> # gcc on Windows 10 (Cygwin)
> $ gcc t903.c -Wall -Wextra -std=c11 -pedantic -Wfatal-errors && ./a.exe
> 0.
On 2020-03-12 16:49, Eliot Moss wrote:
> On 3/12/2020 5:13 PM, Brian Inglis wrote:
>> On 2020-03-11 21:36, Eliot Moss wrote:
>>> On 3/11/2020 12:30 PM, Brian Inglis wrote:
On 2020-03-11 00:13, Eliot Moss wrote:
> On 3/11/2020 1:31 AM, Brian Inglis wrote:
>>>
There are gcc bugzilla com
On 3/12/2020 5:13 PM, Brian Inglis wrote:
On 2020-03-11 21:36, Eliot Moss wrote:
On 3/11/2020 12:30 PM, Brian Inglis wrote:
On 2020-03-11 00:13, Eliot Moss wrote:
On 3/11/2020 1:31 AM, Brian Inglis wrote:
There are gcc bugzilla comments about requiring gcc to be built with glibc
libatomic t
On 2020-03-11 21:36, Eliot Moss wrote:
> On 3/11/2020 12:30 PM, Brian Inglis wrote:
>> On 2020-03-11 00:13, Eliot Moss wrote:
>>> On 3/11/2020 1:31 AM, Brian Inglis wrote:
>
>> There are gcc bugzilla comments about requiring gcc to be built with glibc
>> libatomic to guarantee indirect inline func
On 3/11/2020 12:30 PM, Brian Inglis wrote:
On 2020-03-11 00:13, Eliot Moss wrote:
On 3/11/2020 1:31 AM, Brian Inglis wrote:
There are gcc bugzilla comments about requiring gcc to be built with glibc
libatomic to guarantee indirect inline functions support, and presumably glibc
detecting gcc i
Eliot Moss writes:
> What I am really reporting is that Cygwin is giving the pthread mutex form
> when it should not be. My CPU clearly has the capability, and the compiler
> clearly
> knows how to emit the instruction, since the __sync form does it. What is
> mysterious and tangled is why libat
On 2020-03-11 00:13, Eliot Moss wrote:
> On 3/11/2020 1:31 AM, Brian Inglis wrote:
>
> A quick followup: I was able to get __sync_val_compare_and_swap_16 to work
> (and its bool form). That will do for now, though of course it's
> deprecated.
>
> This does get me the inlined asm cod
On 3/11/2020 1:31 AM, Brian Inglis wrote:
A quick followup: I was able to get __sync_val_compare_and_swap_16 to work
(and its bool form). That will do for now, though of course it's deprecated.
This does get me the inlined asm code.
Digging further into the murk where a simple builtin inlin
On 2020-03-10 15:13, Eliot Moss wrote:
> On 3/10/2020 4:35 PM, Brian Inglis wrote:
>> On 2020-03-08 20:59, Eliot Moss wrote:
>>> On 3/8/2020 10:29 PM, Eliot Moss wrote:
This is probably to the gcc maintainer ...
I am running on a processor that has compare/exchange 128-bit (cx16
On 3/10/2020 4:35 PM, Brian Inglis wrote:
On 2020-03-08 20:59, Eliot Moss wrote:
On 3/8/2020 10:29 PM, Eliot Moss wrote:
This is probably to the gcc maintainer ...
I am running on a processor that has compare/exchange 128-bit (cx16 capability),
and I compiler with -mcx16 and -latomic. I'm on
On 2020-03-08 20:59, Eliot Moss wrote:
> On 3/8/2020 10:29 PM, Eliot Moss wrote:
>> This is probably to the gcc maintainer ...
>>
>> I am running on a processor that has compare/exchange 128-bit (cx16
>> capability),
>> and I compiler with -mcx16 and -latomic. I'm on the latest release cygwin
>>
On 3/8/2020 10:29 PM, Eliot Moss wrote:
This is probably to the gcc maintainer ...
I am running on a processor that has compare/exchange 128-bit (cx16 capability),
and I compiler with -mcx16 and -latomic. I'm on the latest release cygwin gcc
(9.2.0-3, I believe) and the corresponding libatomic.
Hi Daniel,
On Dec 5 19:24, Daniel Kochmański wrote:
> Hey,
>
> while testing ECL on Cygwin I've encountered a few issues with how the
> functions coshl and acoshl treat infinities (long double
> functions). Results are invalid and that does not happen on Linux.
Most of the long double functions
On Aug 18 16:51, Denis Excoffier wrote:
> Hello,
>
> In the GCC 10 Release Criteria, one can read
> (https://gcc.gnu.org/gcc-10/criteria.html) that cygwin is among the secondary
> platform list:
>
> >
> > Secondary Platform List
> >
> > The secondary platforms are:
> > * aarch64-elf
> > * i686
On 2019-08-18 08:51, Denis Excoffier wrote:
> In the GCC 10 Release Criteria, one can read
> (https://gcc.gnu.org/gcc-10/criteria.html) that cygwin is among the
> secondary platform list:
>> Secondary Platform List
>>
>> The secondary platforms are:
>> * aarch64-elf
>> * i686-apple-darwin
>> * i6
On Nov 27 11:32, Jiří Engelthaler wrote:
> Hi,
> I have a problem with GCC 7.3.0 (problem is in all versions) and
> precompiled headers.
> I have the sample file http://ge.tt/7fRLk1t2 which causes Segmentation
> fault in cc1.
> The test passes normally on Linux. I searched why and found that the
Christian Franke wrote:
Marco Atzeri wrote:
On 6/12/2018 7:11 PM, Christian Franke wrote:
...
The attached patch for
/usr/lib/gcc/*-pc-cygwin/7.3.0/include/c++/bits/basic_string.h
fixes this.
Please forget this patch. It was bases on a wrong assumption and only
cures symptoms.
It seems
Marco Atzeri wrote:
On 6/12/2018 7:11 PM, Christian Franke wrote:
...
The attached patch for
/usr/lib/gcc/*-pc-cygwin/7.3.0/include/c++/bits/basic_string.h
fixes this.
Christian
Thanks Christian
for the investigation.
It seems an upstream bug so could you report it there ?
Done:
https://
On 6/12/2018 7:11 PM, Christian Franke wrote:
Ivan Shynkarenka wrote:
Could reproduce this with 32 and 64 bit Cygwin g++ 7.3.0
A comparison of preprocessor (-E) outputs shows that the "extern
template" declarations for getline() are only visible for C++ <= 14.
These are guarded by "__cplusplus
On 2018-06-13 05:11, Christian Franke wrote:
Ivan Shynkarenka wrote:
I use x64 bit Cygwin and it failed in my home, work and Appveyor. I add
cygcheck.out with my environment.
I'm sorry about misspell prefix space in my prev example. Please try the
following one:
#include
#include
int main(
Ivan Shynkarenka wrote:
I use x64 bit Cygwin and it failed in my home, work and Appveyor. I add
cygcheck.out with my environment.
I'm sorry about misspell prefix space in my prev example. Please try the
following one:
#include
#include
int main(int argc, char** argv)
{
std::string line
On 2018-06-12 02:17, Marco Atzeri wrote:
On 6/11/2018 4:11 AM, Ross Smith wrote:
On 2018-06-06 09:00, Marco Atzeri wrote:
On 6/5/2018 10:32 PM, Ivan Shynkarenka wrote:
Hello
I use x64 bit Cygwin and it failed in my home, work and Appveyor. I
add
cygcheck.out with my environment.
I'm sor
On 6/11/2018 4:11 AM, Ross Smith wrote:
On 2018-06-06 09:00, Marco Atzeri wrote:
On 6/5/2018 10:32 PM, Ivan Shynkarenka wrote:
Hello
I use x64 bit Cygwin and it failed in my home, work and Appveyor. I add
cygcheck.out with my environment.
I'm sorry about misspell prefix space in my prev ex
On 2018-06-06 09:00, Marco Atzeri wrote:
On 6/5/2018 10:32 PM, Ivan Shynkarenka wrote:
Hello
I use x64 bit Cygwin and it failed in my home, work and Appveyor. I add
cygcheck.out with my environment.
I'm sorry about misspell prefix space in my prev example. Please try the
following one:
#in
On 6/5/2018 10:32 PM, Ivan Shynkarenka wrote:
Hello
I use x64 bit Cygwin and it failed in my home, work and Appveyor. I add
cygcheck.out with my environment.
I'm sorry about misspell prefix space in my prev example. Please try the
following one:
#include
#include
int main(int argc, char*
On 6/5/2018 9:12 PM, Hans-Bernhard Bröker wrote:
Am 05.06.2018 um 17:56 schrieb Ivan Shynkarenka:
Hello,
I found an issue with Cygwin GCC 7.3.0 when building with -std=gnu++17
flag.
Using Cygwin 32-bit or 64-bit? I have to ask because I could not
reproduce your problem here, on the 64-bit
Am 05.06.2018 um 17:56 schrieb Ivan Shynkarenka:
Hello,
I found an issue with Cygwin GCC 7.3.0 when building with -std=gnu++17
flag.
Using Cygwin 32-bit or 64-bit? I have to ask because I could not
reproduce your problem here, on the 64-bit version.
Build: g++ -std=gnu++17 test.cpp
Buil
On 3/27/18, Brian Inglis wrote:
> On 2018-03-27 11:39, Lee wrote:
>> How do you figure out which package is missing from your install?
>> $cat sbstrict.c
>> int main () {
>> return 0;
>> }
>> $i686-w64-mingw32-gcc -fsanitize=bounds-strict sbstrict.c
>> /usr/lib/gcc/i686-w64-mingw32/6.4.0/../../
On 2018-03-27 11:39, Lee wrote:
> How do you figure out which package is missing from your install?
> $cat sbstrict.c
> int main () {
> return 0;
> }
> $i686-w64-mingw32-gcc -fsanitize=bounds-strict sbstrict.c
> /usr/lib/gcc/i686-w64-mingw32/6.4.0/../../../../i686-w64-mingw32/bin/ld:
> cannot fin
On Fri, 16 Mar 2018 16:45:11, Tim Clarke wrote:
> Sorry, posted this from my other non-regsitered email address!!
>
> Following my previous post advising that the gcc 32 compiler was
> exiting immediately (return code 1) without doing anything, I have
> now established what is happening.
> The beh
On 16/03/2018 16:04, Tim Clarke wrote:
I have installed the 64 verswon of gcc and it works fine
I also installed the 32 bit version on a 32-bit laptop and it
installs ok, but when atteppting to comple any program with
gcc it simply returns eiimdiately without doing anything,
with return-code 1
Dear Tim,
do you compile c or c++ code (.cpp extension)?
As far as I can tell, you need "gcc-core" and "gcc-g++" if you want to compile
c++ code - or at least this is what I install and it works (regularly tested
with automated regression tests, which always install a fresh Cygwin)
Best regar
On 18/02/2018 22:57, Sonia Diaz Pacheco wrote:
(I'm not subscribed, please CC me)
Hi all,
I've just updated gcc and it stopped working. It shows the following error
message.
g++ -Wall -W -O2 -c -o arg_parser.o arg_parser.cc
C:/cygwin64/lib/gcc/x86_64-pc-cygwin/6.4.0/cc1plus.exe: error while l
Thanks to all the lead me the way.
Using cygwin's time machine I was able to build a working cygwin
enviroment with gcc/gfortran at version 5.40.
(http://ctm.crouchingtigerhiddenfruitbat.org/pub/cygwin/circa/64bit/2017/09/05/224214/)
On 11/27/2017 12:58 PM, Achim Gratz wrote:
Hans Horn writ
Hans Horn writes:
> I noticed that cywgin's gcc/gfortran has moved whole sale to gcc 6.4.
> How can I get the latest release of the 5.x branch (32 and 64bit)
> back?
Use the Cygwin Time Machine, some other post had the link.
> I'm trying to build a legacy suite of programs that I know builds
> un
LMH writes:
> You can have as many cygwin installations on your system as you want, just
> name the
> root folder and install folder something different for each one. There are
> potential
> problems if you try to run more than one version at the same time.
As long as they don't see each other v
Hans Horn wrote:
> Group,
>
> I noticed that cywgin's gcc/gfortran has moved whole sale to gcc 6.4.
> How can I get the latest release of the 5.x branch (32 and 64bit) back?
> I'm trying to build a legacy suite of programs that I know builds under 5.x,
> but
> fails miserably under 6.4.
>
> Than
On 27/11/2017 20:29, Keith Christian wrote:
Yaakov,
To help Hans a bit, do we know is the Wayback Machine still working
(I've never used it.)
http://www.crouchingtigerhiddenfruitbat.org/Cygwin/timemachine.html
--
Problem reports: http://cygwin.com/problems.html
FAQ: h
Yaakov,
To help Hans a bit, do we know is the Wayback Machine still working
(I've never used it.)
Or, Hans could keep a gfortran 5.x system around, or roll back the
latest Cygwin updates until he's had a chance to as you say, fix the
code.
--
Problem reports: http://cygwin.com/problems.htm
On 2017-11-26 23:54, Hans Horn wrote:
> I noticed that cywgin's gcc/gfortran has moved whole sale to gcc 6.4.
> How can I get the latest release of the 5.x branch (32 and 64bit) back?
It is no longer supported.
> I'm trying to build a legacy suite of programs that I know builds under
> 5.x, but f
Am 26.09.2017 um 07:32 schrieb Marco Atzeri:
"The header shall define the fd_set type as a structure."
so if they are using it, they should have a proper include
The complete story is a bit more complicated than that, though.
The curl maintainers almost fixed this at their end, but then Cyg
On 26/09/2017 03:41, Ian Fette wrote:
I tried compiling a very simple program with curl using -std=c++14 under
64-bit cygwin with gcc 6.4.0. When compiling with just g++ main.cpp -lcurl
everything is fine, however if I try to use c++14 as the dialect (g++
main.cpp -lcurl -std=c++14) familiar pr
On 2017-09-25 19:41, Ian Fette wrote:
> I tried compiling a very simple program with curl using -std=c++14 under
> 64-bit cygwin with gcc 6.4.0. When compiling with just g++ main.cpp -lcurl
> everything is fine, however if I try to use c++14 as the dialect (g++
> main.cpp -lcurl -std=c++14) fami
Please do not add me to the addresses directly. I get the mail from the
list. Note, if you're not subscribed you should be, I've removed you
from the address lists as well.
On 8/23/2017 3:38 PM, Joachim Metz wrote:
>> Was there a stackdump file you could have attached? What happens if you
>> re
> Was there a stackdump file you could have attached? What happens if you
> remove the -O3 and -O2 for that matter. I find it interesting that
> you're using a 32bit Cygwin on a server that only executes on a 64bit
> CPU. Does this happen with 64bit Cygwin? No, then use it instead.
So this does
On 8/18/2017 1:21 AM, Joachim Metz wrote:
> Hello CygWin maintainers,
>
> I want to report an observation, which might help address a bug.
>
> This issue has been reported in the past in:
> https://cygwin.com/ml/cygwin/2014-10/msg00502.html
>
> I recently ran into the same issue:
>
> On AppVeyo
On 23/07/17 12:38, Irfan Adilovic wrote:
I am reproducing here a bug report I filed to gcc's bugzilla against
gcc-7.1.0:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81522 , in
hopes of finding others who observed the same issue or who may have a
solution. The bug only appears on Cygwin and only
On Sun, Jul 23, 2017 at 4:38 AM, Irfan Adilovic wrote:
> I am reproducing here a bug report I filed to gcc's bugzilla against
> gcc-7.1.0: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81522
> The bug only appears on Cygwin and only in c++17 mode with the old ABI.
Pedantic automated response:
Whi
This problem goes away when updating Cygwin x86_64 from 2.8.1 to 2.8.2 ; same
for this one:
https://cygwin.com/ml/cygwin/2017-07/msg00088.html "g++ std::map initializing
raises segmentation fault."
Falk
> The following C++ program crashes when compiled with GCC (both 5.4 and 6.3)
> under Cygwin, when compiled with both an optimization level higher than -O0
> (i.e. -O1, -O2 or -O3) and the C++ standard set to -std=c++nn (for any
> supported nn, i.e. 98, 03, 11, 14 or 17):
> ```
> #include
> #in
On Thu, Jul 6, 2017 at 6:07 AM, TANNHAUSER Falk
wrote:
> The following C++ program crashes when compiled with GCC (both 5.4 and 6.3)
> under Cygwin, when compiled with both an optimization level higher than -O0
> (i.e. -O1, -O2 or -O3) and the C++ standard set to -std=c++nn (for any
> supported
Interesting that the package name isn't "libarchive" in the repos, but
it's "libarchive13". Since I'm using a apt-get bash script to get the
packages for me anyway. Since it seems I already had "libarchive13"
installed, I tried installing the mingw64 package to see if it would fix
my issue buil
starz0rdesign wrote:
Which package contains libink.a?
This is the output for make V=1
$ make V=1
make all-am
make[1]: Entering directory '/home/nobodyimportant/libarchive-3.3.1'
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wformat -Wformat-s
ecurity -no-undefined -version-info 1
Which package contains libink.a?
This is the output for make V=1
$ make V=1
make all-am
make[1]: Entering directory '/home/nobodyimportant/libarchive-3.3.1'
/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wformat
-Wformat-s
ecurity -no-undefined -version-info 16:1:3 -o libarchive.
Hi,
On Mon, Jul 3, 2017 at 11:52 PM, starz0rdesign wrote:
> Hello.
>
> I'm having a bit of an issue trying to compile LibArchive 3.3.1 for Windows.
> I have Mingw64 with GCC7.1 installed to prevent the Cygwin installer from
> linking it's DLL.
Maybe you should ask on the Mingw mailing list.
> A
JonY wrote:
On 01/26/2017 10:30 AM, Christian Franke wrote:
After upgrading to gcc test version 6.3.0-1, C++ exception handling is
broken if DLL version of new libstdc++6 is used.
Noted, I'll consider the test version broken for now.
Meantime I examined the testcase with gdb: The DLL expor
On 01/26/2017 10:30 AM, Christian Franke wrote:
> After upgrading to gcc test version 6.3.0-1, C++ exception handling is
> broken if DLL version of new libstdc++6 is used.
>
Noted, I'll consider the test version broken for now.
signature.asc
Description: OpenPGP digital signature
On 4/26/2016 20:10, Marco Atzeri wrote:
>
>
> On 26/04/2016 12:16, JonY wrote:
>> On 4/26/2016 01:46, Marco Atzeri wrote:
>>> Visible on 32bit and not present on 64bit
>>>
>>> $ cat uuid.c
>>> #include
>>>
>>> int main ()
>>> {
>>> uuid_t out;
>>> uuid_generate_random(out);
>>> retur
On 26/04/2016 12:16, JonY wrote:
On 4/26/2016 01:46, Marco Atzeri wrote:
Visible on 32bit and not present on 64bit
$ cat uuid.c
#include
int main ()
{
uuid_t out;
uuid_generate_random(out);
return 0;
}
$ gcc uuid.c -luuid
/tmp/ccLlmFMf.o:uuid.c:(.text+0x16): undefined referenc
On 4/26/2016 01:46, Marco Atzeri wrote:
> Visible on 32bit and not present on 64bit
>
> $ cat uuid.c
> #include
>
> int main ()
> {
> uuid_t out;
> uuid_generate_random(out);
> return 0;
> }
>
>
> $ gcc uuid.c -luuid
> /tmp/ccLlmFMf.o:uuid.c:(.text+0x16): undefined reference to
> `
On 2016-03-31 09:08, Peter Foley wrote:
The cygwin gcc package appears to be missing the helper libraries for
the -fsanitize series of options.
These are only supported on x86-linux.
--
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/f
On 2016-03-25 16:55, Lester Ingber wrote:
I just tries to use the memory-leak detection built into gcc.
I have the latest v5.3.0 from the regular x64 setup.
I get:
/bin/ld: cannot find -llsan
collect2: error: ld returned 1 exit status
I do not see any lsan (or tsan) in my cygwin64 directories.
On 16/03/2016 11:43, Daniel Rudy wrote:
Hello,
I've been banging my head against the wall on this one. For some inexplicable
reason, both gcc and clang broke at the same time right after I updated
cygwin64. To try to resolve the issue, I tried to uninstall and then reinstall
a fresh copy
On 2016-02-25 17:12, JonY wrote:
On 2/26/2016 01:44, Yaakov Selkowitz wrote:
JonY,
It has been brought to my attention that /usr/lib/w32api is now taking
precedence over /usr/lib, which is a result of this commit:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=227962
https://github.com
On 2/26/2016 01:44, Yaakov Selkowitz wrote:
> JonY,
>
> It has been brought to my attention that /usr/lib/w32api is now taking
> precedence over /usr/lib, which is a result of this commit:
>
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=227962
> https://github.com/gcc-mirror/gcc/commit
On Nov 14 12:59, tdotre...@aircrack-ng.org wrote:
> Hi,
>
> I just updated to cygwin 2.3.1-1 after
> https://cygwin.com/ml/cygwin/2015-11/msg00186.html1 to see if the update
> solves the issue but it still segfaults. I only tested gcc 5.2.0-1 and I'm
> pretty sure it's gonna happen on every other
On Wed, Oct 28, 2015 at 5:36 PM, Yaakov Selkowitz wrote:
>
> The various sanitizers in recent versions of GCC are not currently
> supported on Cygwin.
Then it would be nicer if GCC reported an error (rather than compile
dozens of files and then fail to link them at the end).
This is likely a GCC
On Tue, 2015-10-27 at 20:58 -0500, Steven Penny wrote:
> I have installed the "gcc-core" package:
>
> $ gcc --version
> gcc (GCC) 4.9.3
>
> Using this file:
>
> http://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/testsuite/c-c%2B%2B-common/ubsan/undefined-1.c;hb=382ecb
>
> and this command:
>
> For the last month or so every time I update in setup, in the Resolving
> Dependencies pane I see
>
> libvtv0()
>
> Required by: gcc-core
>
> Note the empty version number and description. I accept it, but the next
> time I
> update, it's back.
Fixed now, tha
1 - 100 of 1094 matches
Mail list logo
