Zartaj Majeed via Cygwin writes:
> The latest GCC 13.4 package is not configured with --enable-checking=release
Read the gcc documentation:
When the option is not specified, the active set of checks depends on
context. Namely, bootstrap stage 1 defaults to ‘--enable-checking=yes’,
builds f
Zartaj Majeed via Cygwin writes:
> The latest GCC 13.4 package is not configured with --enable-checking=release
Read the gcc documentation:
When the option is not specified, the active set of checks depends on
context. Namely, bootstrap stage 1 defaults to ‘--enable-checking=yes’,
builds f
The latest GCC 13.4 package is not configured with --enable-checking=release
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/13/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/mnt/share/packages/gccmake/gcc-13/gcc/gcc.x86_64/src/gcc
Zartaj Majeed via Cygwin writes:
> GCC on Cygwin is not configured with --enable-checking=release. This
> makes the compiler run very slow due to extra diagnostic checks.
How about you don't install the absolutely latest test version (from a
gcc snapshot) and instead chose a release
GCC on Cygwin is not configured with --enable-checking=release. This makes the
compiler run very slow due to extra diagnostic checks.
I'm seeing C++ compile 10 times slower on Cygwin
Here's GCC configure options and the warning message about extra diagnostics on
Cygwin compared
as the need arises when revised or new {source}/*.c occur.
> After creating the archive myx0.a the key gcc command line is
> $ gcc -w -static -o myx -O3 ./myx0.a -lreadline -lncurses -lm
> This worked flawlessly up to and including readline-8.1.2 but failed with
> 8.2.2 and this week
and make sure that
/usr/local/lib is searched before /lib, by using suitable -L options.
Note that ld's man page says that -L specified directories are searched
*before* the default directories. Thus: -L/usr/local/lib in this case.
While you can do complicated things with gcc and ld, m
myx0.a the key gcc command line is
$ gcc -w -static -o myx -O3 ./myx0.a -lreadline -lncurses -lm
This worked flawlessly up to and including readline-8.1.2 but failed with 8.2.2
and this week's latest update to 8.3.1.
To get the compilation to work it is (thank Goodness) not necessary to r
On 13/05/2025 18:24, ASSI via Cygwin wrote:
Hamish McIntyre-Bhatty via Cygwin writes:
I've run into a blocker when trying to build wxPython that wasn't a
problem when I last did it (which amittedly was over a year ago). Some
-werror flags are being passed to GCC, but I can't se
On 2025-05-26 12:27, Arthur Schwarz wrote:
Hi Brian;
I'm trying to track down the gcc linker (ld) manual. Any idea where I can find
it?
$ cygcheck -f /usr/bin/ld
binutils-2.44-1
https://cygwin.com/packages/summary/binutils-src.html
https://www.gn
Hi Brian;
I'm trying to track down the gcc linker (ld) manual. Any idea where I
can find it?
I've looked at the gcc site (gcc.gnu.org/onlinedocs/) and it's not
there. I did a google search and found a 1998 linker manual. I looked at
the local cygwin (/usr/share/doc) and there
Thanks.
Just downloaded all the documents (the easy part), now comes the reading.
art
On 5/23/2025 6:40 AM, Jon Turney wrote:
On 23/05/2025 14:30, skidmarks via Cygwin wrote:
[...]
Thanks!
g++ -shared -flinker-output=dyn -o slip.dll *.o
ran with not errors.
Is there any documentation ava
On 23/05/2025 14:30, skidmarks via Cygwin wrote:
[...]
Thanks!
g++ -shared -flinker-output=dyn -o slip.dll *.o
ran with not errors.
Is there any documentation available on cygwin specific issues?
This seems like a question that I should be able to answer on my
own.
Indeed. We do ask people
> On 2025-05-22 12:37, Arthur Schwarz via Cygwin wrote:
> > I can't figure this one out.
> >
> > > clear;g++ -flinker-output=dyn -o slip.dll *.o
> >
> > generates:
> >
> >
/usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-
On Thu, May 22, 2025 at 1:58 PM lostbits via Cygwin wrote:
>
> Win 11-64
>
> Are the version numbers for gcc correct? You have listed the latest gcc
> (version 15.1) when I search packages but:
>
> > gcc --version
>
> shows version 12.4.0. My setup-x86_64.exe ver
On 2025-05-22 12:37, Arthur Schwarz via Cygwin wrote:
I can't figure this one out.
> clear;g++ -flinker-output=dyn -o slip.dll *.o
generates:
/usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: /usr/lib/
gcc/x86_64-pc-cygwin/12/../../../../lib/libcygwin.a(libcmai
:
Win 11-64
Are the version numbers for gcc correct? You have listed the latest
gcc (version 15.1) when I search packages but:
> gcc --version
shows version 12.4.0. My setup-x86_64.exe version is 2.933.
The version shown in the local update pop-up is 12.4.0-3. How do I get
later versi
I can't figure this one out.
> clear;g++ -flinker-output=dyn -o slip.dll *.o
generates:
/usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld:
/usr/lib/gcc/x86_64-pc-cygwin/12/../../../../lib/libcygwin.a(libcmain.o):
in function `main':
/usr/src/debug/cygwin-3
Win 11-64
Are the version numbers for gcc correct? You have listed the latest gcc
(version 15.1) when I search packages but:
> gcc --version
shows version 12.4.0. My setup-x86_64.exe version is 2.933.
The version shown in the local update pop-up is 12.4.0-3. How do I get
later versi
Hamish McIntyre-Bhatty via Cygwin writes:
> I've run into a blocker when trying to build wxPython that wasn't a
> problem when I last did it (which amittedly was over a year ago). Some
> -werror flags are being passed to GCC, but I can't see where they're
> coming
On 08/05/2025 20:59, Brian Inglis via Cygwin wrote:
On 2025-05-08 13:25, Hamish McIntyre-Bhatty via Cygwin wrote:
I've run into a blocker when trying to build wxPython that wasn't a
problem when I last did it (which amittedly was over a year ago). Some
-werror flags are being pas
On 2025-05-08 13:25, Hamish McIntyre-Bhatty via Cygwin wrote:
I've run into a blocker when trying to build wxPython that wasn't a problem when
I last did it (which amittedly was over a year ago). Some -werror flags are
being passed to GCC, but I can't see where they're co
Hi there,
I've run into a blocker when trying to build wxPython that wasn't a
problem when I last did it (which amittedly was over a year ago). Some
-werror flags are being passed to GCC, but I can't see where they're
coming from. Are there any defaults set for GCC that me
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.
Reg
The gcc-gdc package (currently in version 11.5.0) [1] lacks
the *.d files of the standard library (libphobos, including druntime).
How to reproduce:
hello.d
import std.stdio;
void main ()
{
writeln("Hello world!");
}
=
$ g
Am 08.01.2025 um 11:24 schrieb ASSI:
The native Gcc compilers have been updated to the latest upstream
snapshot version of the main development branch:
gcc-15.0.1+20250105
gcc -v still says 15.0.0
This build incorporates the experimental v4 patch from T. Yano to use
the newlib locale
Thomas Wolff via Cygwin writes:
> gcc 14 and gcc 15 exhibit a mysterious compilation failure for mintty:
> In file included from /usr/include/w32api/windows.h:70,
> from /usr/include/w32api/wtypesbase.h:12,
> from /usr/include/w32ap
Am 01.12.2024 um 21:20 schrieb ASSI:
The native Gcc compilers have been updated to the latest upstream
snapshot version of the gcc-13 branch:
gcc-14.2.1+20241130
This build incorporates the experimental v4 patch from T. Yano to use
the newlib locale function in libstdc++ so that other
Am 04.11.2024 um 21:26 schrieb Brian Inglis via Cygwin:
On 2024-11-04 12:00, ASSI wrote:
The native Gcc compilers have been updated to the latest upstream
snapshot version of the gcc-13 branch:
gcc-14.2.1+20241102
This build incorporates the experimental v4 patch from T. Yano to use
the
On 2024-11-04 12:00, ASSI wrote:
The native Gcc compilers have been updated to the latest upstream
snapshot version of the gcc-13 branch:
gcc-14.2.1+20241102
This build incorporates the experimental v4 patch from T. Yano to use
the newlib locale function in libstdc++ so that other locales
Takashi Yano via Cygwin writes:
> This release does not seem to be applied '-mno-align-vector-insn'
> patch. Is this intentional?
Yes.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downlo
On Sun, 04 Aug 2024 21:50:40 +0200
ASSI wrote:
> The mingw64 cross compilers have been updated for both architectures to
> the latest upstream release version of the gcc-11 branch:
>
> mingw64-i686-gcc-12.4.0-1-src
> mingw64-i686-gcc-core-12.4.0-1
> mingw64-i686-gcc-
On 2024-08-04 13:50, ASSI wrote:
The mingw64 cross compilers have been updated for both architectures to
the latest upstream release version of the gcc-11 branch:
> 12 <
mingw64-i686-gcc-12.4.0-1-src
mingw64-i686-gcc-core-12.4.0-1
m
I have file this bug with GCC:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115524
On Sat, Jul 27, 2024 at 8:02 PM ASSI via Cygwin wrote:
> ASSI via Cygwin writes:
> > This sounds like it might be a bug in newlib, so you should either
> > report it there or else it woul
easier (more targeted) workaround for the underlying stack data
> > alignment problem when passing vector datatypes by value (which is due
> > to a conflict with alignment requirements for SEH and remains unsolved
> > upstream). You can also use '-Wa,-muse-unaligned-vect
t problem when passing vector datatypes by value (which is due
> to a conflict with alignment requirements for SEH and remains unsolved
> upstream). You can also use '-Wa,-muse-unaligned-vector-move', which is
> more widely available.
gcc of MSYS2 enables -mno-align-vector-insn f
ASSI via Cygwin writes:
> This sounds like it might be a bug in newlib, so you should either
> report it there or else it would be the newlib integration for gcc. In
> any case this needs to be fixed upstream.
The latter turns out to be the case, this is actually the same bug (and
will
table.
>
> Also, it is reported as printable by `std::iswprint(int ch)`.
>
> Also, the non-wide space character is reported as printable, i.e,
> `std::use_facet>(loc)::is(std::ctype_base::print, ' ')` is
> `true`.
>
> Also, `ctype.is(std::ctype_base::print, ctype.widen(&#x
Richard via Cygwin writes:
> As anticipated, after further investigation, it is NOT a
> Cygwin-related issue, hence I withdraw my request with apologies for
> noise.
You didn't say what you are trying to achieve, but since the exercise
seems to be to learn something about Linux kernel (module) pro
Sirs:
As anticipated, after further investigation, it is NOT a Cygwin-related issue,
hence I withdraw my request with apologies for noise.
FWIW and benefit of future readers (or victims), let it be noted that the
compiler is reacting to the architecture-related parameter '-mmodel=kernel', as
i
Cygwin-related per se and any advice at this
junction is well come.
It seems that world knows something about this situation that escapes me
entirely...
If it is the case, I am happy to offer additional contextual info upon request.
As a very important observation, please note that gcc is invoked
Hi!
I am the maintainer for the bioinformatics tool suite MMseqs2.
We build Windows binaries for our windows users with Cygwin for many years
without major issues. Thanks a lot!
This weeks' GCC 12.4 update seems to have introduced issues with OpenMP.
Every command line invocation that
On 15/07/2024 22:44, Mark Liam Brown via Cygwin wrote:
On Mon, Jul 15, 2024 at 9:35 PM Csaba Ráduly via Cygwin
wrote:
On 09/07/2024 08:17, Cedric Blancher via Cygwin wrote:
I'd agree that newer gcc 13.x to compile Cygwin and as /usr/bin/gcc
would be a very good idea, not only for perfor
On 2024-07-15 14:44, Mark Liam Brown via Cygwin wrote:
On Mon, Jul 15, 2024 at 9:35 PM Csaba Ráduly via Cygwin wrote:
On 09/07/2024 08:17, Cedric Blancher via Cygwin wrote:
I'd agree that newer gcc 13.x to compile Cygwin and as /usr/bin/gcc
would be a very good idea, not only for perfor
On Mon, Jul 15, 2024 at 9:35 PM Csaba Ráduly via Cygwin
wrote:
>
> On 09/07/2024 08:17, Cedric Blancher via Cygwin wrote:
> > I'd agree that newer gcc 13.x to compile Cygwin and as /usr/bin/gcc
> > would be a very good idea, not only for performance+STL fixes, but
> &
On 09/07/2024 08:17, Cedric Blancher via Cygwin wrote:
I'd agree that newer gcc 13.x to compile Cygwin and as /usr/bin/gcc
would be a very good idea, not only for performance+STL fixes, but
also since by default the Cygwin distro lacks C++17 support,
Huh? GCC supports C++17 since GCC 7
On 2024-07-09 00:17, Cedric Blancher via Cygwin wrote:
On Sat, 6 Jul 2024 at 21:55, Mark Liam Brown wrote:
Cygwin gcc is currently stuck at version 11.4:
$ gcc --version
gcc (GCC) 11.4.0
I would politely request an urgent update to GCC 13.3 (not 14.1, 13.3
is considered mature), as 11.4 causes
On Sat, 6 Jul 2024 at 21:55, Mark Liam Brown via Cygwin
wrote:
>
> Greetings!
>
> Cygwin gcc is currently stuck at version 11.4:
> $ gcc --version
> gcc (GCC) 11.4.0
>
> I would politely request an urgent update to GCC 13.3 (not 14.1, 13.3
> is considered mature), as
On Sat, Jul 06, 2024 at 09:53:00PM +0200, Mark Liam Brown via Cygwin wrote:
> Greetings!
>
> Cygwin gcc is currently stuck at version 11.4:
> $ gcc --version
> gcc (GCC) 11.4.0
>
> I would politely request an urgent update to GCC 13.3 (not 14.1, 13.3
> is considered
Greetings!
Cygwin gcc is currently stuck at version 11.4:
$ gcc --version
gcc (GCC) 11.4.0
I would politely request an urgent update to GCC 13.3 (not 14.1, 13.3
is considered mature), as 11.4 causes severe problems:
1. Securly updates in the STL are not available in Cygwin
2. Everything relying
ter is reported as printable, i.e,
`std::use_facet>(loc)::is(std::ctype_base::print, ' ')` is
`true`.
Also, `ctype.is(std::ctype_base::print, ctype.widen(' '))` is `true` with
MinGW, with GCC on Linux, and with Visual Studio.
The problem can be demonstrated with the code b
On 22/05/2024 00:30, Dan Shelton via Cygwin wrote:
Hello!
Can Cygwin gcc or clang be used to use ucrt instead of cygwin.dll/mingw.dll?
We provide a cross-compiler targeting the Win32 API, but this only
support msvcrt currently.
[1] https://cygwin.com/faq.html#faq.programming.win32-no
Hello!
Can Cygwin gcc or clang be used to use ucrt instead of cygwin.dll/mingw.dll?
Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
On 2024-04-19 15:39, René Berber via Cygwin wrote:
On 4/19/2024 2:59 PM, Arnab Paul via Cygwin wrote:
Hello,
I am trying to install a software which requires the libraries gcc-fortran,
make, libarpack-devel, liblapack-devel, libnetcdf-fortran-devel, git.
As I did and ran the commands given
On 4/19/2024 2:59 PM, Arnab Paul via Cygwin wrote:
Hello,
I am trying to install a software which requires the libraries gcc-fortran,
make, libarpack-devel, liblapack-devel, libnetcdf-fortran-devel, git.
As I did and ran the commands given below,
git clone https://github.com/Aida-Alvera/DINEOF
Hello,
I am trying to install a software which requires the libraries gcc-fortran,
make, libarpack-devel, liblapack-devel, libnetcdf-fortran-devel, git.
As I did and ran the commands given below,
git clone https://github.com/Aida-Alvera/DINEOF
cd DINEOF/
cp config.mk.template config.mk
make
The
On 14/03/2024 18:34, Thomas Hedden via Cygwin wrote:
I installed a test version of gcc and cannot revert to an earlier,
non-test version. Here are the latest versions listed in the setup routine:
11.4.0-1
12.3.1+20240202-0.1 (Test)
13.2.1+20240203-0.1 (Test)
(there are some even older ones
I installed a test version of gcc and cannot revert to an earlier,
non-test version. Here are the latest versions listed in the setup routine:
11.4.0-1
12.3.1+20240202-0.1 (Test)
13.2.1+20240203-0.1 (Test)
(there are some even older ones, but I want 11.4.0-1.)
$ gcc --version
gcc (GCC) 13.2.1
On Mon, Feb 26, 2024 at 10:49:55AM -0700, Brian Inglis via Cygwin wrote:
> On 2024-02-25 21:33, gs-cygwin.com--- via Cygwin wrote:
> > Does gcc now depend on libintl-devel ? Is this dependency declared?
> >
> > Along with the release of cygwin 3.5.0, my CI on github start
On 2024-02-25 21:33, gs-cygwin.com--- via Cygwin wrote:
Does gcc now depend on libintl-devel ? Is this dependency declared?
Along with the release of cygwin 3.5.0, my CI on github started failing,
where autoconf would report that a working C compiler was not found for
the Cygwin build.
The
Does gcc now depend on libintl-devel ? Is this dependency declared?
Along with the release of cygwin 3.5.0, my CI on github started failing,
where autoconf would report that a working C compiler was not found for
the Cygwin build.
The github workflow in question: search for "Windows-Cygwi
Takashi Yano via Cygwin writes:
> Thank you for releasing this test version!
Thank you for providing the locale patch.
> Does not this include AVX2 misalignd patch for
> https://cygwin.com/pipermail/cygwin/2023-December/255073.html
> introduced by lazka on IRC and GTHREAD mutex_init patch
> http
On Mon, 5 Feb 2024 06:27:43 +0900
Takashi Yano wrote:
> On Sun, 04 Feb 2024 21:52:46 +0100
> ASSI wrote:
> > The native Gcc compilers have been updated to the latest upstream
> > snapshot version of the gcc-12 branch:
> >
> > gcc-12.3.1+20240202
> >
> >
On Sun, 04 Feb 2024 21:52:46 +0100
ASSI wrote:
> The native Gcc compilers have been updated to the latest upstream
> snapshot version of the gcc-12 branch:
>
> gcc-12.3.1+20240202
>
> This build incorporates the experimental v4 patch to use the newlib
> locale function
Hi,
I encountered the problem that the avx2 code crashes with segfault.
This happens if the cygwin gcc or cygwin mingw gcc compiler is used.
To reproduce the problem, compile the following test case with:
gcc -O0 avx2test.c -mavx2 -o avx2test
or
x86_64-w64-mingw32-gcc -O0 avx2test.c -mavx2 -o
Harry Rockefeller via Cygwin writes:
> It says "installed package gcc-core obsoletes gcc-ada (of same version
> number) do not ask to install"
That was a bug in the hint file, should be fixed.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blof
On 9/7/2023 7:00 PM, Harry Rockefeller via Cygwin wrote:
The message I get when trying to install gcc-ada 11.4.0-1 doesn't make
sense.
It says "installed package gcc-core obsoletes gcc-ada (of same version
number) do not ask to install"
When I run cygcheck on this package:
with -
The message I get when trying to install gcc-ada 11.4.0-1 doesn't make
sense.
It says "installed package gcc-core obsoletes gcc-ada (of same version
number) do not ask to install"
When I run cygcheck on this package:
with -c it says it is "OK";
with -l and pipe to grep it
The native Gcc compilers have been updated to the latest upstream
snapshot version of the gcc-12 branch:
gcc-12.3.0+20230901
and the gcc-13 branch:
gcc-13.2.0+20230902
Cygwin does not allow multiple versions of the compilers to be installed
concurrently.
For this build, the D compiler has
Jose Isaias Cabrera via Cygwin writes:
>> Actually it's the first time it is officially available on Cygwin
>> (and without a working runtime the next major release of gcc will
>> again have to drop it as it would no longer bootstrap).
>
> Darn it! Darn D people. :-
The mingw64 cross compilers have been updated for both architectures to
the latest upstream release version of the gcc-11 branch:
mingw64-i686-gcc-11.4.0-1-src
mingw64-i686-gcc-core-11.4.0-1
mingw64-i686-gcc-debuginfo-11.4.0-1
mingw64-i686-gcc-fortran-11.4.0-1
mingw64-i686-gcc-g++-11.4.0-1
On June 6, 2023 1:38 PM, Achim Gratz expressed:
>
> Jose Isaias Cabrera via Cygwin writes:
> > On June 5, 2023 4:27 PM, Achim Gratz expressed:
> >
> >> gcc-gdc-11.4.0-1
> >
> > Thank you for bringing GDC back.
>
> Actually it's the first time i
Jose Isaias Cabrera via Cygwin writes:
> On June 5, 2023 4:27 PM, Achim Gratz expressed:
>
>> gcc-gdc-11.4.0-1
>
> Thank you for bringing GDC back.
Actually it's the first time it is officially available on Cygwin (and
without a working runtime the next major release of
On June 5, 2023 4:27 PM, Achim Gratz expressed:
> gcc-gdc-11.4.0-1
Thank you for bringing GDC back.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: ht
The native Gcc compilers have been updated to the latest upstream
release version of the gcc-11 branch:
gcc-11.4.0-1-src
gcc-ada-11.4.0-1
gcc-core-11.4.0-1
gcc-debuginfo-11.4.0-1
gcc-fortran-11.4.0-1
gcc-g++-11.4.0-1
gcc-gdc-11.4.0-1
gcc-objc++-11.4.0-1
gcc-objc-11.4.0-1
libatomic1
The scripts are uploaded to github
https://github.com/xu-chiheng/Tool
On Tue, May 16, 2023 at 11:10 AM 徐持恒 Xu Chiheng wrote:
>
> These are the scripts I used internally.
>
> The scripts are started by bash -i, they will source the ~/.bashrc
> file at startup, so they can use the convenient bash f
_build_type_toolchain_and_set_compiler_flags() {
if [ -z "${BUILD_TYPE}" ];then
BUILD_TYPE=Release
fi
if [ -z "${TOOLCHAIN}" ];then
TOOLCHAIN=GCC
fi
case "${BUILD_TYPE}" in
Release | Debug )
echo "build t
Ken Brown via Cygwin writes:
> On 3/11/2023 1:50 PM, Achim Gratz via Cygwin wrote:
>> The native Gcc compilers have been updated to the latest upstream
>> snapshot version of the gcc-11 branch:
>> gcc-11.3.1+20230310
>
> I've given it a pretty good workout w
On 3/11/2023 1:50 PM, Achim Gratz via Cygwin wrote:
The native Gcc compilers have been updated to the latest upstream
snapshot version of the gcc-11 branch:
gcc-11.3.1+20230310
Thanks!
I've given it a pretty good workout with builds of Emacs and TeX Live,
and everything seems good s
The native Gcc compilers have been updated to the latest upstream
snapshot version of the gcc-11 branch:
gcc-11.3.1+20230310
This release includes libgccjit as a separate package for the native
toolchain. Since Cygwin does not yet enable ASLR by default, any
nontrivial dynamic objects that
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
On 2023-01-17 15:25, Don Kuenz via Cygwin wrote:
Greetings,
Back in the day i686-pc-mingw32-gcc used the -mno-cygwin flag to break
the implicit link to cygwin1.dll. It enabled developers to release a
standalone binary. In other words, cygwin1.dll did not have to be
installed on the user's
Greetings,
Back in the day i686-pc-mingw32-gcc used the -mno-cygwin flag to break
the implicit link to cygwin1.dll. It enabled developers to release a
standalone binary. In other words, cygwin1.dll did not have to be
installed on the user's PC in order for a standalone binary to run.
i6
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 fil
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.
ing a Unix-like environment.
The correct solution thus becomes "Don't do that, then." Fix the
build system detection to recognize Cygwin as a type of Unix, and
things will almost certainly just work.
It also depends on how your application, in this case gcc or rather cpp,
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
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++ "bar/main.cpp"` works as exp
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
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 -mwin32
Is that a cygwin s
Hi folks,
Any plans to follow Fedora and default gcc 12 options to -fno-omit-frame-pointer
and/or use -fno-omit-frame-pointer and _FORTIFY_SOURCE=3 in cygwin and package
builds?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte
Hi folks,
Any plans to follow Fedora and default gcc 12 options to -fno-omit-frame-pointer
and/or use -fno-omit-frame-pointer and _FORTIFY_SOURCE=3 in cygwin and package
builds?
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte
>>> 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
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
>> 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
&
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}'
ld:
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
1 - 100 of 4638 matches
Mail list logo
