ucrt for mingw compiler (suggestion and wish)

Hi all, The (original) mingw compilers essentially come in the flavours mingw64, ucrt64, clang64. The mingw compilers available via cygwin install are the mingw64 ones. This means they are based on the old M$ C runtime msvcrt instead if the new ucrt one. Woild it be possible to offer the

Re: [Ms-nfs41-client-devel] Cygwin&mingw svn fails on NFS4 share

On Fri, Jun 14, 2024 at 5:19 PM Roland Mainz wrote: > > On Fri, Jun 14, 2024 at 12:14 PM Mark Liam Brown > wrote: > > Cygwin 3.4/3.5&mingw svn fails on a NFS4 share during checkout > > > > svn checkout https://svn.FreeBSD.org/base/head/share/man > > Am

Re: [Ms-nfs41-client-devel] Cygwin&mingw svn fails on NFS4 share

On Fri, Jun 14, 2024 at 12:14 PM Mark Liam Brown wrote: > Cygwin 3.4/3.5&mingw svn fails on a NFS4 share during checkout > > svn checkout https://svn.FreeBSD.org/base/head/share/man > Aman/man4 > Aman/man4/tcp.4 > Aman/man4/ndis.4 > Aman/man4/Makefile &

Cygwin&mingw svn fails on NFS4 share

Greeting! Cygwin 3.4/3.5&mingw svn fails on a NFS4 share during checkout svn checkout https://svn.FreeBSD.org/base/head/share/man Aman/man4 Aman/man4/tcp.4 Aman/man4/ndis.4 Aman/man4/Makefile Aman/man4/altq.4 Aman/man4/miibus.4 Aman/man4/vlan.4 Aman/

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

ou so much!! >>> >>> From: Cygwin on behalf >>> of Takashi Yano via Cygwin >>> Sent: 04 March 2024 12:06 >>> To: cygwin@cygwin.com >>> Subject: Re: Regression: Cygwin 3.5.1 freezes when launching several mingw

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

Takashi Yano via Cygwin > > Sent: 04 March 2024 12:06 > > To: cygwin@cygwin.com > > Subject: Re: Regression: Cygwin 3.5.1 freezes when launching several mingw > > processes in parallel > > > > On Mon, 4 Mar 2024 20:00:13 +0900 > > Takashi Yano via Cygwin

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

ect: Re: Regression: Cygwin 3.5.1 freezes when launching several mingw > processes in parallel > > On Mon, 4 Mar 2024 20:00:13 +0900 > Takashi Yano via Cygwin wrote: >> On Sun, 3 Mar 2024 13:07:11 +0900 >> Takashi Yano wrote: >>> On Sat, 2 Mar 2024 11:49:36 +

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

4 12:06 To: cygwin@cygwin.com Subject: Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel On Mon, 4 Mar 2024 20:00:13 +0900 Takashi Yano via Cygwin wrote: > On Sun, 3 Mar 2024 13:07:11 +0900 > Takashi Yano wrote: > > On Sat, 2 Mar 2024 11:49:36 +

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

I think I've been experiencing something similar with 3.5.1, where date.exe randomly hangs with a full core pegged. Loading it in gdb shows: Thread 1 received signal SIGTRAP, Trace/breakpoint trap. 0x7ffe23b0b503 in KERNELBASE!DebugBreak () from /cygdrive/c/Windows/System32/KERNELBASE.dll (g

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

On Mon, 4 Mar 2024 20:00:13 +0900 Takashi Yano via Cygwin wrote: > On Sun, 3 Mar 2024 13:07:11 +0900 > Takashi Yano wrote: > > On Sat, 2 Mar 2024 11:49:36 + > > Kate Deplaix wrote: > > > I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of > > > RAM and with an up-to-date

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

On Sun, 3 Mar 2024 13:07:11 +0900 Takashi Yano wrote: > On Sat, 2 Mar 2024 11:49:36 + > Kate Deplaix wrote: > > I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of > > RAM and with an up-to-date Windows 10. > > Thanks for the information. I could reproduce the problem wi

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

On Sat, 2 Mar 2024 11:49:36 + Kate Deplaix wrote: > I'm running cygwin on baremetal on an Intel i5-750 (4 cores), with 7GB of RAM > and with an up-to-date Windows 10. Thanks for the information. I could reproduce the problem with Core i5 M 540 + 8GB RAM machine. Let consider how to debug. -

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

Yano via Cygwin Sent: Saturday, March 2, 2024 4:41 am To: cygwin@cygwin.com Subject: Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel On Fri, 1 Mar 2024 17:48:52 + Kate Deplaix wrote: > Hi, > > Using cygwin 3.6.0-0.66.gc77a5689f7bd I was in

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

quite reliably over the whole compilation process) > fails with make -j (works fine with -j1 once again) > > Luckily i was able to make a really small test-case this time: > Using MinGW 11.4.0 with the following test.c file: > > #define UNICODE > #define _UNICODE > > #

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

ckily i was able to make a really small test-case this time: Using MinGW 11.4.0 with the following test.c file: #define UNICODE #define _UNICODE #include #include int main() { int ret = _wsystem(L"x86_64-w64-mingw32-gcc -dumpversion"); if(ret != 0) printf("FOUND %d\n"

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

On Fri, 1 Mar 2024 at 08:03, Takashi Yano via Cygwin wrote: > Please try: cygwin 3.6.0-0.66.gc77a5689f7bd (TEST) I can confirm this fixes the issue for me, thank you! David -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

On Fri, 1 Mar 2024 19:21:12 +0900 Takashi Yano wrote: > On Fri, 1 Mar 2024 09:25:10 +0900 > Takashi Yano wrote: > > On Thu, 29 Feb 2024 18:19:45 + > > Kate Deplaix wrote: > > > To reproduce this: > > > > > > * > > > make sure you have a fresh installed of cygwin 3.5.1 > > > * > > > install

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

On Fri, 1 Mar 2024 09:25:10 +0900 Takashi Yano wrote: > On Thu, 29 Feb 2024 18:19:45 + > Kate Deplaix wrote: > > To reproduce this: > > > > * > > make sure you have a fresh installed of cygwin 3.5.1 > > * > > install the following packages: autoconf, make, patch, curl, > > mingw64-x86_64-

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

$ (gdb|grep '+1275' -n -B10 -A10)<530 /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc: No such file or directory. 225- 226-564 in /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc 227-565 in /usr/src/debug/cygwin-3.5.1-1/winsup/cygwin/pinfo.cc 228- 0x0001800991de <+300>:

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

On Thu, 29 Feb 2024 18:19:45 + Kate Deplaix wrote: > To reproduce this: > > * > make sure you have a fresh installed of cygwin 3.5.1 > * > install the following packages: autoconf, make, patch, curl, > mingw64-x86_64-gcc-g++, mingw64-i686-gcc-g++ > * > curl -LO > https://github.com/oca

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

$ (echo symbol cygwin1.dll;grep -Po '(?<=cygwin1!)[a-z_0-9]*?\+0x[a-f0-9]*'|sed -E 's/^/i line *(/;s/$/)/')|gdb GNU gdb (GDB) (Cygwin 12.1-1) 12.1 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free softwar

Re: Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

On 3/1/2024 6:34 AM, Kevin Schnitzius via Cygwin wrote: On Thursday, February 29, 2024 at 01:21:01 PM EST, Kate Deplaix via Cygwin wrote: At some point of the make process, one job will infinit loop (taking 100% of one core), while the rest of the mingw jobs will idle and never finish. After some

Regression: Cygwin 3.5.1 freezes when launching several mingw processes in parallel

make cold * * At some point of the make process, one job will infinit loop (taking 100% of one core), while the rest of the mingw jobs will idle and never finish. After some time Cygwin Terminal isn't responsive anymore, and I'm not able to open another one or to spawn any other processes

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

Sorry for necroreply. Just to keen in history records. When starting any program under MSYS (and MSYS2), the MSYS[2] checks whether the lunched program is linked with msys-*.dll. If program is linked with this DLL then the program expects POSIX-like environment so no path translation is perform

Re: Contribute some scripts to build Cross-GCC, Clang, and QEMU on Cygwin and MSYS2/MinGW-w64

convenient bash functions defined > there. > > QEMU can only be built on MSYS2/MinGW-w64. -- 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

Re: Contribute some scripts to build Cross-GCC, Clang, and QEMU on Cygwin and MSYS2/MinGW-w64

defined > there. > > QEMU can only be built on MSYS2/MinGW-w64. # MIT License # Copyright (c) 2023 徐持恒 Xu Chiheng # Permission is hereby granted, free of charge, to any person obtaining a copy # of this software and associated documentation files (the "Software"), to deal # i

[ANNOUNCEMENT] Updated: {,mingw-{i686,x86_64}-}pcre2-10.42-1

: pcre2-10.42-1 libpcre2-10.42-1 libpcre2_16_0-10.42-1 libpcre2_32_0-10.42-1 libpcre2-posix3-10.42-1 libpcre2-devel-10.42-1 libpcre2-doc-10.42-1 mingw-i686-pcre2-10.42-1 mingw-x86_64-pcre2-10.42-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the

[ANNOUNCEMENT] Updated: {,mingw-{i686,x86_64}-}pcre2-10.41-1

uploaded to the Cygwin distribution: pcre2-10.41-1 libpcre2-10.41-1 libpcre2_16_0-10.41-1 libpcre2_32_0-10.41-1 libpcre2-posix3-10.41-1 libpcre2-devel-10.41-1 libpcre2-doc-10.41-1 mingw-i686-pcre2-10.41-1 mingw-x86_64-pcre2-10.41-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO

Re: mingw.org link in User's Guide - domain does not appear to be owned by mingw project

On 2022-07-10 10:34, Lynn Winebarger wrote: There's a link in the "Building DLLs" section of the user guide that is supposed to go to the MingW home page. It looks like that domain name is no longer under the control of the MingW project. https://www.cygwin.com/cygwin-ug-net/dll

mingw.org link in User's Guide - domain does not appear to be owned by mingw project

There's a link in the "Building DLLs" section of the user guide that is supposed to go to the MingW home page. It looks like that domain name is no longer under the control of the MingW project. https://www.cygwin.com/cygwin-ug-net/dll.html#dll-build Lynn -- Problem repo

[ANNOUNCEMENT] Updated: {,mingw-{i686,x86_64}-}pcre2-10.40-1

uploaded to the Cygwin distribution: pcre2-10.40-1 libpcre2-10.40-1 libpcre2_16_0-10.40-1 libpcre2_32_0-10.40-1 libpcre2-posix3-10.40-1 libpcre2-devel-10.40-1 libpcre2-doc-10.40-1 mingw-i686-pcre2-10.40-1 mingw-x86_64-pcre2-10.40-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO

libmariadb.pc missing for MinGW toolchains

Pkg-config does not detect installed MariaDB Connector/C for MinGW, e.g. when building some software that connects to MariaDB or MySQL. The reason is that the pkg-config files are missing in the registries of pkg-config. (These files could be part of future mingw64-*-mariadb-connector-c v2.3.3

[ANNOUNCEMENT] Updated: {,mingw-{i686,x86_64}-}pcre2-10.39-1

to the Cygwin distribution: pcre2-10.39-1 libpcre2-10.39-1 libpcre2_16_0-10.39-1 libpcre2_32_0-10.39-1 libpcre2-posix3-10.39-1 libpcre2-devel-10.39-1 libpcre2-doc-10.39-1 mingw-i686-pcre2-10.39-1 mingw-x86_64-pcre2-10.39-1 -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you

[ANNOUNCEMENT] Updated: {,mingw-{i686,x86_64}-}pcre2-10.38-1

have been uploaded to the Cygwin distribution: pcre2-10.38-1 libpcre2-10.38-1 libpcre2_16_0-10.38-1 libpcre2_32_0-10.38-1 libpcre2-posix3-10.38-1 libpcre2-devel-10.38-1 libpcre2-doc-10.38-1 mingw-i686-pcre2-10.38-1 mingw-x86_64-pcre2-10.38-1 -- *** CYGWIN-ANNOUNCE

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

for a long time, and is heavily used by the original mingw.org mingw distribution. Libtool is catered to work with MSYS simply because it has been around far longer than MSYS2. I'd say if anything, libtool needs to check if it is on MSYS2 or MSYS and then work appropriately. MSYS2 shou

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

>/$ cmd //c echo hello />/hello />//>/which works, and this, which doesn't: />//>/$ cmd /c echo hello />//>/Microsoft Windows [Version 10.0.blah] />/(c) Microsoft Corporation. All rights reserved. />//>/C:\msys64\home\myname> / Your example seems to be inverted, the first form doesn't work, the

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

On 6/28/2021 8:56 AM, Dietmar May via Cygwin wrote: Thanks for submitting the bug report. I can now see what may be a duplicate report under: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949 responding that //c is deliberate so MSYS does not convert a posix path, so in the Cygwin Mingw

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

Thanks for submitting the bug report. I can now see what may be a duplicate report under: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949 responding that //c is deliberate so MSYS does not convert a posix path, so in the Cygwin Mingw build case, the response may be "Don't Do T

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

k to this thread and patch to the upstream package maintainers; I will post any responses received. I can now see what may be a duplicate report under: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10949 responding that //c is deliberate so MSYS does not convert a posix path, so in the Cygwin M

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

On 2021-06-26 20:38, Dietmar May via Cygwin wrote: On 6/26/2021 3:17 PM, Brian Inglis wrote: On 2021-06-25 14:46, Dietmar May via Cygwin wrote: The build completes successfully by replacing the "cmd /c | sed" construct with simply: func_convert_core_msys_to_w32_result=$1 so no path translation

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

Jonathan Yong is correct - removing --build allows make to complete without error using the unmodified ltmain.sh There's still the issue of generating a call to cmd.exe with an invalid switch (//c), which will cause it to hang indefinitely if ever invoked. The risk of breaking anything by fix

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

On 2021-06-25 14:46, Dietmar May via Cygwin wrote: The build completes successfully by replacing the "cmd /c | sed" construct with simply: func_convert_core_msys_to_w32_result=$1 so no path translation takes place. The function then becomes: func_convert_core_msys_to_w32 () {   $debug_cmd

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

_result=$1 } SUMMARY func_convert_core_msys_to_w32 in /usr/share/libtool/build-aux/ltmain.sh has an extraneous '/' in the call to ( cmd //c echo "$1" ) causing make to hang indefinitely when configured with --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 The project builds

Re: libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

On 6/25/21 2:34 PM, Dietmar May via Cygwin wrote: ./configure --disable-werror --disable-doxygen-pdf --enable-ftdi --enable-jlink --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 Don't set --build, you are building on Cygwin, not MSYS. OpenPGP_0x713B5FE29C145D45.asc Description: Open

libtool with mingw hangs building openocd in func_convert_core_msys_to_w32

uccessfully on msys2 & mingw-w64-x86_64-gcc installed, as well as on git-for-windows-sdk (which uses msys2). msys2 has the same issue ('//c'), but the compiler is in the path, so no cross-compilation configuration is needed (and apparently this function is not invoked). DETAILS

[ANNOUNCEMENT] Updated: pcre-8.45-1 / mingw-{i686, x86_64}-pcre-8.45-1

The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl, with just a few differences. The MinGW packages have also been updated to the latest version. The following packages have been uploaded to the Cygwin

[ANNOUNCEMENT] Updated: pcre2-10.37-1 / mingw-{i686, x86_64}-pcre2-10.37-1

ABI for the POSIX compatible library since some symbols were removed for solving problems with applications that link to both a "real" POSIX regex library and PCRE2-POSIX (usually indirectly). Applications need to be recompiled to pick up that change. The MinGW packages have also been upda

GLM for MinGW at same version of the ones for CYGWIN?

Hello, with reference to this thread: https://cygwin.com/pipermail/cygwin/2020-December/247106.html recently, GLM for CYGWIN has been updated to 0.9.9.5. I'm wondering if it would be possible to do the same thing and update the GLM packages for MinGW to the same version. An update will sim

[ANNOUNCEMENT] Updated: pcre2-10.36-1 / mingw-{i686, x86_64}-pcre2-10.36-1

The PCRE2 library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl, with just a few differences. This is a rebuild of the latest upstream release with gcc10, along with the latest patchset from Fedora. The MinGW packages have

[ANNOUNCEMENT] Rebuilt/Updated: pcre-8.44-1 / mingw-{i686, x86_64}-pcre-8.44-1

The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl, with just a few differences. This is a rebuild of the latest upstream release with gcc10, along with the latest patchset from Fedora. The MinGW packages have

Re: Unable to extract GMP version information from gmp_version :mingw

sing in one of the source directories. > > I found the button for plain text mode in yahoo. > > I will read up on cross compiling in the next day or two. I don't know what > packages to install for that in cygwin. I get : cross compiling ... no. > > They seem real

Fwd: Unable to extract GMP version information from gmp_version :mingw

Hi Brian and Achim, I built gnucobol with cygwin and mingw. I may not need cross compiling. I read that the permissions are easier to deal with in mingw so I got out the mingw tools. I thought that I'd try out deploying a program under mingw with cygwin outside cygwin without the permi

Fwd: Unable to extract GMP version information from gmp_version :mingw

Thanks Achim. I fixed the ld_library_path. I was wondering about the tip you gave me on devel packages not being split from runtime in mingw. Now I know for sure. I since added the bin directory to path for the mingw files for the x64 directory. Very cool. I have to crash now. I will work on

Re: Unable to extract GMP version information from gmp_version :mingw

standalone devel packages, only the Cygwin packages are split into runtime and devel. > I have the file libgmp.dll.a in c:/cygwin/lib That's not the link library for MingW, but for Cygwin. > Please let me know if there is anything i can do to get past this error. Maybe you look at some

thanks Brian! MinGW/cygwin. Have a cool weekend :-)

yahoo. I will read up on cross compiling in the next day or two. I don't know what packages to install for that in cygwin. I get : cross compiling ... no. They seem really interested in gnucobol with mingw related questions. Thanks for all of your help this weekend. roboloki -- Problem re

Re: Unable to extract GMP version information from gmp_version :mingw

On 2020-10-24 22:44, Jim McNamara via Cygwin wrote: > I am experimenting with mingW64 with cygwin. > My ./configure looks like this: > $ echo $LD_LIBRARY_PATHC:/cygwin/lib > $ ./configure --prefix=/home/user/cobol-3.1-rc1 --host=x86_64-w64-mingw32 > checking for gmp... nochecking for libgmp... noch

Unable to extract GMP version information from gmp_version :mingw

HI all- I am experimenting with mingW64 with cygwin. My ./configure looks like this: $ echo $LD_LIBRARY_PATHC:/cygwin/lib $ ./configure --prefix=/home/user/cobol-3.1-rc1 --host=x86_64-w64-mingw32 checking for gmp... nochecking for libgmp... nochecking gmp.h usability... yeschecking gmp.h presence.

Re: Default mingw _WIN32_WINNT

On 2020-05-11 12:53 pm, Yaakov Selkowitz wrote: I would just like to chime in that it would be a crying shame if Cygwin were to ever drop support for Windows 7. There are many people, myself one, who are dead set against Windows 10. "Ever"?!? You do realize that, ESU aside, Windows 7 is out

Re: Default mingw _WIN32_WINNT

On Mon, 2020-05-11 at 10:55 -0400, Chris Wagner wrote: > On 2020-05-05 5:05 am, Rainer Emrich wrote: > > Am 05.05.2020 um 10:54 schrieb Corinna Vinschen: > > > Therefore it might be a good idea to bump the default for these > > > Cygwin-related headers to at least 0x0600. > > > > > > Setting them

Re: Default mingw _WIN32_WINNT

On 2020-05-05 5:05 am, Rainer Emrich wrote: Hi Corinna, Am 05.05.2020 um 10:54 schrieb Corinna Vinschen: Therefore it might be a good idea to bump the default for these Cygwin-related headers to at least 0x0600. Setting them to 0x0602 sounds like a good idea, but as long as we didn't drop Vi

Re: Default mingw _WIN32_WINNT

me rule. In case 2, it's a legitimate goal to create executables still running on older versions of Windows. In how far changing _WIN32_WINNT makes sense or not for native development doesn't actually belong here, it would have to be discussed on the mingw-w64 mailing lists. > > Ya

Re: Default mingw _WIN32_WINNT

On Tue, 2020-05-05 at 10:54 +0200, Corinna Vinschen wrote: > On May 5 08:45, Biswapriyo Nath via Cygwin wrote: > > Chaging the defines in package may break others installation. > > No, it doesn't in this case. In what case would it? > Yaakov is talking about mingw-w64

Re: Problems with a combination of a mingw program, mintty, and CYGWIN=disable_pcon

ting to cout. It is cross-compiled as a mingw > program. I've been running it without problems fro over 2 years. Recently, I > updated cygwin to 3.1.4-1 and noticed the pcon support. Since then, the > output of my program has been messy: output lines have intermittent gaps in > th

Re: Problems with a combination of a mingw program, mintty, and CYGWIN=disable_pcon

Hi André, Thanks for the report. On Thu, 7 May 2020 03:38:25 + André Bleau via Cygwin wrote: > Hi cygwin users, > > I have cli program that I run with mintty. It is a simple C++ program, > reading from cin and outputing to cout. It is cross-compiled as a mingw > pro

Problems with a combination of a mingw program, mintty, and CYGWIN=disable_pcon

Hi cygwin users, I have cli program that I run with mintty. It is a simple C++ program, reading from cin and outputing to cout. It is cross-compiled as a mingw program. I've been running it without problems fro over 2 years. Recently, I updated cygwin to 3.1.4-1 and noticed the pcon su

Re: Default mingw _WIN32_WINNT

On May 5 10:06, JonY via Cygwin wrote: > On 5/5/20 9:05 AM, Rainer Emrich wrote: > > Hi Corinna, > > > > Am 05.05.2020 um 10:54 schrieb Corinna Vinschen: > >> Therefore it might be a good idea to bump the default for these > >> Cygwin-related headers to at least 0x0600. > >> > >> Setting them to

Re: Default mingw _WIN32_WINNT

On 5/5/20 9:05 AM, Rainer Emrich wrote: > Hi Corinna, > > Am 05.05.2020 um 10:54 schrieb Corinna Vinschen: >> Therefore it might be a good idea to bump the default for these >> Cygwin-related headers to at least 0x0600. >> >> Setting them to 0x0602 sounds like a good idea, but as long as we didn't

Re: Default mingw _WIN32_WINNT

Hi Corinna, Am 05.05.2020 um 10:54 schrieb Corinna Vinschen: > Therefore it might be a good idea to bump the default for these > Cygwin-related headers to at least 0x0600. > > Setting them to 0x0602 sounds like a good idea, but as long as we didn't > drop Vista or W7 support it might be premature

Re: Default mingw _WIN32_WINNT

On May 5 08:45, Biswapriyo Nath via Cygwin wrote: > Chaging the defines in package may break others installation. No, it doesn't in this case. Yaakov is talking about mingw-w64 headers used to create *Cygwin* applications using the occasional Windows function. Cygwin executables in th

Re: Default mingw _WIN32_WINNT

Chaging the defines in package may break others installation. You can set the version in source code as you need, for example: #undef _WIN32_WINNT #define _WIN32_WINNT 0x602 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:

Default mingw _WIN32_WINNT

JonY, In w32api-headers and mingw64-*-headers, the default value of _WIN32_WINNT can be configured at build-time with --with-default-win32- winnt=$VER, with the default still being 0x502 (XP x64/2003 R2). With 2008, 2008 R2, and 7 having gone out of support earlier this year, Server 2012 is now t

MinGW pkg-config not working (part 2)

le "/home/carlo/mylibrary". In this directory create a file called "test.pc" with these lines: Name: test Description: test MinGW pkg-config on CYGWIN Version: 1.2.3 Libs: Cflags: -I/home/carlo/mylibrary Finally, add this directory to PKG_CONFIG_PATH environment variable. Now, if y

Packaging request: mingw-w64 versions of libargon2

Hi (Yaakov!), Please could libargon2 be packaged for the two mingw-w64 builds? I've recently opened https://github.com/P-H-C/phc-winner-argon2/pull/285 which upstreams (and I think corrects) the patches in MSYS2. I also opened https://github.com/P-H-C/phc-winner-argon2/pull/286

Re: Mingw pkg-config not working

Hello, I would like to report that I updated to the latest release, I tried to do some tests and it really seems that it has resolved the issue on my side. Thank you very much for your support. Sincerely, Carlo Bramini. Il giorno lun 6 apr 2020 alle ore 18:44 Yaakov Selkowitz ha scritto: > > On

Re: Missing new.h and broken comdef.h in cygwin32-w32api-headers (and the mingw header packages too)

le or directory So, I copy new.h from the mingw headers (I'm using the cygwin compiler *not* mingw). Then, I get the following: Why do you think the mingw headers would work with Cygwin's compiler? From an API point of view, Cygwin is a POSIX system. If your software includes com

Missing new.h and broken comdef.h in cygwin32-w32api-headers (and the mingw header packages too)

I've been trying to compile something that uses comutil.h, which in turn includes comip.h and comdef.h (amongst others). First, I get a missing header error: /usr/include/w32api/comip.h:21:10: fatal error: new.h: No such file or directory So, I copy new.h from the mingw headers (I&#x

Re: Mingw pkg-config not working

On Sun, 2020-04-05 at 15:51 +0200, Carlo B. via Cygwin wrote: > I wanted to report that I received a reply on the issue that I had opened > here: > > https://todo.sr.ht/~kaniini/pkgconf/10#comment-7894 Thanks for following up. > The report has been closed and I got this reply: > > "You should

Re: Mingw pkg-config not working

Hello, I wanted to report that I received a reply on the issue that I had opened here: https://todo.sr.ht/~kaniini/pkgconf/10#comment-7894 The report has been closed and I got this reply: "You should use a symlink instead of a wrapper script when using the personality feature." I hope that some

Re: [PATCH] winsup/cygwin: remove defines added in mingw-w64 v7.0.0

On Apr 1 10:38, Corinna Vinschen wrote: > On Apr 1 11:20, Biswapriyo Nath via Cygwin wrote: > > Patch file attached. > > Thanks, but except for removing DiscardVirtualMemory, this won't work > for now. The Cygwin w32api headers on Fedora where I'm building > Cygwin are still version 5.0.4. > >

Re: [PATCH] winsup/cygwin: remove defines added in mingw-w64 v7.0.0

edora version gets bumped, I'll apply this patch. Corinna > From fcc8f83f4d47ba9f755725c64218f2f13e9a8e2d Mon Sep 17 00:00:00 2001 > From: Biswapriyo Nath > Date: Wed, 1 Apr 2020 11:20:00 +0530 > Subject: [PATCH] winsup/cygwin: remove defines added in mingw-w64 v7.0.0 >

[PATCH] winsup/cygwin: remove defines added in mingw-w64 v7.0.0

Patch file attached. From fcc8f83f4d47ba9f755725c64218f2f13e9a8e2d Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Wed, 1 Apr 2020 11:20:00 +0530 Subject: [PATCH] winsup/cygwin: remove defines added in mingw-w64 v7.0.0 Signed-off-by: Biswapriyo Nath --- winsup/cygwin/mmap.cc | 3

Re: Mingw pkg-config not working

Hello, I implemented the solution to this problem as a patch to pkgconf.cygport as requested. I attached small patch to this email, which resolved the troubles with CMake and Meson. I hope that you will find it useful and some developers will gently apply the correction to fix the issue. Thank yo

Re: Mingw pkg-config not working

Hello, I wanted to say that I modified the script in this way and it seems that it has resolved all issues: #!/bin/sh if [ "$#" -eq 1 ] && [ "$1" == "--version" ]; then exec pkgconf --version else exec pkgconf --personality=i686-w64-mingw32 $@ fi Fixing x64_64 is easy, I have just replaced i686-w

Re: Mingw pkg-config not working

On 20/02/2020 11:06, Carlo B. wrote: [...] x86_64-w64-mingw32-pkg-config are emulated with a shell script, for example the one for i686 is: #!/bin/sh exec pkgconf --personality=i686-w64-mingw32 $@ But while this solution mostly works when you exec it from the command line, it makes impossible t

Mingw pkg-config not working

Hello, I discovered that the mingw cross compilers for i686 and x86-64 have a problem with support of pkg-config. From what I have seen, the mingw included into CYGWIN is not using the usual pkg-config, but it uses pkgconf instead, which is a good thing at first sight, since it does not depend to

Re: cygwin mingw crosscompiler / readline bug

Auto-answer..he-he... > I'm trying to compile a standalone Windows-32 console application > using 'readline' with cygwin's 'i686-w64-mingw32-gcc' crosscompiler. > > I have a bug: readline repeates every input line to STDOUT on > Windows-32 application (running from the CMD.EXE, outside a Cygwin)

Re: Update mingw-w64 headers

On 2019-10-28 22:48, Biswapriyo Nath wrote: > I did not mean the release page [1]. I mean the cygwin headers is older > than the current mingw-w64 git repository [2]. The latest tag is v6.0.0. > [3] > > Wait, did you mean there should be a new "stable" tag or release in &

Re: Update mingw-w64 headers

I did not mean the release page [1]. I mean the cygwin headers is older than the current mingw-w64 git repository [2]. The latest tag is v6.0.0. [3] Wait, did you mean there should be a new "stable" tag or release in mingw-w64 so that cygwin can import it? [1]: http://mingw-w64.or

Re: Update mingw-w64 headers

On 2019-10-28 11:20, Biswapriyo Nath wrote: > The C header files are way behind the current mingw-w64 repository. Can you > update that package in cygwin? http://mingw-w64.org/doku.php/download is outdated: Cygwin was updated at the start of this year to the current mingw64 version 6:

Update mingw-w64 headers

The C header files are way behind the current mingw-w64 repository. Can you update that package in cygwin? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http

cygwin mingw crosscompiler / readline bug

> $ == My application: === #include #include #include #include int main(){ char* line; while (1) { line = readline("enter a string> "); add_history(line); if(line != NULL) { printf("You entered: %s\n", line); free(line); }else{ break;}

Re: libglut is missing library for MinGW static linking

On 9/27/2018 9:40 AM, Matt D. wrote: > libglut-devel provides libglut.a and libglut.dll.a but linking libglut.a > with either "-lglut" or "-lglut.dll" both depend on either cygglut-3.dll > or libglut-0.dll respectively when compiling for Cygwin or MinGW. >

libglut is missing library for MinGW static linking

libglut-devel provides libglut.a and libglut.dll.a but linking libglut.a with either "-lglut" or "-lglut.dll" both depend on either cygglut-3.dll or libglut-0.dll respectively when compiling for Cygwin or MinGW. I understand that this isn't a big deal for Cygwin binar

Re: What is Cygwin and MinGW [WAS: Request new Ruby release]

I'm moving this to the Cygwin-Talk list. On 5/14/2018 7:48 PM, Steven Penny wrote: > On Mon, 14 May 2018 10:31:18, cyg Simple wrote: >> And you a free to do so.  MinGW isn't GCC > > yes it is. when you compile GCC, as i have done: > > http://github.com/svnpenn/

re: U++ and mingw

Hi- I read up on mingw system. I now can use it with U++. I know cygwin has mingw packages. I'd rather just leave the gcc package set up without mingw and install mingw from outside of cygwin. I really like cygwin and will try to use it for Tcl even if I don't get the teacup sys

[ANNOUNCEMENT] MinGW GNOME 3.26 libraries

* mingw64-x86_64-libgsf1-1.14.42-1 * mingw64-x86_64-librest0.7-0.8.1-1 * mingw64-x86_64-librsvg2-2.40.20-1 * mingw64-x86_64-libsoup2.4-2.60.3-1 * mingw64-x86_64-pango1.0-1.40.14-1 This updates the GTK+/GNOME libraries for the MinGW-w64 cross-compiler toolchains to the 3.26 stable release. -- Yaakov

Re: Cannot install built library to mingw sysroot

Nvm I found solution already: http://cygwin.com/ml/cygwin/2010-04/msg00651.html -- 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

Cannot install built library to mingw sysroot

I have built and installed GraphicsMagick with this command: $ ../configure '--host=x86_64-w64-mingw32' '--disable-shared' --prefix=/usr/x86_64-w64-mingw32/sys-root/mingw CXXFLAGS="-flto -ffat-lto-objects" && make && make install Installation fail

Re: time command does not show CPU time for MinGW binaries

On 1/7/2018 10:38 AM, dan...@poradnik-webmastera.com wrote: > time command does not show CPU time for MinGW binaries. I have this > sample piece of code: > > #include > #include > > #define N 10 > #define K 1 > > double data[N]; > > int main() >

time command does not show CPU time for MinGW binaries

time command does not show CPU time for MinGW binaries. I have this sample piece of code: #include #include #define N 10 #define K 1 double data[N]; int main() { clock_t t = clock(); for (unsigned long n = 0; n < N; ++n) for (unsigned long k = 0; k <

  1   2   3   4   5   6   7   8   9   >