, by using the new
aarch64-w64-mingw32 cross compiler.
Unfortunately, I discovered that there was a bug in libtool that
blocked the creation of shared libraries with aarch64-w64-mingw32.
I reported the bug here:
https://savannah.gnu.org/support/?111081
and it has been fixed by a patch include
runtime and several libraries, not
> > released yet to my repository.
> > Although the "aarch64-w64-mingw32" target is still experimental, I
> > have to say that this cross compiler worked very well, at least until
> > now.
>
> Great work! We'd certainly wel
including binutils, gcc, mingw runtime and several libraries, not
released yet to my repository.
Although the "aarch64-w64-mingw32" target is still experimental, I
have to say that this cross compiler worked very well, at least until
now.
Great work! We'd certainly welcome and appre
libraries, not
released yet to my repository.
Although the "aarch64-w64-mingw32" target is still experimental, I
have to say that this cross compiler worked very well, at least until
now.
However, some problems appear because there are some thirdy party
tools not expecting to have mingw com
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 12/19/2020 2:37 AM, Lee via Cygwin wrote:
On 12/18/20, Brian Inglis wrote:
On 2020-12-17 20:45, Lee via Cygwin wrote:
Would someone please explain why adding "-static" makes
i686-w64-mingw32-gcc fail?
This works (or at least the compiler doesn't complain)
$ i686-w64-mingw
On 12/18/20, Brian Inglis wrote:
> On 2020-12-17 20:45, Lee via Cygwin wrote:
>> Would someone please explain why adding "-static" makes
>> i686-w64-mingw32-gcc fail?
>>
>> This works (or at least the compiler doesn't complain)
>>
>> $
On 2020-12-17 20:45, Lee via Cygwin wrote:
Would someone please explain why adding "-static" makes
i686-w64-mingw32-gcc fail?
This works (or at least the compiler doesn't complain)
$ i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix -lpcre
This does not w
Would someone please explain why adding "-static" makes
i686-w64-mingw32-gcc fail?
This works (or at least the compiler doesn't complain)
$ i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix -lpcre
This does not work
$ i686-w64-mingw32-gcc -o a.exe -static
Hello,
I was wondering if it would be possible to add libsoxr to the list of
the available packages for MINGW (32bit and 64bit).
This package is already available into cygwin, but not for MINGW.
Thank you very much for your time.
Sincerely.
--
Problem reports: http://cygwin.com/problems.htm
On 1/9/19, JonY wrote:
> On 1/9/19 7:43 PM, Lee wrote:
>>> MSVCR = MicroSoft Visual C Run-time (I think)
>>
>
> Yes, as implemented by msvcrt.dll.
cool - makes much more sense now. Thank you!
>> Meaning i686-w64-mingw32-gcc uses the Microsoft libraries vs. cygwi
ubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html
>>>>>> has a note for LC_MESSAGES:
>>>>>> The functionality described is an extension to the ISO C standard.
>>>>>> Application developers may make use of an extension as it is
>
On 1/9/19 7:43 PM, Lee wrote:
>> MSVCR = MicroSoft Visual C Run-time (I think)
>
Yes, as implemented by msvcrt.dll.
> Meaning i686-w64-mingw32-gcc uses the Microsoft libraries vs. cygwin
> gcc using posix compliant libraries? Implying LC_MESSAGES not being
> defined is yet a
.h.html
>>>>> has a note for LC_MESSAGES:
>>>>> The functionality described is an extension to the ISO C standard.
>>>>> Application developers may make use of an extension as it is
>>>>> supported on all POSIX.1-2017-conforming systems.
>&g
gt;The functionality described is an extension to the ISO C standard.
>>>>Application developers may make use of an extension as it is
>>>>supported on all POSIX.1-2017-conforming systems.
>>>>
>>>> i686-w64-mingw32-gcc doesn't have
use of an extension as it is
supported on all POSIX.1-2017-conforming systems.
i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined.
Is that an oversight, something missing in windows, or .. ??
Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be
referring to o
se of an extension as it is
>> supported on all POSIX.1-2017-conforming systems.
>>
>> i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined.
>> Is that an oversight, something missing in windows, or .. ??
>>
>
> Windows MSVCR isn't POSIX nor ISO C co
on all POSIX.1-2017-conforming systems.
>
> i686-w64-mingw32-gcc doesn't have LC_MESSAGES defined.
> Is that an oversight, something missing in windows, or .. ??
>
Windows MSVCR isn't POSIX nor ISO C compliant, so you shouldn't be
referring to opengroups, only against M
-mingw32-gcc doesn't have LC_MESSAGES defined.
Is that an oversight, something missing in windows, or .. ??
$ cat lcmessages.c
#include
#include
#include
#include
int main(int argc, char **argv )
{
char *s, *lang;
lang = getenv("LANG");
printf(" LANG=%s initial
In 2014 there was a query about i686-w64-mingw32-gcc in the case that
/usr/bin was not on the PATH, and the responses then said that the issue
would be fixed in the next release.
I got bitten now because when I use ssh to execute a command on a remote
cygwin64 system /bin gets on PATH but
r exit(), but not on abnormal
termination. Add fflush() calls to fix.
Works for me if one more overflow char is added:
Cygwin mintty:
$ ./ssp testtestx
main: argv[1]=testtestx
doit: s="testtestx" buf="12345678" i=1
doit: s="testtestx" buf="testtestx"
On 10/4/17, Christian Franke wrote:
> Lee wrote:
>> Maybe I'm just Doing It Wrong, but
>>gcc -fstack-protector-all
>> seems to be working correctly &
>>i686-w64-mingw32-gcc -fstack-protector-all
>> seems to be broken - eg:
>>
>> $./ss
Lee wrote:
Maybe I'm just Doing It Wrong, but
gcc -fstack-protector-all
seems to be working correctly &
i686-w64-mingw32-gcc -fstack-protector-all
seems to be broken - eg:
$./ssp testtestx
Illegal instruction
printf's that happen before the stack over-write don't show
Maybe I'm just Doing It Wrong, but
gcc -fstack-protector-all
seems to be working correctly &
i686-w64-mingw32-gcc -fstack-protector-all
seems to be broken - eg:
$./ssp testtestx
Illegal instruction
printf's that happen before the stack over-write don't show up &
On 9/8/17, Steven Penny wrote:
> On Fri, 8 Sep 2017 10:14:54, Lee wrote:
>> $ i686-w64-mingw32-gcc -o div.exe div.c
>> $ ./div
>> works
>>
>> $ i686-w64-mingw32-gcc -fstack-protector-strong -o div.exe div.c
>> $ ./div
>> C:/cygwin/home/Lee/t/
On 9/8/17, Yaakov Selkowitz wrote:
> On 2017-09-08 16:08, Lee wrote:
>> $ i686-w64-mingw32-gcc --version
>> i686-w64-mingw32-gcc (GCC) 6.3.0
>> Copyright (C) 2016 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is
On Fri, 8 Sep 2017 10:14:54, Lee wrote:
$ i686-w64-mingw32-gcc -o div.exe div.c
$ ./div
works
$ i686-w64-mingw32-gcc -fstack-protector-strong -o div.exe div.c
$ ./div
C:/cygwin/home/Lee/t/div.exe: error while loading shared libraries: ?:
cannot open shared object file: No such file or
On 2017-09-08 16:08, Lee wrote:
> $ i686-w64-mingw32-gcc --version
> i686-w64-mingw32-gcc (GCC) 6.3.0
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY o
On 9/8/17, Nellis, Kenneth wrote:
>> From: Lee
>> ...
>> Was there ever a man page for cygcheck? I remember looking at one,
>> but maybe I it was https://cygwin.com/cygwin-ug-net/cygcheck.html ??
>> $ man cygcheck
>> No manual entry for cygcheck
>>
>> $ info cygcheck
>> info: No menu item 'cygchec
> From: Lee
> ...
> Was there ever a man page for cygcheck? I remember looking at one,
> but maybe I it was https://cygwin.com/cygwin-ug-net/cygcheck.html ??
> $ man cygcheck
> No manual entry for cygcheck
>
> $ info cygcheck
> info: No menu item 'cygcheck' in node '(dir)Top'
Both man and info
On 9/8/17, Marco Atzeri wrote:
> On 08/09/2017 22:01, Lee wrote:
>> On 9/8/17, Marco Atzeri wrote:
>>> On 08/09/2017 20:53, Lee wrote:
>>>> On 9/8/17, Marco Atzeri wrote:
>>>>> On 08/09/2017 16:14, Lee wrote:
>> I've still got the '
On 08/09/2017 22:01, Lee wrote:
On 9/8/17, Marco Atzeri wrote:
On 08/09/2017 20:53, Lee wrote:
On 9/8/17, Marco Atzeri wrote:
On 08/09/2017 16:14, Lee wrote:
I've still got the 'i686-w64-mingw32-gcc -fstack-protector-strong' executable:
$ ./div.exe
C:/cygwin/home/Lee/t
On 9/8/17, Marco Atzeri wrote:
> On 08/09/2017 20:53, Lee wrote:
>> On 9/8/17, Marco Atzeri wrote:
>>> On 08/09/2017 16:14, Lee wrote:
>>>> I'm hoping that I'm just missing a library, but which one? Even
>>>> better, how to tell which on
On 08/09/2017 20:53, Lee wrote:
On 9/8/17, Marco Atzeri wrote:
On 08/09/2017 16:14, Lee wrote:
I'm hoping that I'm just missing a library, but which one? Even
better, how to tell which one?
$ i686-w64-mingw32-gcc -o div.exe div.c
$ ./div
works
$ i686-w64-mingw32-gcc -fstack
On 9/8/17, Marco Atzeri wrote:
> On 08/09/2017 16:14, Lee wrote:
>> I'm hoping that I'm just missing a library, but which one? Even
>> better, how to tell which one?
>>
>> $ i686-w64-mingw32-gcc -o div.exe div.c
>> $ ./div
>>works
>>
On 08/09/2017 16:14, Lee wrote:
I'm hoping that I'm just missing a library, but which one? Even
better, how to tell which one?
$ i686-w64-mingw32-gcc -o div.exe div.c
$ ./div
works
$ i686-w64-mingw32-gcc -fstack-protector-strong -o div.exe div.c
$ ./div
C:/cygwin/home/Lee/t/div.
I'm hoping that I'm just missing a library, but which one? Even
better, how to tell which one?
$ i686-w64-mingw32-gcc -o div.exe div.c
$ ./div
works
$ i686-w64-mingw32-gcc -fstack-protector-strong -o div.exe div.c
$ ./div
C:/cygwin/home/Lee/t/div.exe: error while loading shared
On Sat, 8 Jul 2017 13:45:38 +0100, Jon Turney wrote:
> The i686-pc-mingw32 toolchain was removed from Cygwin a while ago [1].
Many thanks - very enlightening! Obviously I missed this info. So a useless
patch.
> [1] https://cygwin.com/ml/cygwin-announce/2016-03/msg00069.html
--
P
On 08/07/2017 09:32, Jannick wrote:
On Jul 03, 2017 at 01:12 PM, Jannick wrote:
On Mon, 3 Jul 2017 09:25:51 +0200, Corinna Vinschen wrote:
[...]
I am not sure what the code basis of i686-pc-mingw32 is, so am back here on
this list with the patch.
Maybe there is someone out here who knows
mingw-w64 list turned out to be the wrong list, too, unfortunately.
For the MinGW32 distribution glob.h is maintained here
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/mingwrt/include/glob.h.
I am not sure what the code basis of i686-pc-mingw32 is, so am back here on
this
On Mon, 3 Jul 2017 09:25:51 +0200, Corinna Vinschen wrote:
> This is, in fact, the wrong mailing list. The files for the mingw
> cross build environment are maintained via the mingw-w64-public
> mailing list on sourceforge, see
>
> https://sourceforge.net/p/mingw-w64/mailman/
>
> Ideally yo
Hi Jannick,
On Jul 1 15:44, Jannick wrote:
> Attached a tiny patch to i686-pc-mingw32' glob.h which remedies a function
> prototype definition error thrown upon compilation.
>
> I am hoping that this is the correct one of cygwin's mail-lists, please
> advise otherwise
Attached a tiny patch to i686-pc-mingw32' glob.h which remedies a function
prototype definition error thrown upon compilation.
I am hoping that this is the correct one of cygwin's mail-lists, please
advise otherwise.
Thanks,
J.
---
C:/cygwin32/usr/i686-pc-mingw32/sys-root/min
On 8/28/2016 10:06 PM, Whek rin wrote:
> The utility x86_64-w64-mingw32-ld from package mingw-x86_64-binutils
> cannot by default find libraries from the path
> /usr/x86_64-w64-mingw32/sysroot/mingw/lib, where the package
> mingw64-x86_64-runtime installs them. I believe thi
On 8/29/2016 10:06, Whek rin wrote:
> The utility x86_64-w64-mingw32-ld from package mingw-x86_64-binutils
> cannot by default find libraries from the path
> /usr/x86_64-w64-mingw32/sysroot/mingw/lib, where the package
> mingw64-x86_64-runtime installs them. I believe thi
The utility x86_64-w64-mingw32-ld from package mingw-x86_64-binutils
cannot by default find libraries from the path
/usr/x86_64-w64-mingw32/sysroot/mingw/lib, where the package
mingw64-x86_64-runtime installs them. I believe this is a build
configuration issue. I've attached a zip file
On Wed, Feb 24, 2016 at 9:29 PM, Mark Geisert wrote:
> Just a guess: your 64-bit windres is generating a 64-bit .res file that the
> 32-bit g++ can't grok. Look at 'windres -h'. There's a "-F" == "--target"
> flag that can specify a target type. I would try adding "-F pe-i386" after
> the "-O c
> Jim Reisert AD1C wrote:
>> I have a 64-bit Cygwin environment. I'm trying to compile a 32-bit
>> (target) Windows program using i686-pc-mingw32-g++
>>
>> # i686-pc-mingw32-g++ -g -Wall -Iinclude -I../../library/include -c
>> -o NPOTAdlg.o NPOTAdlg.cpp
>
Jim Reisert AD1C wrote:
I have a 64-bit Cygwin environment. I'm trying to compile a 32-bit
(target) Windows program using i686-pc-mingw32-g++
# i686-pc-mingw32-g++ -g -Wall -Iinclude -I../../library/include -c
-o NPOTAdlg.o NPOTAdlg.cpp
# windres -Iinclude res/NPOTAdlg.rc -O coff -
I have a 64-bit Cygwin environment. I'm trying to compile a 32-bit
(target) Windows program using i686-pc-mingw32-g++
# i686-pc-mingw32-g++ -g -Wall -Iinclude -I../../library/include -c
-o NPOTAdlg.o NPOTAdlg.cpp
# windres -Iinclude res/NPOTAdlg.rc -O coff -o res/NPOTAdlg.res
# i6
On Apr 11 20:15, Randy Decker wrote:
> # Brief problem description
> # C source file - 'printf("Test");' added as diagnostics
> # Source compiles and executes in Ubuntu
> # Executable compiled in cygwin terminal OK in command prompt W8.1
> # - Also OK in another machine running Windows 8.1
>
testtext.txt
.bashrc cygwinResults.txt welcome.exe
.bashrc_ORG Hello.c x86_64-w64-mingw32-gcc.exe
.inputrc HelloFromUnix.c
.profile HelloFromUnix-PFEvsNotepad.c
# Show alias
Randy@Hartford ~
$ alias
alias gcc='C:/cygw
Today I have update my Cygwin and thus it started giving error at the
end of compiling. Using Compiler Mingw32 Libtool for cross platform
compiling
In function 'main':
xxx.c:315:3: warning: implicit declaration of function '_spawnv'
[-Wimplicit-functio
On 2014-04-30 18:50, Jim Reisert AD1C wrote:
Can anyone help me to use the POSIX regexp library (header regex.h)
with the i686-pc-mingw32-g++ compiler? I've searched through google
and I can't find any example of this.
mingw64-i686-libgnurx is available in Ports.
Yaakov
--
Probl
On Thu, May 1, 2014 at 7:38 AM, Jim Reisert AD1C wrote:
> #include
> #include
> #include
> #include
> #include
>
> #include
>
>
> results in:
>
> # i686-pc-mingw32-g++ -g -Wall -I../../library -c -o csv2adif.o csv2adif.cpp
>
> csv2adif.cpp:12
#include
#include
#include
#include
#include
#include
results in:
# i686-pc-mingw32-g++ -g -Wall -I../../library -c -o csv2adif.o csv2adif.cpp
csv2adif.cpp:12:19: fatal error: regex.h: No such file or directory
/usr/include/regex.h
/usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/bits
On Wed, Apr 30, 2014 at 05:50:45PM -0600, Jim Reisert AD1C wrote:
> Can anyone help me to use the POSIX regexp library (header regex.h)
> with the i686-pc-mingw32-g++ compiler? I've searched through google
> and I can't find any example of this.
>
> If this won&#
Can anyone help me to use the POSIX regexp library (header regex.h)
with the i686-pc-mingw32-g++ compiler? I've searched through google
and I can't find any example of this.
If this won't work, does anyone have a practical example of PCRE and
this compiler? It seems that there&#x
On 9/26/2013 19:03, Frédéric Bron wrote:
>> Compiled binary seems to crash here.
>> I updated mingw64 runtime/headers yesterday.
>>
>> $ echo "main(){}" >t.c && i686-w64-mingw32-gcc t.c -o t
>> $ ./t
>> Segmentation fault
>
>
Hi,
These have been updated:
mingw64-*-headers-3.0.0-1
mingw64-*-runtime-3.0.0-1
w32api-{headers,runtime}-3.0.0-1
Thanks, but it seems I'm already using those version.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation:
> Compiled binary seems to crash here.
> I updated mingw64 runtime/headers yesterday.
>
> $ echo "main(){}" >t.c && i686-w64-mingw32-gcc t.c -o t
> $ ./t
> Segmentation fault
These have been updated:
mingw64-*-headers-3.0.0-1
mingw64-*-runtime-3.0.0-1
w32a
Compiled binary seems to crash here.
I updated mingw64 runtime/headers yesterday.
$ echo "main(){}" >t.c && i686-w64-mingw32-gcc t.c -o t
$ ./t
Segmentation fault
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Docume
On 7/11/2013 06:28, JonY wrote:
> On 7/11/2013 06:12, Christian Franke wrote:
>>
>> If #pragma pack(1) is used instead, it works as expected also with
>> i686-w64-mingw32-gcc 4.7.3.
>>
>> (Upstream?) bug ?
>>
>
> Likely, there are no cygwin specific pa
On 7/11/2013 06:12, Christian Franke wrote:
>
> If #pragma pack(1) is used instead, it works as expected also with
> i686-w64-mingw32-gcc 4.7.3.
>
> (Upstream?) bug ?
>
Likely, there are no cygwin specific patches applied for it, please
check with gcc-help.
Thanks.
The new MinGW-w64 4.7.3 gcc apparently ignores __attribute__((packed)).
Cygwin's gcc 4.7.3 and older MinGW-w64 4.5.3 work as expected.
Testcase:
$ cat packed.c
struct packed { char a; short b; } __attribute__((packed));
int size = sizeof(struct packed);
$ i686-w64-mingw32-gcc --version
On 2013-06-22 14:07, Vasiliy wrote:
Please, take a look at:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h (why '/mingw/'?)
which has:
#include
which in turn causes a lot of conflicting types errors with winnt.h,
besides complaining wdm.h is not being found
http://cyg
Please, take a look at:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h (why '/mingw/'?)
which has:
#include
which in turn causes a lot of conflicting types errors with winnt.h,
besides complaining wdm.h is not being found
--
Problem reports: http://cygwin.com/pro
On Tue, Oct 30, 2012 at 07:45:07PM +, steve morris wrote:
>I'm trying to do builds using mingw32. This was working fine then it started
>failing. Now it fails every time. I don't recall making any cygwin related
>changes between the last work case and the first fail c
On Thu, Aug 30, 2012 at 6:10 AM, Sven Köhler wrote:
> Am 29.08.2012 18:08, schrieb thoni56:
>> "i686-w64-mingw32-gcc" (which it is in my cygwin) works perfectly. Thanks!
>
> That is actually not MinGW (formely known as mingw32),
It is no such thing. It is known as MinGW
Am 29.08.2012 18:08, schrieb thoni56:
> "i686-w64-mingw32-gcc" (which it is in my cygwin) works perfectly. Thanks!
That is actually not MinGW (formely known as mingw32), but MinGW-w64 (a
new project, independent from the "old" MinGW32 project).
That's why JonY pointe
JonY-6 wrote
>
> On 8/29/2012 14:15, thoni56 wrote:
>>
>> thoni56 wrote
>>>
>>> I'm in the process of going from gcc3 to gcc4. For one project I need to
>>> build both cygwin and win32 executables so "-mno-cygwin" to
>>>
On 8/29/2012 14:15, thoni56 wrote:
>
> thoni56 wrote
>>
>> I'm in the process of going from gcc3 to gcc4. For one project I need to
>> build both cygwin and win32 executables so "-mno-cygwin" to "mingw32-gcc"
>> was an initial hurdle.
>>
thoni56 wrote
>
> I'm in the process of going from gcc3 to gcc4. For one project I need to
> build both cygwin and win32 executables so "-mno-cygwin" to "mingw32-gcc"
> was an initial hurdle.
>
> However that is now sorted out, but one thing puz
I'm in the process of going from gcc3 to gcc4. For one project I need to
build both cygwin and win32 executables so "-mno-cygwin" to "mingw32-gcc"
was an initial hurdle.
However that is now sorted out, but one thing puzzles me. If the mingw32 is
a cygwin cross-compil
Just to close the loop on this for anyone who might be encountering a
similar issue or situation in the future, with the simple test example
info Ryan Johnson provided me in the previous response, I was able to
eventually narrow down my problem to a makefile complexity. The
makefile was setting th
On 08/06/2012 10:55 AM, Dennis Isenhour wrote:
On 2012-06-01 22:40, Greg Chicares wrote:
What if you use i686-pc-mingw32-g++ instead of i686-pc-mingw32-gcc?
I've tried that (so i'm no longer receiving the "unrecognized option"
warning message), but I must still be doing so
On 2012-06-01 22:40, Greg Chicares wrote:
What if you use i686-pc-mingw32-g++ instead of i686-pc-mingw32-gcc?
I've tried that (so i'm no longer receiving the "unrecognized option"
warning message), but I must still be doing something wrong as I'm
still having the same pr
Had to look up that acronym, and saw this one right above it:
TMTOWTDI
Oh the irony ;-)
Earnie Boyd wrote:
On Fri, Jun 1, 2012 at 1:29 PM, Dennis Isenhour wrote:
Can someone tell me, is static linking of libstdc++(-6 ?) not
currently supported in cygwin using the mingw compiler?
http
On 2012-06-01 17:29Z, Dennis Isenhour wrote:
>>
>> i686-pc-mingw32-gcc: unrecognized option '-static-libstdc++'
What if you use i686-pc-mingw32-g++ instead of i686-pc-mingw32-gcc?
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On Fri, Jun 1, 2012 at 1:29 PM, Dennis Isenhour wrote:
> Can someone tell me, is static linking of libstdc++(-6 ?) not
> currently supported in cygwin using the mingw compiler?
http://cygwin.com/acronyms/#TOFU
IDK, but maybe with -static-libstdc++ it would work.
--
Earnie
-- https://sites.googl
ll”.
>
> cygcheck: track_down: could not find libstdc++-6.dll
>
> I thus located ./gcc/i686-pc-mingw32/4.5.2/debug/libstdc++-6.dll and
> copied it to my local build area, which ultimately did in fact resolve
> my issue. However, I would prefer NOT to have to distribute this dll
failing because it could not locate “libstdc++-6.dll”.
cygcheck: track_down: could not find libstdc++-6.dll
I thus located ./gcc/i686-pc-mingw32/4.5.2/debug/libstdc++-6.dll and
copied it to my local build area, which ultimately did in fact resolve
my issue. However, I would prefer NOT to have to
gw64.sf.net
> a) 32bit
> b) 64bit
>
> Cygwin provides cross-compiler toolchains for each of these three "flavors":
>
> 1) i686-pc-mingw32-gcc
> 2a) i686-w64-mingw32-gcc
> 2b) x86_64-w64-mingw32-gcc
OK, thanks. The bottom line is that I should stick with
> a) 32bit
> b) 64bit
>
> Cygwin provides cross-compiler toolchains for each of these three "flavors":
>
> 1) i686-pc-mingw32-gcc
> 2a) i686-w64-mingw32-gcc
> 2b) x86_64-w64-mingw32-gcc
>
> The mingw.org compilers, cygwin's mingw.org-tar
re confused by the existence of the separate "mingw64" project.
There are three different "flavors" of mingw-ish compilers:
1. mingw.org (32bit only)
2. mingw64.sf.net
a) 32bit
b) 64bit
Cygwin provides cross-compiler toolchains for each of these three "fl
> * JonY [2011-08-22 18:05:33 +0800]:
>
> On 8/22/2011 09:26, Sam Steingold wrote:
>>> * Kai Tietz [2011-08-20
>>> 09:31:47 +0200]:
>>> 2011/8/20 JonY :
>>>>> /usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h:2922:26:
>>>
On 8/22/2011 09:26, Sam Steingold wrote:
>> * Kai Tietz [2011-08-20
>> 09:31:47 +0200]:
>> 2011/8/20 JonY :
>>>> /usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h:2922:26:
>>>> error: redeclaration of enumerator `WinRestrictedCodeSid'
&g
> * Kai Tietz [2011-08-20
> 09:31:47 +0200]:
> 2011/8/20 JonY :
>>> /usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h:2922:26:
>>> error: redeclaration of enumerator `WinRestrictedCodeSid'
>>> /usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:2
00]:
>>>>>>
>>>>>> You are supposed to use -I to add the ddk path to gcc.
>>>>>
>>>>> how?
>>>>> I mean, -Iddk does not work because I do not have ddk directory in my
>>>>> build directory.
>>>>
gt; You are supposed to use -I to add the ddk path to gcc.
>>>>
>>>> how?
>>>> I mean, -Iddk does not work because I do not have ddk directory in my
>>>> build directory.
>>>> how do I ask i686-w64-mingw32-gcc to print
>>>> /usr/
; >
>> > how?
>> > I mean, -Iddk does not work because I do not have ddk directory in my
>> > build directory.
>> > how do I ask i686-w64-mingw32-gcc to print
>> > /usr/i686-w64-mingw32/sys-root/mingw/include/ ??
>> > thanks!
>>
>
how?
>>> I mean, -Iddk does not work because I do not have ddk directory in my
>>> build directory.
>>> how do I ask i686-w64-mingw32-gcc to print
>>> /usr/i686-w64-mingw32/sys-root/mingw/include/ ??
>>> thanks!
>>
>> Try i686-w64-mingw32-gcc
directory in my
> > build directory.
> > how do I ask i686-w64-mingw32-gcc to print
> > /usr/i686-w64-mingw32/sys-root/mingw/include/ ??
> > thanks!
>
> Try i686-w64-mingw32-gcc -print-sysroot and append /mingw/include/ddk.
Or just use -I=/mingw/include/ddk
On 8/19/2011 07:37, Sam Steingold wrote:
>> * JonY [2011-08-19 06:39:03 +0800]:
>>
>> You are supposed to use -I to add the ddk path to gcc.
>
> how?
> I mean, -Iddk does not work because I do not have ddk directory in my
> build directory.
> how do I ask i68
> * JonY [2011-08-19 06:39:03 +0800]:
>
> You are supposed to use -I to add the ddk path to gcc.
how?
I mean, -Iddk does not work because I do not have ddk directory in my
build directory.
how do I ask i686-w64-mingw32-gcc to print
/usr/i686-w64-mingw32/sys-root/mingw/include/ ??
thanks
ently decided to make another effort to build boost with 1.7
> because I feel that it will be difficult to maintain my build chain
> based on cygwin 1.5.
>
> I realized that there are 2 mingw32 compilers coming with cygwin 1.7:
> i686-w64-mingw32 and i686-pc-mingw32.
> I im
On 8/18/2011 23:44, Sam Steingold wrote:
> Hi,
> I cannot
> #include
> because /usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntifs.h contains
> #include
> and actually lives in ddk, i.e., it should be
> #include
> after I aplly these two patches:
> --- c:/gnu/cygw
feel that it will be difficult to maintain my build chain
based on cygwin 1.5.
I realized that there are 2 mingw32 compilers coming with cygwin 1.7:
i686-w64-mingw32 and i686-pc-mingw32.
I imagine that they correspond to:
- w64 ->http://mingw-w64.sourceforge.net/
- pc -> http://mingw.org/
I
t;<'\n';
> return 0;
> }
>
> outputs:
> - 3.18 when built with i686-pc-mingw32-g++
> - 3.11 when built with i686-w64-mingw32-g++
> why?
> I have mingw-runtime version 3.18 installed. Is it used only by
> i686-pc-mingw32?
>
> I found that:
>
1 - 100 of 197 matches
Mail list logo
