Re: coreutils-6.11-1 in release-2 area
Hi Eric, On May 13 13:02, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 5/12/2008 8:11 PM: | I've finally finished a build of coreutils 6.11, and uploaded it to the | release-2 area. | So there will probably be issues and/or regressions; please | report them on this list, and I will try to fix them before cygwin 1.7.0 | goes live. And the very first issue was that cp and mv dumped core, because I forgot an '#include config.h' in my source additions. -2 is uploaded now. There's a bug in coreutils 6.11 id(1) which results in showing a truncated group list. Running my domain account against id from coreutils 6.10 shows: $ id uid=11001(corinna) gid=10513(Domain Users) groups=544(Administrators),545(Users),554(Pre-Windows 2000 Compatible Access),572(Denied RODC Password Replication Group),10512(Domain Admins),10513(Domain Users) Running it against id from 6.11 shows: $ id uid=11001(corinna) gid=10513(DomUsers) groups=10513(DomUsers) The reason is apparently that the mgetgroups function is always called with a username != NULL, even if no username has been given on the command line. As result, the grouplist is evaluated by using the getugroups function, which searches the group memberships manually using getgrent. For the current user it should rather use getgroups directly, as would be the case with username=NULL. HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: coreutils-6.11-1 in release-2 area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 5/22/2008 4:36 AM: | | There's a bug in coreutils 6.11 id(1) which results in showing a | truncated group list. Running my domain account against id from | coreutils 6.10 shows: | | The reason is apparently that the mgetgroups function is always called | with a username != NULL, even if no username has been given on the | command line. Thanks for the report. This has seen upstream changes as well: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=history;f=src/id.c;h=92c39fe;hb=3ceabe1 So I'll probably take this issue upstream, to make sure it doesn't introduce conflicts with SELinux. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg1XNoACgkQ84KuGfSFAYDhpwCeIQOfCz/3/z+QevND59fAVUHU AGUAoJIYFceLpCJ+FCukYs9r0gmfbbwo =8oUX -END PGP SIGNATURE-
Re: coreutils-6.11-1 in release-2 area
On May 22 05:45, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 5/22/2008 4:36 AM: | | There's a bug in coreutils 6.11 id(1) which results in showing a | truncated group list. Running my domain account against id from | coreutils 6.10 shows: | | The reason is apparently that the mgetgroups function is always called | with a username != NULL, even if no username has been given on the | command line. Thanks for the report. This has seen upstream changes as well: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=history;f=src/id.c;h=92c39fe;hb=3ceabe1 So I'll probably take this issue upstream, to make sure it doesn't introduce conflicts with SELinux. Cool, thanks. While we're talking about coreutils, it would be a good idea to use the latest Cygwin from CVS when testing coreutils further(*). cp baild out on me because it used a NULL pathname in calls to futimesat, which I'd consider a bug in coreutils, but the Linux man page gives away that this is a GLIBC extension. I fixed that in CVS so futimesat can now do its job (hopefully) correctly withe NULL pathname as well. However, here's a question: Should coreutils really use futimesat at all when futimes and utimensat are available? Isn't that sort of a buglet in coreutils? Corinna (*) I guess I have to upload yet another 1.7 version before I'm really off on vacation... -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: coreutils-6.11-1 in release-2 area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 5/22/2008 5:56 AM: | | While we're talking about coreutils, it would be a good idea to use the | latest Cygwin from CVS when testing coreutils further(*). cp baild out | on me because it used a NULL pathname in calls to futimesat, which I'd | consider a bug in coreutils, but the Linux man page gives away that this | is a GLIBC extension. I fixed that in CVS so futimesat can now do its | job (hopefully) correctly withe NULL pathname as well. | | However, here's a question: Should coreutils really use futimesat at | all when futimes and utimensat are available? Isn't that sort of a | buglet in coreutils? Hmm. There's some history here. futimesat was the original proposal, then Posix 200x changed their minds and decided to standardize utimensat instead. Gnulib implemented a version prior to glibc, then glibc picked up the prototype that Posix was proposing which conflicted with gnulib (if I recall correctly, it was the addition of a flag parameter). Meanwhile, it IS a bit annoying that Posix 200x decided not to standardize utimensat(fd,NULL,times,flag) as changing the times on fd rather than treating fd as the directory starting point; once you have an open fd, having to refer to the file by name again is potentially racy. I wonder if, in all of the flurry in the Austin Group about changing futimesat to utimensat, that this use case was overlooked. But cygwin should certainly consider providing this as a useful extension, and coreutils should be taught to snoop whether systems with futimesat/utimensat support also honor this extension. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg1YsAACgkQ84KuGfSFAYCZZQCg1rYEKnRtLHbFXnoepTOuUBkj AaYAn1Izxbo7w7NY4NsnorDJlAAk0RIZ =T/0D -END PGP SIGNATURE-
Re: coreutils-6.11-1 in release-2 area
On May 22 06:10, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 5/22/2008 5:56 AM: | | While we're talking about coreutils, it would be a good idea to use the | latest Cygwin from CVS when testing coreutils further(*). cp baild out | on me because it used a NULL pathname in calls to futimesat, which I'd | consider a bug in coreutils, but the Linux man page gives away that this | is a GLIBC extension. I fixed that in CVS so futimesat can now do its | job (hopefully) correctly withe NULL pathname as well. | | However, here's a question: Should coreutils really use futimesat at | all when futimes and utimensat are available? Isn't that sort of a | buglet in coreutils? Hmm. There's some history here. futimesat was the original proposal, then Posix 200x changed their minds and decided to standardize utimensat instead. Gnulib implemented a version prior to glibc, then glibc picked up the prototype that Posix was proposing which conflicted with gnulib (if I recall correctly, it was the addition of a flag parameter). Meanwhile, it IS a bit annoying that Posix 200x decided not to standardize utimensat(fd,NULL,times,flag) as changing the times on fd rather than treating fd as the directory starting point; once you have an open fd, having to refer to the file by name again is potentially racy. No need to refer the dir by name: futimens (dirfd. timespec); Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: coreutils-6.11-1 in release-2 area
On May 22 14:18, Corinna Vinschen wrote: Hmm. There's some history here. futimesat was the original proposal, then Posix 200x changed their minds and decided to standardize utimensat instead. Gnulib implemented a version prior to glibc, then glibc picked up the prototype that Posix was proposing which conflicted with gnulib (if I recall correctly, it was the addition of a flag parameter). Meanwhile, it IS a bit annoying that Posix 200x decided not to standardize utimensat(fd,NULL,times,flag) as changing the times on fd rather than treating fd as the directory starting point; once you have an open fd, having to refer to the file by name again is potentially racy. No need to refer the dir by name: futimens (dirfd. timespec); Btw., even if you don't consider the Posix 200x functions futimens/utimensat, you don't need futimsat(dirfd, NULL, timeval): futimes (dirfd, timeval); So, actually I think that using futimesat this way is a gratuitous utilization of a glibc extension. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: coreutils-6.11-1 in release-2 area
On May 22 06:38, Eric Blake wrote: Without futimens/utimensat, there is no way to set nanosecond resolution (where that granularity is supported). As far as I can tell, the only reason that coreutils still uses the non-standardized futimesat with a NULL pathname is that it provided more resolution than any standardized function, while supporting glibc that had not yet implemented the standardized futimens/utimensat. I guess all that is needed now is a patch to coreutils and/or gnulib to prefer the standardized names (and fall back to futimesat under the hood when needed), rather than preferring the non-standardized name. ACK. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: coreutils-6.11-1 in release-2 area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 5/22/2008 6:42 AM: | | No need to refer the dir by name: | | | | futimens (dirfd. timespec); | | | | Btw., even if you don't consider the Posix 200x functions | | futimens/utimensat, you don't need futimsat(dirfd, NULL, timeval): | | | | futimes (dirfd, timeval); | | | | So, actually I think that using futimesat this way is a gratuitous | | utilization of a glibc extension. | | | Thanks for the write-up. | That sounds like the right way to go. | Do you feel like doing it? Yes, I'll be tackling this. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg1bEkACgkQ84KuGfSFAYAwGwCbBMNx0UVYNOEW+jNY/ydv9pJr ZtsAoMHqCvSbCNy1GL86IT+spq5lr3dO =+q+z -END PGP SIGNATURE-
Re: coreutils-6.11-1 in release-2 area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 5/22/2008 6:30 AM: | Meanwhile, it IS a bit annoying that Posix 200x decided not to standardize | utimensat(fd,NULL,times,flag) as changing the times on fd rather than | treating fd as the directory starting point; once you have an open fd, | having to refer to the file by name again is potentially racy. | No need to refer the dir by name: | | futimens (dirfd. timespec); | | Btw., even if you don't consider the Posix 200x functions | futimens/utimensat, you don't need futimsat(dirfd, NULL, timeval): | | futimes (dirfd, timeval); | | So, actually I think that using futimesat this way is a gratuitous | utilization of a glibc extension. Without futimens/utimensat, there is no way to set nanosecond resolution (where that granularity is supported). As far as I can tell, the only reason that coreutils still uses the non-standardized futimesat with a NULL pathname is that it provided more resolution than any standardized function, while supporting glibc that had not yet implemented the standardized futimens/utimensat. I guess all that is needed now is a patch to coreutils and/or gnulib to prefer the standardized names (and fall back to futimesat under the hood when needed), rather than preferring the non-standardized name. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg1aUgACgkQ84KuGfSFAYCq/ACg0AFpP7E2D5kMqD/wPGB+WJyo OnIAoNFzNZXKikteHZ6FsM84ltgQKBAp =CiKn -END PGP SIGNATURE-
Re: CMake 2.6.0-1 ready
Dr. Volker Zell wrote: Okay no problem with the MANIFEST file then. But the directory structure looks strange. usr/share/cmake-2.6.0-CYGWIN-unknown usr/share/doc/cmake-2.6.0-CYGWIN-unknown/ usr/share/doc/cmake-2.6.0/MANIFEST Shouldn't that be usr/share/cmake-2.6.0 usr/share/doc/cmake-2.6.0/ If the subdirectory cmake-2.6.0-CYGWIN-unknown is ok then at least move the manifest file from usr/share/doc/cmake-2.6.0/MANIFEST to usr/share/doc/cmake-2.6.0-CYGWIN-unknown Yup, those directories are bad. I will fix that in the next release thanks, I had not noticed it. 2.4.8 had this structure: 12227 ./bin 4 ./share/doc/Cygwin 656 ./share/doc/cmake-2.4.8 660 ./share/doc 284 ./share/man/man1 284 ./share/man 89 ./share/cmake-2.4.8/Templates 214 ./share/cmake-2.4.8/Modules/Platform 1325./share/cmake-2.4.8/Modules 12 ./share/cmake-2.4.8/include 1426./share/cmake-2.4.8 2370./share The MANIFEST file was here: ./share/doc/cmake-2.4.8/MANIFEST 2.6.0 should have the same structure but does not. I am going to release 2.6.1 very soon, and I will make sure it goes back to the correct structure. Just for my peace of mind, can someone tell me if the MANIFEST used to be required? I know I went out of my way to create that file, and now I can't find any reference to it in the cygwin docs. Thanks. -Bill
Re: coreutils-6.11-1 in release-2 area
On Thu, May 22, 2008 at 09:28:19PM +0200, Corinna Vinschen wrote: On May 22 13:56, Corinna Vinschen wrote: While we're talking about coreutils, it would be a good idea to use the latest Cygwin from CVS when testing coreutils further(*). cp baild out on me because it used a NULL pathname in calls to futimesat, which I'd consider a bug in coreutils, but the Linux man page gives away that this is a GLIBC extension. I fixed that in CVS so futimesat can now do its job (hopefully) correctly withe NULL pathname as well. [...] (*) I guess I have to upload yet another 1.7 version before I'm really off on vacation... FYI, I've uploaded a 1.7.0-15 to release-2 which fixes this as well as a related internal error in Cygwin which was caused by getting an EFAULT due to the NULL pathname. It also contains your strchr patch and the setfacl changes discussed on the main list. It will also contain my removal of the strchr from cygwin's string.h which should have the effect of causing cygwin to use gcc's built-in version of strchr. cgf
Re: coreutils-6.11-1 in release-2 area
On May 22 13:56, Corinna Vinschen wrote: While we're talking about coreutils, it would be a good idea to use the latest Cygwin from CVS when testing coreutils further(*). cp baild out on me because it used a NULL pathname in calls to futimesat, which I'd consider a bug in coreutils, but the Linux man page gives away that this is a GLIBC extension. I fixed that in CVS so futimesat can now do its job (hopefully) correctly withe NULL pathname as well. [...] (*) I guess I have to upload yet another 1.7 version before I'm really off on vacation... FYI, I've uploaded a 1.7.0-15 to release-2 which fixes this as well as a related internal error in Cygwin which was caused by getting an EFAULT due to the NULL pathname. It also contains your strchr patch and the setfacl changes discussed on the main list. Famous last words: This is really the last test release before my vacation starts. Really, I mean it! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: coreutils-6.11-1 in release-2 area
On May 22 15:56, Christopher Faylor wrote: On Thu, May 22, 2008 at 09:28:19PM +0200, Corinna Vinschen wrote: On May 22 13:56, Corinna Vinschen wrote: While we're talking about coreutils, it would be a good idea to use the latest Cygwin from CVS when testing coreutils further(*). cp baild out on me because it used a NULL pathname in calls to futimesat, which I'd consider a bug in coreutils, but the Linux man page gives away that this is a GLIBC extension. I fixed that in CVS so futimesat can now do its job (hopefully) correctly withe NULL pathname as well. [...] (*) I guess I have to upload yet another 1.7 version before I'm really off on vacation... FYI, I've uploaded a 1.7.0-15 to release-2 which fixes this as well as a related internal error in Cygwin which was caused by getting an EFAULT due to the NULL pathname. It also contains your strchr patch and the setfacl changes discussed on the main list. It will also contain my removal of the strchr from cygwin's string.h which should have the effect of causing cygwin to use gcc's built-in version of strchr. Oh, surprise! I thought Cygwin would use Eric's version now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: coreutils-6.11-1 in release-2 area
On Thu, May 22, 2008 at 10:28:32PM +0200, Corinna Vinschen wrote: On May 22 15:56, Christopher Faylor wrote: On Thu, May 22, 2008 at 09:28:19PM +0200, Corinna Vinschen wrote: On May 22 13:56, Corinna Vinschen wrote: While we're talking about coreutils, it would be a good idea to use the latest Cygwin from CVS when testing coreutils further(*). cp baild out on me because it used a NULL pathname in calls to futimesat, which I'd consider a bug in coreutils, but the Linux man page gives away that this is a GLIBC extension. I fixed that in CVS so futimesat can now do its job (hopefully) correctly withe NULL pathname as well. [...] (*) I guess I have to upload yet another 1.7 version before I'm really off on vacation... FYI, I've uploaded a 1.7.0-15 to release-2 which fixes this as well as a related internal error in Cygwin which was caused by getting an EFAULT due to the NULL pathname. It also contains your strchr patch and the setfacl changes discussed on the main list. It will also contain my removal of the strchr from cygwin's string.h which should have the effect of causing cygwin to use gcc's built-in version of strchr. Oh, surprise! I thought Cygwin would use Eric's version now. It will export it but, in my testing, it won't use it. But that's no different than any other program which uses strchr() and specifies the right -O optimization level. strchr() and strlen() are among a group of functions that gcc inlines automatically when you compile a file with optimization. cgf
Re: coreutils-6.11-1 in release-2 area
On May 22 16:31, Christopher Faylor wrote: On Thu, May 22, 2008 at 10:28:32PM +0200, Corinna Vinschen wrote: On May 22 15:56, Christopher Faylor wrote: It will also contain my removal of the strchr from cygwin's string.h which should have the effect of causing cygwin to use gcc's built-in version of strchr. Oh, surprise! I thought Cygwin would use Eric's version now. It will export it but, in my testing, it won't use it. But that's no different than any other program which uses strchr() and specifies the right -O optimization level. strchr() and strlen() are among a group of functions that gcc inlines automatically when you compile a file with optimization. But then... is the #define strlen __builtin_strlen [...] stuff at the top of winsup.h just old cruft which isn't needed anymore? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: coreutils-6.11-1 in release-2 area
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 5/22/2008 2:41 PM:
| Oh, surprise! I thought Cygwin would use Eric's version now.
| It will export it but, in my testing, it won't use it.
Actually, it will. Build cygwin1.dbg, then 'gdb cygwin1.dll',
'disassemble strchr', and you will see my implementation - gcc only
implements the builtin as a wrapper to notice where it can avoid using the
library, and NOT as a full-blown replacement that would work even in the
absence of libc (after all, how do you write a generic builtin in
intermediate language that will compile to optimal code across all the
various architectures that gcc targets?).
| But that's no
| different than any other program which uses strchr() and specifies the
| right -O optimization level.
Actually, what gcc does with __builtin_strchr is that IF it can optimize
at compile time, it does (so strchr(abc,b) is turned into the
compile-time constant bc, without a function call). But WHEN gcc can't
optimize, it calls the library's strchr() instead.
|
| strchr() and strlen() are among a group of functions that gcc inlines
| automatically when you compile a file with optimization.
|
| But then... is the
|
| #define strlen __builtin_strlen
| [...]
|
| stuff at the top of winsup.h just old cruft which isn't needed anymore?
|
Adding #defines that defer to the builtin is still a useful idiom - it
allows the builtin to do optimizations even when compiled with -std=c89,
or when compiling with -fno-builtin that would inhibit the normal
recognition of plain names as special functions. But when you don't
specifically request such a strict compilation environment, the #define
doesn't really buy much, since gcc automatically recognizes the original
name as one of its builtins.
To see for yourself, compile a program consisting of:
#include stdio.h
int main(int argc, char**argv)
{
~ printf (%d\n, strlen(abc));
~ printf (%d\n, __builtin_strlen(abc));
~ printf (%d\n, strlen(argv[0]));
~ printf (%d\n, __builtin_strlen(argv[0]));
~ return 0;
}
With 'gcc -O2', then 'gdb program', 'disassemble main', you can see the
first two instances are hard-coded to 3, the last two result in 'call
strlen'. With 'gcc -O2 -fno-builtin', only the second instance is
hard-coded to three. But hopefully this goes to show that where the
compiler can't optimize at compile time, the library function is used.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkg2IcQACgkQ84KuGfSFAYCxRgCdFeOfGl9b9oO+SdTdRpBzNq3F
5GEAmwco9oEQwZnbP8sChnYRGdluu3an
=YssM
-END PGP SIGNATURE-
Re: coreutils-6.11-1 in release-2 area
On Thu, May 22, 2008 at 07:45:40PM -0600, Eric Blake wrote: According to Corinna Vinschen on 5/22/2008 2:41 PM: | Oh, surprise! I thought Cygwin would use Eric's version now. | It will export it but, in my testing, it won't use it. Actually, it will. Build cygwin1.dbg, then 'gdb cygwin1.dll', 'disassemble strchr', and you will see my implementation Well, cygwin1.dll exports it. So of course you will *see* it in cygwin1.dll. However, I misinterpreted the disassembly of one of the object files that I looked at where I thought that strchr had been inlined. I had to actually look at a linked version of cygwin0.dll to see the call. I guess we'll see if the effects of a subroutine call and probable non-cache locality are going to outweigh any performance improvement. I'm still not thrilled about tweaking these functions given the It's 2008 and someone has already done this so why reinvent it again? concept. cgf
src/winsup/cygwin ChangeLog path.cc syscalls.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-05-22 11:18:46 Modified files: winsup/cygwin : ChangeLog path.cc syscalls.cc Log message: * path.cc (cygwin_conv_path): Define tp before setting up faul handler. * syscalls.cc: Ditto, throughout. (gen_full_path_at): Add bool parameter to allow NULL pathname. (futimesat): Allow NULL pathname as GLIBC. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4159r2=1.4160 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/path.cc.diff?cvsroot=srcr1=1.503r2=1.504 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.496r2=1.497
src/winsup/utils ChangeLog setfacl.c
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-05-22 18:56:26 Modified files: winsup/utils : ChangeLog setfacl.c Log message: * setfacl.c (setfacl): Change from void to int. Return 2 in case of error. (main): Return with error code from setfacl. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/ChangeLog.diff?cvsroot=srcr1=1.402r2=1.403 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/utils/setfacl.c.diff?cvsroot=srcr1=1.14r2=1.15
src/winsup/cygwin ChangeLog cygtls.h tlsoffsets.h
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-05-22 20:32:15 Modified files: winsup/cygwin : ChangeLog cygtls.h tlsoffsets.h Log message: * cygtls.h (struct san): Add two int values to store the current tls_pathbuf counters. (return_from_fault): Restore tls_pathbuf counters. (setup_fault): Save tls_pathbuf counters. * tlsoffset.h: Regenerate. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4161r2=1.4162 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygtls.h.diff?cvsroot=srcr1=1.56r2=1.57 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/tlsoffsets.h.diff?cvsroot=srcr1=1.35r2=1.36
src/winsup/cygwin ChangeLog grp.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-05-22 21:03:54 Modified files: winsup/cygwin : ChangeLog grp.cc Log message: * grp.cc (internal_getgroups): Don't add deny-only groups to the group list. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4162r2=1.4163 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/grp.cc.diff?cvsroot=srcr1=1.106r2=1.107
src/winsup/cygwin ChangeLog grp.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2008-05-22 21:14:30 Modified files: winsup/cygwin : ChangeLog grp.cc Log message: * grp.cc (internal_getgroups): Fix thinko. Only add enabled groups to the group list. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4163r2=1.4164 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/grp.cc.diff?cvsroot=srcr1=1.107r2=1.108
Re: wstring support in GCC 4.1.2 in Cygwin 1.5.25-11
Ya I am trying MinGW now.
But since it is like building on the windows platform, we need to get round
with
concepts which differ on the posix and the windows system. Currently I am
dealing with the Signals, one such problem. In in my linux based code we
have used
the sigaction() concept which is not supported in MinGW.
Now I am bit worried to estimate the time for the complete activity as I
will
have to make modifications in the code to make porting successful.
Longyu Mei wrote:
How about minGW? Did you try that? I have similiar
problem and I will try to see if there is any
difference.
--- jadooo [EMAIL PROTECTED] wrote:
Thanks a lot for the valuable information.
I am trying to port my application developed in
linux to windows, now as
it is quiet clear that I could not use cygwin, due
to lack of Unicode
support,
is there any other alternative to try out my porting
activity.
Thanking you all once again for the great help.
Vipin
jadooo wrote:
Hi All,
I was trying to compile my code on
Cygwin[1.5.25-11] with GCC[4.1.2],
but I am not able to build with errors on wstring.
I tried to test a simple application which uses
wstring, like
#include string
#include iostream
int main( )
{
using namespace std;
const basic_string wchar_t s1 ( Labc );
wstring s2 ( Labc ); // Uses the typedef
for wstring
if ( s1 == s2 )
cout The strings s1 s2 are equal.
endl;
else
cout The strings s1 s2 are not equal.
endl;
}
and on compiling I am getting the following
error..
--g++ main.cpp -o main
main.cpp: In function `int main()':
main.cpp:8: error: `wstring' undeclared (first use
this function)
main.cpp:8: error: (Each undeclared identifier is
reported only once for
each fu
nction it appears in.)
main.cpp:8: error: expected `;' before s2
main.cpp:9: error: `s2' undeclared (first use this
function)
I searched on the net but could not get any thing
recent or useful. Some
old forum threads[2005] say that
it was not supported.
Any advice or pointer will be of great help.
Thanks Regards
Vipin
--
View this message in context:
http://www.nabble.com/wstring-support-in-GCC-4.1.2-in-Cygwin-1.5.25-11-tp17275355p17359564.html
Sent from the Cygwin list mailing list archive at
Nabble.com.
--
Unsubscribe info:
http://cygwin.com/ml/#unsubscribe-simple
Problem reports:
http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
View this message in context:
http://www.nabble.com/wstring-support-in-GCC-4.1.2-in-Cygwin-1.5.25-11-tp17275355p17399580.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: makefile for matlab-engine in cygwin
2008/5/21 [EMAIL PROTECTED]: Hi evereybody I am working with a client/server system and I am trying to extend it with an input client which uses matlab engine to get data from matlab. I would like to compile it with cygwin in windows XP. Just typing 'mex.bat A.c B.c' (where 'A.c' and 'B.c' are a 'reduced' version of the input client) in the cygwin bash shell works fine, but I am a bit struggling with the makefile: I would like to extend an existing makefile which works fine with other input clients. If I just change 'gcc' to 'mex.bat' in the makefile I get the following error: Just out of my head: You are using the lcc template (LCCENGMATOPTS.BAT) and the Win32 perl with the cygwin setup. You should use the GCC template (maybe GCCENGMATOPTS.BAT) and maybe cygwin's perl instead. That's how I did it. But's a long time ago and I don't have access to that machine anymore. lcc should also do it, but then you'll get difficulties when doing cross-compiling to better platforms. So starting with the stricter gcc is a brave goal for your s-functions. $ make Makefile:34: depend: No such file or directory mex.bat -M -g -O3 -std=c99 -Wall -W -Werror -pedantic -I../../server - I../../utility file.c file_input.c flight_info.c input_client.c main.c matlab_flightpath_input.c orientation.c parse_arg.c pdf.c position.c time_stamp.c ../../utility/file.c ../../utility/tcp.c ../../utility/parse_arg.c ./../server/flight_info.c ../../server/pdf.c ../../server/position.c ../../serv er/time_stamp.c ../../server/o rientation.c ../../server/input_client.c ../../server/client.c depend make: [depend] Error 9 (ignored) depend:2: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. Appendix 1: makefile CC = gcc ... Appendix 2: mexopts.bat file rem LCCENGMATOPTS.BAT rem remCompile and link options used for building standalone engine or MAT remprograms remwith LCC C compiler 2.4 ... set PATH=%MATLAB%\sys\lcc\bin;%PATH% set LCCMEX=%MATLAB%\sys\lcc\mex set PERL=%MATLAB%\sys\perl\win32\bin\perl.exe set MW_TARGET_ARCH=win32 rem rem Compiler parameters rem set COMPILER=lcc set OPTIMFLAGS=-DNDEBUG set DEBUGFLAGS=-g4 set COMPFLAGS=-c -Zp8 -I%MATLAB%\sys\lcc\include -noregistrylookup set NAME_OBJECT=-Fo Any help or pointers in the right direction would be highly appreciated. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: _pinfo::dup_proc_pipe: DuplicateHandle failed
On Wed, 21 May 2008, Relson, David wrote: Hi Hugh, I'm not an expert (else I'd solve this myself), but it seems not to be a when it comes to windows, neither am I, but since nobody else is coming in on this thread I'll see if I can get you any further forward. problem with make, but a general problem in duplicating handles for subprocesses. To test that, I entered a classic Hello World program and created a 2 line script named hello.sh to build it: relsondt1-- cat ./hello.sh #!/bin/sh -x Bcc +BccDos.cfg -c -Ic:/BC45/INCLUDE -D -oHELLO.OBJ HELLO.CPP This is the sort of narrowing down that helps. relsondt1-- ./hello.sh + Bcc +BccDos.cfg -c -Ic:/BC45/INCLUDE -D -oHELLO.OBJ HELLO.CPP 7 [main] bash 5564! _pinfo::dup_proc_pipe: DuplicateHandle failed, \ pid 5564, hProcess 0x6DD, wr_proc_pipe 0x750, Win32 error 6 That Win32 error looks more like it is to do with Windows than Cygwin per se. So what is Win32 error 6 (apart from a very unintuitive error message? Google points me at various things, including this: http://www.freeerrorscan.net/landing/error/error-6.php?t202kw=error%206m=pc=3lpip=538gclid=CKrViK32uZMCFQ88QwodgQR3DA which says there are problems with your registry if you get this. I'm not in a position to give advice on how to fix this. I don't really know what the best cleanup programs are or how to test their trustworthiness. But I'd like to know. Also, I don't know whether to trust that source as being accurate. Borland C++ 4.52 Copyright (c) 1987, 1994 Borland International hello.cpp: Warning hello.cpp 8: Parameter 'argc' is never used in function \ main(int,char * *) Warning hello.cpp 8: Parameter 'argv' is never used in function \ main(int,char * *) As can be seen, the message is displayed _and_ the compiler is run. this would seem to fit with the hypothesis that this is something amiss which is not directly related to Cygwin or your program, because the script does its job. But I wouldn't say it counts as proof. Note that I've used \ and indentation to indicate wrapped/continued lines. HTH, David Hugh -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: _pinfo::dup_proc_pipe: DuplicateHandle failed
Hugh Sasse wrote on 22 May 2008 12:08: relsondt1-- ./hello.sh + Bcc +BccDos.cfg -c -Ic:/BC45/INCLUDE -D -oHELLO.OBJ HELLO.CPP 7 [main] bash 5564! _pinfo::dup_proc_pipe: DuplicateHandle failed, \ pid 5564, hProcess 0x6DD, wr_proc_pipe 0x750, Win32 error 6 That Win32 error looks more like it is to do with Windows than Cygwin per se. So what is Win32 error 6 http://msdn.microsoft.com/en-us/library/ms681382(VS.85).aspx ERROR_INVALID_HANDLE which says there are problems with your registry if you get this. No, it's what you'd expect if you try and dup a handle that's already been closed - an indication that the child exited prematurely. This is one of those semi-generic fork failures that could be BLODA, but another possibility is that because this is a non-cygwin app being launched from cygwin, it might be pulling in a dll that causes a rebase conflict. Following the rebaseall procedure described in the Usage: section of /usr/share/doc/Cygwin/rebase-2.4.3.README might help as is, or it might be necessary to find a list of the dlls being pulled in by the borland compiler and rebase them too by adding a -T option pointing to a file that lists the (cygwin-style posix) paths to the BC45 dlls. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setfacl on Cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 5/21/2008 5:05 PM: | Hi Eric, | | I'm looking at ACL support for gnulib. Can you reproduce this with a | recent Cygwin? With a two-year-old Cygwin I got this: I reproduced the same symptoms with cygwin 1.5.25-11. | | $ touch foo | | $ getfacl foo | # file: foo | # owner: haible | # group: None | user::rw- | group::r-- | mask:rwx | other:r-- | | $ setfacl -m user:4:--x foo | setfacl: No error | | $ echo $? | 0 | | $ getfacl foo | # file: foo | # owner: haible | # group: None | user::rw- | group::r-- | mask:rwx | other:r-- | | The setfacl program | 1. complained about No error, | 2. exited with exit code 0 although it did not execute the requested change. | | Bruno | | - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg1XVsACgkQ84KuGfSFAYDZ3wCeMRFdZ4W2Li56pAJkTPJY16ry QygAnA8TDzi/fNw3Agy0w2qEV6RmFefY =5bUN -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setfacl on Cygwin
On May 22 05:47, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 5/21/2008 5:05 PM: | Hi Eric, | | I'm looking at ACL support for gnulib. Can you reproduce this with a | recent Cygwin? With a two-year-old Cygwin I got this: I reproduced the same symptoms with cygwin 1.5.25-11. | | $ touch foo | | $ getfacl foo | # file: foo | # owner: haible | # group: None | user::rw- | group::r-- | mask:rwx | other:r-- | | $ setfacl -m user:4:--x foo | setfacl: No error | | $ echo $? | 0 | | $ getfacl foo | # file: foo | # owner: haible | # group: None | user::rw- | group::r-- | mask:rwx | other:r-- | | The setfacl program | 1. complained about No error, | 2. exited with exit code 0 although it did not execute the requested change. The problem is that the request can't be executed because we have no mapping from uid 4 to a Windows SID. OTOH, the underlying Solaris function acl() does not define any error code for a non-existant user because it's not an error on Solaris. What error code do you want? EINVAL? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setfacl on Cygwin
On May 22 14:34, Corinna Vinschen wrote: On May 22 05:47, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 5/21/2008 5:05 PM: | Hi Eric, | | I'm looking at ACL support for gnulib. Can you reproduce this with a | recent Cygwin? With a two-year-old Cygwin I got this: I reproduced the same symptoms with cygwin 1.5.25-11. | | $ touch foo | | $ getfacl foo | # file: foo | # owner: haible | # group: None | user::rw- | group::r-- | mask:rwx | other:r-- | | $ setfacl -m user:4:--x foo | setfacl: No error | | $ echo $? | 0 | | $ getfacl foo | # file: foo | # owner: haible | # group: None | user::rw- | group::r-- | mask:rwx | other:r-- | | The setfacl program | 1. complained about No error, | 2. exited with exit code 0 although it did not execute the requested change. The problem is that the request can't be executed because we have no mapping from uid 4 to a Windows SID. OTOH, the underlying Solaris function acl() does not define any error code for a non-existant user because it's not an error on Solaris. What error code do you want? EINVAL? I applied a patch to CVS so this situation will return an Invalid argument error message now. Thanks for the report, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
/dev/console
i am getting some kinda error with init, its not executing scripts in runlevels. syslogd logs May 22 18:07:37 node1 init: PID 1832: `init' service stopped, exit status: 0 May 22 18:07:37 node1 init: open(/dev/console): Permission denied May 22 18:07:43 node1 init: can't open /dev/console May 22 18:07:43 node1 init: can't open /dev/console May 22 18:07:43 node1 init: Entering runlevel: 3 May 22 18:07:43 node1 init: open(/dev/console): Permission denied May 22 18:07:44 node1 init: PID 2744: `init' service started May 22 18:07:44 node1 webmin[2296]: Webmin starting May 22 18:07:45 node1 init: no more processes left in this runlevel May 22 18:18:31 node1 -- MARK -- anybody From Chandigarh to Chennai - find friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: /dev/console
On May 22 18:35, Jaspreet Singh wrote: i am getting some kinda error with init, its not executing scripts in runlevels. syslogd logs May 22 18:07:37 node1 init: PID 1832: `init' service stopped, exit status: 0 May 22 18:07:37 node1 init: open(/dev/console): Permission denied May 22 18:07:43 node1 init: can't open /dev/console May 22 18:07:43 node1 init: can't open /dev/console May 22 18:07:43 node1 init: Entering runlevel: 3 May 22 18:07:43 node1 init: open(/dev/console): Permission denied May 22 18:07:44 node1 init: PID 2744: `init' service started May 22 18:07:44 node1 webmin[2296]: Webmin starting May 22 18:07:45 node1 init: no more processes left in this runlevel May 22 18:18:31 node1 -- MARK -- You can't use /dev/console for logging. When running init as a service, it has no console. Change your syslogd configuration. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: wstring support in GCC 4.1.2 in Cygwin 1.5.25-11
I just come across one article in google about UTF-8 Cygwin http://www.okisoft.co.jp/esc/utf8-cygwin/ Just wanted to check about this. As per the documentation here it says that the Cygwin it is providing will suport Unicode. Is it worth to go back and try this out. Brian Dessent wrote: jadooo wrote: Please let me know if I am doing anything wrong. Yes, you are misunderstanding the nature of the problem. In order to support the wstring class, gcc relies on the platform's libc supporting wide character C99 functions. newlib does not have the necessary support[1] so until that work is contributed, the wstring class cannot be enabled in libstdc++. And even then, you'd have to rebuild libstdc++ which means rebuilding all of gcc. Cygwin 1.7 currently contains support for unicode characters in filenames, but this is a far cry from general wide character string support (e.g. wprintf) so simply upgrading to 1.7 will not do anything. Larry's suggestion that this will start working in 1.7 is premature, unless somebody contributes the necessary newlib improvements before 1.7 is released. Brian [1] For a list of the missing features see http://cygwin.com/ml/cygwin-developers/2008-04/msg00094.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- View this message in context: http://www.nabble.com/wstring-support-in-GCC-4.1.2-in-Cygwin-1.5.25-11-tp17275355p17405074.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: wstring support in GCC 4.1.2 in Cygwin 1.5.25-11
jadooo wrote: I just come across one article in google about UTF-8 Cygwin http://www.okisoft.co.jp/esc/utf8-cygwin/ Just wanted to check about this. As per the documentation here it says that the Cygwin it is providing will suport Unicode. Is it worth to go back and try this out. You can try it out but it's important to keep in mind 2 things: 1. This is a patch that has not been accepted into CVS. 1.7.x is accomplishing the same thing by going a different path. 2. This patch still only affects cygwin1.dll. There is no newlib patch. So this doesn't get you any closer to your goal than the snapshot does. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
fate/resolution/location of things like sys/sockio.h
Hi, I'm trying to build nmap from scratch to track down some security issues. It seems to be choking on this, configure:4180: result: no configure:4208: checking for sys/ioccom.h configure:4216: result: no configure:4104: checking sys/sockio.h usability configure:4121: gcc -c -g -O2 conftest.c5 conftest.c:53:24: sys/sockio.h: No such file or directory configure:4127: $? = 1 configure: failed program was: | /* confdefs.h. */ but I can't figure out exactly what the status of sys/sockio.h is from the results here: http://www.google.com/search?hl=enq=site%3Acygwin.com++%22sockio.h%22 Is there a definitive way to fix this? Some posts on non-cygwin sites but nothing seems to get beyond it didn't build what is wrong? Thanks. Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)- leave message 989-348-4796 (P)- emergency only [EMAIL PROTECTED] Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: Hotmail is possibly blocking my mom's entire ISP - try me on [EMAIL PROTECTED] if no reply here. Thanks. _ E-mail for the greater good. Join the i’m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ GreaterGood -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: fate/resolution/location of things like sys/sockio.h
Mike Marchywka wrote on 22 May 2008 16:03: but I can't figure out exactly what the status of sys/sockio.h is from the results here: http://www.google.com/search?hl=enq=site%3Acygwin.com++%22sockio.h%22 Wrong place to look, surely? http://cygwin.com/cgi-bin2/package-grep.cgi?grep=sys%2Fsockio.h Is there a definitive way to fix this? Fix what exactly? The fact that cygwin doesn't supply or support sys/sockio.h? Well, yes, there is a definitive way to fix it: http://cygwin.com/acronyms#PTC cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setfacl on Cygwin
Corinna Vinschen wrote: What error code do you want? EINVAL? EINVAL sounds right, yes. The Solaris manual page [1] also mentions it: EINVAL ... the cmd argument is SETACL or ACE_SETACL and the ACL specified in aclbufp is not valid. I applied a patch to CVS so this situation will return an Invalid argument error message now. Thanks. Will the setfacl program then exit with non-zero exit code (since it could not set the requested ACL)? Bruno [1] http://docs.sun.com/app/docs/doc/816-5167/acl-2?l=ena=view -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setfacl on Cygwin
On Thu, May 22, 2008 at 12:36 PM, Bruno Haible [EMAIL PROTECTED] wrote: Corinna Vinschen wrote: What error code do you want? EINVAL? EINVAL sounds right, yes. The Solaris manual page [1] also mentions it: EINVAL ... the cmd argument is SETACL or ACE_SETACL and the ACL specified in aclbufp is not valid. Right. That's the thing - this is a different error condition, one that could not possibly arise on Solaris (since there is only one concept of user there). The question is, what should the error code be for this new condition that can only arise on Cygwin? Since it's an invalid user identity for the requested operation, EINVAL seems appropriate; it's just not what the man page says EINVAL means in this context. The only other standard error code that leaps out at me as possibly appropriate is EPERM (Operation not permitted). Sadly, the no such thing exists errors are all quite specific as to the thing in question: ENOENT for files, ESRCH for processes, ENXIO for devices, etc. -- Mark J. Reed [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setfacl on Cygwin
On May 22 18:36, Bruno Haible wrote: Corinna Vinschen wrote: What error code do you want? EINVAL? EINVAL sounds right, yes. The Solaris manual page [1] also mentions it: EINVAL ... the cmd argument is SETACL or ACE_SETACL and the ACL specified in aclbufp is not valid. I applied a patch to CVS so this situation will return an Invalid argument error message now. Thanks. Will the setfacl program then exit with non-zero exit code (since it could not set the requested ACL)? It will now, I just applied a patch. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: wstring support in GCC 4.1.2 (OS independent)
Brian Dessent wrote: jadooo wrote: Please let me know if I am doing anything wrong. Yes, you are misunderstanding the nature of the problem. In order to support the wstring class, gcc relies on the platform's libc supporting wide character C99 functions. --- Even though the kernel (cygwin 1.5) doesn't support unicode shouldn't it be possible -- and desirable for gcc to support the 'wstring' datatype? It does seem 'wstring' is supported on standard linux, but internally, the kernel doesn't support double-wide characters anymore than cygwin. So maybe the problem is not that cygwin doesn't support unicode, but that the gcc libs compile utils don't support the standard linux equivalents? Whether or not cygwin (or the linux kernel) supports wchar is not entirely relevant to what the application libraries on top of the kernel support -- at least going by the example on an x86_64 linux. It's still the case that the 64-bit linux kernel doesn't support wchars any more than cygwin, yet the compiler suite does. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: wstring support in GCC 4.1.2 in Cygwin 1.5.25-11
jadooo wrote: Thanks a lot for the valuable information. I am trying to port my application developed in linux to windows, now as it is quiet clear that I could not use cygwin, due to lack of Unicode support, is there any other alternative to try out my porting activity. --- Linux doesn't support double-wide characters in its system calls -- it's all in 'glibc'. Cygwin doesn't need to support unicode anymore than the linux kernel does. It's whoever built the gcc/glib packages that needs to supply that application-level (not system-level) datatype. In the same way, gcc/glib supports 64-bit data types on 32-bit machines and the glib file I/O transparently supports 64-bit file offsets even on 32-bit machines. But, AFAIK, glib doesn't support calling the standard *nix file-io calls with 'wchar' comprised wstrings. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: fate/resolution/location of things like sys/sockio.h
From: [EMAIL PROTECTED] Date: Thu, 22 May 2008 16:15:16 +0100 Thanks. If you are interested, let me try to give a chronology of follow on events as best as I can reconstruct: 1::: Wrong place to look, surely? http://cygwin.com/cgi-bin2/package-grep.cgi?grep=sys%2Fsockio.h Oddly enough, that helped :) OK, so I copied sockio.h and also needed ioccom.h. Just to be clear, http://cygwin.com/cgi-bin/cvsweb.cgi/src/newlib/libc/sys/linux/sys/ioccom.h?cvsroot=src my install is messed up so I'm not sure this problem applies to anyone else but I'm just being complete incase it matters. 2::: Then, I encountered a define problem. This seems to have occured elsewhere so I thought I would post the issue with definition of ssize_t: http://code.google.com/p/xdelta/issues/detail?id=56 This turned out to be flagged with __CYGWIN__ and also easy to fix in the makefile. 3:: But, then I had a missing definition for IFF_POINTOPOINT which does seem to be an issue with cygwin. According to this, the symbol should be defined in if.h: https://www.linux-foundation.org/dbadmin/browse/headgroup.php?cmd=list-byheadgroupHGid=437 my if.h needed to be modified, #define IFF_LOOPBACK0x8 /* is a loopback net*/ // #define IFF_POINTOPOINT0x10/* mjm,*/ // https://www.linux-foundation.org/dbadmin/browse/headgroup.php?cmd=list-byheadgroupHGid=437 #define IFF_NOTRAILERS 0x20/* avoid use of trailers*/ 4: Next, a problem with INET6_ADDSTRLEN16. I found this and implemented the suggestion, http://viral.media.mit.edu/peers/peers-win.html #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ which again seemed to work but I have no idea what other problems may turn up if this isn't right. 5 Then I finally encountered a big link problem and determined that some pieces were built with and without -mno-cygwin. I was finally able to stop it from complaining by grepping all the libraries for the missing symbols and just randomly adding stuff but, duh, the executable wouldn't run. I can probably figure this out but I've never built anything with -mno-cygwin before so it will probably take a while. Thanks. Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)- leave message 989-348-4796 (P)- emergency only [EMAIL PROTECTED] Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: Hotmail is possibly blocking my mom's entire ISP - try me on [EMAIL PROTECTED] if no reply here. Thanks. From: [EMAIL PROTECTED] To: cygwin@cygwin.com Subject: RE: fate/resolution/location of things like sys/sockio.h Date: Thu, 22 May 2008 16:15:16 +0100 Mike Marchywka wrote on 22 May 2008 16:03: but I can't figure out exactly what the status of sys/sockio.h is from the results here: http://www.google.com/search?hl=enq=site%3Acygwin.com++%22sockio.h%22 Wrong place to look, surely? http://cygwin.com/cgi-bin2/package-grep.cgi?grep=sys%2Fsockio.h Is there a definitive way to fix this? Fix what exactly? The fact that cygwin doesn't supply or support ? Well, yes, there is a definitive way to fix it: http://cygwin.com/acronyms#PTC cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ _ Give to a good cause with every e-mail. Join the i’m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?souce=EML_WL_ GoodCause -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: fate/resolution/location of things like sys/sockio.h
On Thu, May 22, 2008 at 05:48:14PM -0400, Mike Marchywka wrote: From: [EMAIL PROTECTED] Date: Thu, 22 May 2008 16:15:16 +0100 Thanks. If you are interested, let me try to give a chronology of follow on events as best as I can reconstruct: 1::: Wrong place to look, surely? http://cygwin.com/cgi-bin2/package-grep.cgi?grep=sys%2Fsockio.h Oddly enough, that helped :) OK, so I copied sockio.h and also needed ioccom.h. Just to be clear, http://cygwin.com/cgi-bin/cvsweb.cgi/src/newlib/libc/sys/linux/sys/ioccom.h?cvsroot=src my install is messed up so I'm not sure this problem applies to anyone else but I'm just being complete incase it matters. As the sys/linux above implies, this is linux-specific code. It has no bearing for cygwin. 2::: Then, I encountered a define problem. This seems to have occured elsewhere so I thought I would post the issue with definition of ssize_t: http://code.google.com/p/xdelta/issues/detail?id=56 This turned out to be flagged with __CYGWIN__ and also easy to fix in the makefile. 3:: But, then I had a missing definition for IFF_POINTOPOINT which does seem to be an issue with cygwin. According to this, the symbol should be defined in if.h: https://www.linux-foundation.org/dbadmin/browse/headgroup.php?cmd=list-byheadgroupHGid=437 my if.h needed to be modified, #define IFF_LOOPBACK0x8 /* is a loopback net*/ // #define IFF_POINTOPOINT0x10/* mjm,*/ // https://www.linux-foundation.org/dbadmin/browse/headgroup.php?cmd=list-byheadgroupHGid=437 #define IFF_NOTRAILERS 0x20/* avoid use of trailers*/ 4: Next, a problem with INET6_ADDSTRLEN16. I found this and implemented the suggestion, http://viral.media.mit.edu/peers/peers-win.html #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ which again seemed to work but I have no idea what other problems may turn up if this isn't right. 5 Then I finally encountered a big link problem and determined that some pieces were built with and without -mno-cygwin. I was finally able to stop it from complaining by grepping all the libraries for the missing symbols and just randomly adding stuff but, duh, the executable wouldn't run. I can probably figure this out but I've never built anything with -mno-cygwin before so it will probably take a while. Sorry but you're very confused by this point. Compiling with -mno-cygwin means that you can't use ANY cygwin headers. You won't be able to create an executable which works this way. When Dave said ...cygwin doesn't supply or support sys/sockio.h he wasn't kidding. It isn't supplied and copying it from a random source and randomly making changes is not going to work. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cscope on cygwin
Hi Eva, Sorry for the delay in replying - I just checked my cscope mail. You can do what you want, but you are falling in to the trap of .cmd file extensions. When you set the EDITOR variable to a .cmd file, it will be run as a windows script, not a bash script. Your use of only works in bash scripts, not windows scripts. I created a script called cs_edit and did: shift /c/windows/notepad.exe $@ Let me explain what this does.When I run mlcscope and pick a line, the arguments given to $EDITOR are +2 filename For some reason which I am not sure of right now, +2 is the first argument. That isn't right and I'll look at that separately, but for now the shift causes all the arguments to shift down one place and it drops the first arg so the arguments become just the filename, Then the $@ puts the argument list on the command line as you expected. I think the reason you tried %2 is to avoid that first argument right? As you deduced, the '' runs the command in the background. Make sure that cs_edit is in your path and is executable (chmod 755 cs_edit), and you should be up and running. Let me know if you have any other problems. Cheers Dave Barladeanu Eva-BEB047 wrote: Hello, I am a newcomer to cygwin. I installed mlcscope-14.1.8-2 on an XP service pack 2 machine. I built the cscope.out data base and I can run searches on the data base. I defined the EDITOR variable as follows: EDITOR=/cygdrive/d/Profiles/myaccount/cs_editor.cmd Where the cs_editor.cmd files contains: textpad %2 Trying to open a file of the search result, textpad opens the file. The problem is that while textpad is open I have no access to cscope and can not open more files or run subsequent searches. This behavior is like in UNIX when I open the text editor in foreground. Can I run somehow the textpad in background? Thank you, Eva Barladeanu Motorola -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Diane Dave http://www.velvetstarbears.com/ http://www.kringlecottage.com/ Fortune: The difference between America and England is that the English think 100 miles is a long distance and the Americans think 100 years is a long time. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: wstring support in GCC 4.1.2 in Cygwin 1.5.25-11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Linda Walsh on 5/22/2008 1:14 PM: | Linux doesn't support double-wide characters in its | system calls -- it's all in 'glibc'. | | Cygwin doesn't need to support unicode anymore than | the linux kernel does. It's whoever built the gcc/glib | packages that needs to supply that application-level (not | system-level) datatype. Please get your terms straight. glib is something MUCH different than glibc. glib is ported to cygwin, glibc is not. glib is a graphics library, glibc is an implementation of libc. Cygwin uses newlib as its implementation of libc. And that's why cygwin doesn't support wstring - because newlib does not have very complete wide character support. But you are correct that it is the job of libc, and not the kernel, to provide application-level code that interprets byte sequences as wide characters. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg2IoMACgkQ84KuGfSFAYDXtQCeI20yMSPSKhvW2wdRhiZfSm3V usIAoKJ/i0GgKQJeVfPJSt92y+fe8VAB =hwpH -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: wstring support in GCC 4.1.2 (OS independent)
Linda Walsh wrote: So maybe the problem is not that cygwin doesn't support unicode, but that the gcc libs compile utils don't support the standard linux equivalents? I can't parse this. Whether or not cygwin (or the linux kernel) supports wchar is not entirely relevant to what the application libraries on top of the kernel support -- at least going by the example on an x86_64 linux. It's still the case that the 64-bit linux kernel doesn't support wchars any more than cygwin, yet the compiler suite does. Comparing Cygwin to the linux kernel is nonsense. They serve totally different purposes -- Cygwin is a user-mode library. If you want to make a comparison, compare Cygwin to glibc as they are both libcs. And again, the compiler suite cannot implement wstring without underlying libc wide character IO support which does not exist in newlib and therefore does not exist in Cygwin. Remember that gcc is divorced from the target libc because a libc is way too OS-dependent. gcc relies on the platform to implement its own libc, and everything gcc implements builds on top of an existing libc. If the libc doesn't have the necessary support there's nothing that libstdc++ can do about it but disable wstring. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
