env var or mount option for multibyte<->unicode filenames conversion
Hi. Currently, the code page for internal convertion of file names to unicode depends on programs's locale. I want to keep UTF-8 as current locale, but use CP1251 for this conversion. Is it possible? -- 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
Re: i686-XXX-mingw32 compilers and __MINGW32_MINOR_VERSION macro: 3.18 or 3.11?
On 8/18/2011 13:44, Frédéric Bron wrote:
> Using cygwin 1.7.9(0.237/5/3) 2011-03-29 10:10.
>
> The following program:
>
> #include
> int main() {
>
> std::cout<<__MINGW32_MAJOR_VERSION<<'.'<<__MINGW32_MINOR_VERSION<<'\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:
> $ grep -r "#define *__MINGW32_MINOR_VERSION" /usr/i686-pc-mingw32/
> /usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h:#define
> __MINGW32_MINOR_VERSION 18
> and
> $ grep -r "#define *__MINGW32_MINOR_VERSION" /usr/i686-w64-mingw32/
> /usr/i686-w64-mingw32/sys-root/mingw/include/_mingw_mac.h:#define
> __MINGW32_MINOR_VERSION 11
>
> This seems to be one of the reasons that prevents me to use boost on cygwin
> 1.7.
>
> Regards,
>
> Frédéric
>
Just bump it up and see if there are any issues, the mingw-w64 toolchain
uses its own header set and the numbers don't always reflect mingw.org
releases, since the macros in there are mainly for compatibility.
You want to check instead for __MINGW64_VERSION_MAJOR on mingw-w64.
signature.asc
Description: OpenPGP digital signature
Re: env var or mount option for multibyte<->unicode filenames conversion
On Aug 18 14:19, Ilya Basin wrote: > Hi. Currently, the code page for internal convertion of file names to > unicode depends on programs's locale. > I want to keep UTF-8 as current locale, but use CP1251 for this > conversion. Is it possible? Maybe if you describe your problem slightly more detailed? Why would you want CP1251 in a Cygwin application if all other apps are using UTF-8? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Gawk error under Cygwin
Hi all, I encounter a strange behavior of gawk under cygwin: Using awk -f somescript.awk works fine except NaN handling which is switched on by --posix but awk --posix -f somescript.awk produces an error awk somescript.awk:29: Fatal: Funktion 'systime' ist nicht definiert. (systime not defined) What is going wrong here ?? Have fun Norbert -- Dipl. Phys. Norbert Zacharias Wind Measurements & Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this email. -- 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
Re: Gawk error under Cygwin
On Aug 18 15:00, DEWI - N. Zacharias wrote: > > Hi all, > > I encounter a strange behavior of gawk under cygwin: > > Using > awk -f somescript.awk > > works fine except NaN handling which is switched on by --posix but > > awk --posix -f somescript.awk > > produces an error > > awk somescript.awk:29: Fatal: Funktion 'systime' ist nicht definiert. > (systime not defined) > > What is going wrong here ?? Try `gawk --lint -f somescript.awk' Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
AW: [bulk] - Re: Gawk error under Cygwin
Hi Corrina, > Von: Corinna Vinschen > Gesendet: Donnerstag, 18. August 2011 15:21 > Betreff: [bulk] - Re: Gawk error under Cygwin > > On Aug 18 15:00, DEWI - N. Zacharias wrote: > > > > Hi all, > > > > I encounter a strange behavior of gawk under cygwin: > > > > Using > > awk -f somescript.awk > > > > works fine except NaN handling which is switched on by --posix but > > > > awk --posix -f somescript.awk > > > > produces an error > > > > awk somescript.awk:29: Fatal: Funktion 'systime' ist nicht definiert. > > (systime not defined) > > > > What is going wrong here ?? > > Try `gawk --lint -f somescript.awk' Thanks that helps! The problem was again in front of the computer. I used awk instead of gawk. Sorry for bothering you Have a nice day Norbert -- Dipl. Phys. Norbert Zacharias Wind Measurements & Power Curve Measurements DEWI GmbH Ebertstrasse 96 26382 Wilhelmshaven Germany Tel.: +49 4421 4808 876 Fax:+49 4421 4808 843 Email: n.zachar...@dewi.de Home: http://www.dewi.de DEWI GmbH - Deutsches Windenergie-Institut, Wilhelmshaven Commercial Register No.: Amtsgericht Oldenburg, HRB 130241 Managing Director: Jens Peter Molly Chairman of the supervisory board: Ministerialrat Dr. Niels Kämpny P Please consider the environment before printing this email. -- 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
Re: i686-XXX-mingw32 compilers and __MINGW32_MINOR_VERSION macro: 3.18 or 3.11?
> Just bump it up and see if there are any issues, the mingw-w64 toolchain > uses its own header set and the numbers don't always reflect mingw.org > releases, since the macros in there are mainly for compatibility. > > You want to check instead for __MINGW64_VERSION_MAJOR on mingw-w64. neither __MINGW64__, nor __MINGW64_VERSION_MAJOR are defined because I am targetting win32, not win64, even if I use w64 compiler. So this does not help. Any other clue? Frédéric -- 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
Re: i686-XXX-mingw32 compilers and __MINGW32_MINOR_VERSION macro: 3.18 or 3.11?
On 8/18/2011 21:56, Frédéric Bron wrote: >> Just bump it up and see if there are any issues, the mingw-w64 toolchain >> uses its own header set and the numbers don't always reflect mingw.org >> releases, since the macros in there are mainly for compatibility. >> >> You want to check instead for __MINGW64_VERSION_MAJOR on mingw-w64. > > neither __MINGW64__, nor __MINGW64_VERSION_MAJOR are defined because > I am targetting win32, not win64, even if I use w64 compiler. > So this does not help. > Any other clue? > > Frédéric > Its there when you include files like stdio.h, which eventually will include _mingw_mac.h. Please do not the header directly if you value platform portability. signature.asc Description: OpenPGP digital signature
Re: v*printf functions not available with g++ -std=c++0x
On Aug 17 11:04, Ryan Johnson wrote: > Hi all, > > I'm using the experimental gcc-4.5 package and hit a strange error: > c++0x mode suppresses the definition of the v*printf() family of > functions in stdio.h in c++0x mode. The offending code seems to be: > > #if !defined(__STRICT_ANSI__) || (__STDC_VERSION__ >= 199901L) > #ifndef _REENT_ONLY > ... > int _EXFUN(vsnprintf, (char *, size_t, const char *, __VALIST) >_ATTRIBUTE ((__format__ (__printf__, 3, 0; > ... > #endif > #endif > > Running `g++ -std=c++0x -dM -E' indicates that __STRICT_ANSI__ is > defined while _REENT_ONLY and __STDC_VERSION__ are not. > > Oddly, functions like _vsnprintf_r are still available for some > strange reason (aren't they extensions?). I hope this is a bug > rather than a requirement of the new standard; meanwhile, using > std=gnu++0x works around the problem. If I try that with Yaakov's 4.5.3 cross compilers, then __STRICT_ANSI__ is not defined with -std=c__0x, unless I also specify `-ansi' on the command line. However, there's a weird warning: $ i686-pc-cygwin-g++ -std=c++0x -dM -E - < /dev/null | grep ANSI cc1: warning: command line option "-std=c++0x" is valid for C++/ObjC++ but not for C Well, sure, that's why I called g++, not gcc... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
i686-w64-mingw32-gcc & ntifs.h
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/cygwin/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h.old
2011-08-10 09:06:18.00100 -0400
+++ c:/gnu/cygwin/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h
2011-08-18 11:42:13.272375000 -0400
@@ -35,11 +35,11 @@
#define NT_INCLUDED
#define _CTYPE_DISABLE_MACROS
-#include
+#include
#include
#include
#include
-#include
+#include
#include
#include
Diff finished. Thu Aug 18 11:42:16 2011
--- c:/gnu/cygwin/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntifs.h.old
2011-08-10 09:06:19.00100 -0400
+++ c:/gnu/cygwin/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntifs.h
2011-08-18 11:33:42.429125000 -0400
@@ -31,7 +31,7 @@ extern "C" {
#endif
/* Dependencies */
-#include
+#include
#include
#include
#include
Diff finished. Thu Aug 18 11:36:04 2011
I get these errors:
In file included from
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h:38:0,
from
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntifs.h:34,
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:215:1: error:
conflicting types for `_interlockedbittestandset'
/usr/i686-w64-mingw32/sys-root/mingw/include/intrin.h:968:5: note: previous
declaration of `_interlockedbittestandset' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:234:1: error:
conflicting types for `_interlockedbittestandreset'
/usr/i686-w64-mingw32/sys-root/mingw/include/intrin.h:969:5: note: previous
declaration of `_interlockedbittestandreset' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:597:14: error: nested
redefinition of `enum _LOGICAL_PROCESSOR_RELATIONSHIP'
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:597:14: error:
redeclaration of `enum _LOGICAL_PROCESSOR_RELATIONSHIP'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3584:18: note: originally
defined here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:598:3: error:
redeclaration of enumerator `RelationProcessorCore'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3585:7: note: previous
definition of `RelationProcessorCore' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:599:3: error:
redeclaration of enumerator `RelationNumaNode'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3585:29: note: previous
definition of `RelationNumaNode' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:600:3: error:
redeclaration of enumerator `RelationCache'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3585:46: note: previous
definition of `RelationCache' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:601:3: error:
redeclaration of enumerator `RelationProcessorPackage'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3586:7: note: previous
definition of `RelationProcessorPackage' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:602:3: error:
redeclaration of enumerator `RelationGroup'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3586:32: note: previous
definition of `RelationGroup' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:603:17: error:
redeclaration of enumerator `RelationAll'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3586:58: note: previous
definition of `RelationAll' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:606:14: error: nested
redefinition of `enum _PROCESSOR_CACHE_TYPE'
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:606:14: error:
redeclaration of `enum _PROCESSOR_CACHE_TYPE'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3591:18: note: originally
defined here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:607:3: error:
redeclaration of enumerator `CacheUnified'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3592:7: note: previous
definition of `CacheUnified' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:608:3: error:
redeclaration of enumerator `CacheInstruction'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3592:20: note: previous
definition of `CacheInstruction' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:609:3: error:
redeclaration of enumerator `CacheData'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3592:37: note: previous
definition of `CacheData' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:610:3: error:
redeclaration of enumerator `CacheTrace'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3592:47: note: previous
definition of `CacheTrace' was here
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/wdm.h:613:16: error:
redefinition of `struct _CACHE_DESCRIPTOR'
/usr/i686-w64-mingw32/sys-root/mingw/include/winnt.h:3597:20: note: originally
defined here
/usr/i686-w64-mingw32/sys-root/min
Re: i686-XXX-mingw32 compilers and __MINGW32_MINOR_VERSION macro: 3.18 or 3.11?
On Thu, 2011-08-18 at 07:44 +0200, Frédéric Bron wrote:
> Using cygwin 1.7.9(0.237/5/3) 2011-03-29 10:10.
>
> The following program:
>
> #include
> int main() {
>
> std::cout<<__MINGW32_MAJOR_VERSION<<'.'<<__MINGW32_MINOR_VERSION<<'\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:
> $ grep -r "#define *__MINGW32_MINOR_VERSION" /usr/i686-pc-mingw32/
> /usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h:#define
> __MINGW32_MINOR_VERSION 18
> and
> $ grep -r "#define *__MINGW32_MINOR_VERSION" /usr/i686-w64-mingw32/
> /usr/i686-w64-mingw32/sys-root/mingw/include/_mingw_mac.h:#define
> __MINGW32_MINOR_VERSION 11
>
> This seems to be one of the reasons that prevents me to use boost on cygwin
> 1.7.
If you are using a mingw* compiler, then you're not "using" Boost on
Cygwin. If you really want to build with Boost on Cygwin, install
libboost-devel and its dependencies.
Yaakov
--
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
Re: i686-XXX-mingw32 compilers and __MINGW32_MINOR_VERSION macro: 3.18 or 3.11?
On Thu, 2011-08-18 at 07:44 +0200, Frédéric Bron wrote:
> Using cygwin 1.7.9(0.237/5/3) 2011-03-29 10:10.
>
> The following program:
>
> #include
> int main() {
>
> std::cout<<__MINGW32_MAJOR_VERSION<<'.'<<__MINGW32_MINOR_VERSION<<'\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:
> $ grep -r "#define *__MINGW32_MINOR_VERSION" /usr/i686-pc-mingw32/
> /usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h:#define
> __MINGW32_MINOR_VERSION 18
> and
> $ grep -r "#define *__MINGW32_MINOR_VERSION" /usr/i686-w64-mingw32/
> /usr/i686-w64-mingw32/sys-root/mingw/include/_mingw_mac.h:#define
> __MINGW32_MINOR_VERSION 11
>
> This seems to be one of the reasons that prevents me to use boost on cygwin
> 1.7.
If you are using a mingw* compiler, then you're not "using" Boost on
Cygwin. If you really want to build with Boost on Cygwin, install
libboost-devel and its dependencies.
Yaakov
--
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
Re: [ANNOUNCEMENT] Updated: binutils-2.21.53-1
On Fri, 2011-08-05 at 13:35 +0200, Denis Excoffier wrote: > Hello, > > On Sun, Jul 31, 2011 at 02:22:51PM -0400, Christopher Faylor wrote: > >> I've made a new version of binutils available for installation. This is > >> a refresh against the current CVS. > > Compared to the previous one (binutils-2.20.51-2), the /usr/include/bfd.h > (and fellows) is missing. I need in order to > compile cygwin-snapshot-20110803-1/winsup/utils/dumper.cc > > Where can i find it, if not in binutils? cgf, Could you please respin binutils with the missing headers and libraries? Yaakov -- 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
Re: [ANNOUNCEMENT] Updated: binutils-2.21.53-1
On 8/18/2011 1:37 PM, Yaakov (Cygwin/X) wrote: > Could you please respin binutils with the missing headers and libraries? Since libbfd & friends are no longer default-installed by the src/ build machinery when building binutils or gcc, I wonder if it would be a good idea to "spin off" libbfd as a separate "package" -- with no ties to (and not used by) binutils/gcc themselves. (Obv, binutils/gcc would continue as they do at present, building an internal version with just what they need). That way, bfd-for-public-use could be configured with all bells and whistles (e.g. elf support, etc). -- Chuck -- 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
Re: i686-XXX-mingw32 compilers and __MINGW32_MINOR_VERSION macro: 3.18 or 3.11?
> If you are using a mingw* compiler, then you're not "using" Boost on > Cygwin. I am. Up to now, I have a dual cygwin installation 1.5/1.7 because I was unable to use boost nor wxwidgets with 1.7. I recently 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 imagine that they correspond to: - w64 ->http://mingw-w64.sourceforge.net/ - pc -> http://mingw.org/ I first tried to use the -w64- version with which I have troubles building boost. However, good news: I just finished building boost with the -pc- version! I still have to build wxwidgets (currently running). It would be nice to understand why the -w64- version does not work but it seems to be beyond my competencies. > If you really want to build with Boost on Cygwin, install > libboost-devel and its dependencies. This is an old version (1.43). I want to use the latest one (1.47) Frédéric -- 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
Re: [ANNOUNCEMENT] Updated: binutils-2.21.53-1
On Thu, Aug 18, 2011 at 12:37:56PM -0500, Yaakov (Cygwin/X) wrote: >On Fri, 2011-08-05 at 13:35 +0200, Denis Excoffier wrote: >> Hello, >> >> On Sun, Jul 31, 2011 at 02:22:51PM -0400, Christopher Faylor wrote: >> >> I've made a new version of binutils available for installation. This is >> >> a refresh against the current CVS. >> >> Compared to the previous one (binutils-2.20.51-2), the /usr/include/bfd.h >> (and fellows) is missing. I need in order to >> compile cygwin-snapshot-20110803-1/winsup/utils/dumper.cc >> >> Where can i find it, if not in binutils? > >Could you please respin binutils with the missing headers and libraries? I'm aware of the problem. No need for a reminder. -- 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
Re: i686-w64-mingw32-gcc & ntifs.h
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/cygwin/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h.old
> 2011-08-10 09:06:18.00100 -0400
> +++ c:/gnu/cygwin/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h
> 2011-08-18 11:42:13.272375000 -0400
> @@ -35,11 +35,11 @@
> #define NT_INCLUDED
> #define _CTYPE_DISABLE_MACROS
>
> -#include
> +#include
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
>
>
> Diff finished. Thu Aug 18 11:42:16 2011
> --- c:/gnu/cygwin/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntifs.h.old
> 2011-08-10 09:06:19.00100 -0400
> +++ c:/gnu/cygwin/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntifs.h
> 2011-08-18 11:33:42.429125000 -0400
> @@ -31,7 +31,7 @@ extern "C" {
> #endif
>
> /* Dependencies */
> -#include
> +#include
> #include
> #include
> #include
>
> Diff finished. Thu Aug 18 11:36:04 2011
Adding to mingw-w64-public list.
You are supposed to use -I to add the ddk path to gcc.
signature.asc
Description: OpenPGP digital signature
Re: i686-XXX-mingw32 compilers and __MINGW32_MINOR_VERSION macro: 3.18 or 3.11?
On 8/19/2011 03:10, Frédéric Bron wrote: >> If you are using a mingw* compiler, then you're not "using" Boost on >> Cygwin. > > I am. Up to now, I have a dual cygwin installation 1.5/1.7 because I > was unable to use boost nor wxwidgets with 1.7. > I recently 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 imagine that they correspond to: > - w64 ->http://mingw-w64.sourceforge.net/ > - pc -> http://mingw.org/ > > I first tried to use the -w64- version with which I have troubles > building boost. > However, good news: I just finished building boost with the -pc- > version! I still have to build wxwidgets (currently running). > > It would be nice to understand why the -w64- version does not work but > it seems to be beyond my competencies. > Adding mingw-w64-public list. Care to share what went wrong? signature.asc Description: OpenPGP digital signature
Re: i686-w64-mingw32-gcc & ntifs.h
> * 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! -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://dhimmi.com http://palestinefacts.org http://mideasttruth.com http://thereligionofpeace.com http://www.PetitionOnline.com/tap12009/ Bug free software merely has random features. -- 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
Contributing license information?
Soon, I will have prepared a list of the location of every license file in every Cygwin package. My motivation is to make it easy for people to find the license information, if they need it. (Preparing this information has required a lot of work on my part, so I would be happy if something could be done to make it easy to keep the information up to date as packages are added and modified.) What is the best way to contribute the license-location information so it can be integrated into Cygwin? I have *imagined* that it would be by adding a field to every package in setup.ini, something like: license: "relative-path-to-first-license relative-path-to-another-license ... relative-path-to-last-license" That seems neat to me, since the information is per-package, and AFAIK per-package information is stored only in sestup.ini. If the right way is to modify setup.ini to hold the license info, would the new setup.ini require a new setup.exe, or does setup.exe ignore information in setup.ini that it doesn't know about? But I gather that setup.ini is created from other data sources via a program called "upset". Anyway, what is the right way to contribute this information? Regards, luke -- 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
Issue with inserting '@' at the command prompt.
Samuel Thibault, le Thu 14 Jul 2011 14:42:14 +0200, a écrit :
> Lars Bjørndal, le Thu 14 Jul 2011 12:56:21 +0200, a écrit :
> > BRLTTY has a cut & paste facility. It sometimes doesn't paste all
> > characters inside cygwin. Pasting an att sign into a shell prompt, the
> > terminal beeps, and no character is written. Doing the same thing
> > after exiting bash, but still with BRLTTY running and in a cmd
> > session, the att sign is printed.
>
> I don't have the time to investigate now, but I can say that depending
> on whether it could open the terminal through CONIN$, brltty uses
> WriteConsoleInputW (or WriteConsoleInputA if not available) or SendInput
> for this.
In the case at stake it is WriteConsoleInputW. Let me explain a simpler
case (pasting is the same)
- the user presses '@' on his braille keyboard (ascii 0x40).
- brltty wants to synthesize it.
- brltty calls VkKeyScanW('@') to get the corresponding virtual key,
0x0630 on an azerty keyboard, which means altgr (controlkeystate 1) +
virtualkey 0x30
- brltty calls MapVirtualKey(vk, 0) to get the corresponding scancode,
0x11 on a standard PC keyboard.
- brltty thus calls WriteConsoleInputW, passing it a KEY_EVENT_RECORD
structure:
.bKeyDown = 1,
.wRepeatCount = 1,
.wVirtualKeyCode = 0x630,
.wVirtualScanCode = 0x11,
.uChar.UnicodeChar = 0x40,
.dwControlKeyState = 1,
and then the same with bKeyDown = 0.
This correctly inserts an '@' in a plain windows console with the
windows cmd, but with a windows console with the cygwin or mingw shell,
this beeps and does not insert anything.
Any idea?
Samuel
--
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
Re: Issue with inserting '@' at the command prompt.
Samuel Thibault, le Fri 19 Aug 2011 04:37:40 +0200, a écrit : > - the user presses '@' on his braille keyboard (ascii 0x40). I forgot to mention: everything goes fine at the cmd, cygwin and mingw shell when the pressed key is e.g. 'a', i.e. which does not need altgr. Samuel -- 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
