Re: static vs. shared linking
David Stacey writes: > Thank you for your reply. I tried this two different ways: > > - Running 'rebase -s' on cygcrash_library.dll; Better try 'rebase -O' if you're just experimenting. > - Moving 'cygcrash_library.dll' into /usr/bin and triggering a full > rebase using 'rebase-trigger full' and then running setup-x86_64.exe. As long as it isn't mentioned in /etc/setup/*.lst.gz that won't do anything. You could put the location for your library into a file in /var/lib/rebase/user.d to have it picked up by the autorebase. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Adding font path to X server
Boylan, Ross writes: > I need the Cygwin X server to have access to fonts from dosemu; currently I have to add the path manually each > time I start. I thought I was following the manual by setting up .startxwinrc as > xset fp+ /usr/share/fonts/dosemu > xterm > > but startxwin fails to start (details below). How do I avoid having to set the path manually? > > I'd appreciate cc's as my subscription to the list is currently in an odd state, and may not be working. Sorry, no can do with the gmane ML gateway I'm using. Hope you see this on the mailing list. > $ startxwin > Welcome to the XWin X Server [...] > xset: bad font path element (#6), possible causes are: > Directory does not exist or has wrong permissions > Directory missing fonts.dir > Incorrect font server address or syntax > /home/rdboylan/.startxwinrc: line 2: $'xterm\r': command not found > xinit: connection to X server lost > > The commands in .startwinxrc work fine when typed into an xterm after X launches. You appear to have at least one CR character in your .startxwinrc file. Use d2u on the file to get rid of it/them. If that alone doesn't fix your issue, you may need to add 'xset fp rehash' after the existing 'xset' command. Be sure not to add more CR chars if you edit the file again :-) . ..mark -- 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
How can I contribute a FAQ entry for MITM? Should there be a FAQ entry on how to add FAQ entries?
I'd like to propose text to add to the Cygwin FAQ (https://cygwin.com/faq/ ) about how Cygwin counters MITM attacks. How can I propose such text? Also: shouldn't "how can I contribute to this FAQ?" be a FAQ entry? Thanks. --- David A. Wheeler -- 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
More about permissions
Dear Cygwin community -- Along with some others, I've been struggling a little to accommodate the changes to permissions handling that came lately. I think I about have it figured out to work mostly Unix-like within my cygwin tree, but have one remaining thing I am wondering about, even though I have been through the ntsec document more than once. (I think everyone will admit that this is complicated :-) ...) - I have created a new group, that I call Cygwin, to be the typical group of cygwin-related files, so that I can control group permissions appropriately. I am a member of that group. - I have found that if a directory is chmod to 2755 (2000 == set gid) and the directory's group is Cygwin, then cygwin-created files in the directory get group Cygwin. (This was not necessarily happening before.) To get this to happen, I had to list the sid of the Cygwin group as my group in my line of the /etc/passwd file. Otherwise the group would be me, which does not seem to allow the same differentiation of user versus group permissions. - I could not find an explanation of the 'mask' list by getfacl. Near as I can tell it is not really settable, although setfacl does not complain, and it is the OR of the permissions of the various groups. Now, to what I would like to do. Ideally I want SYSTEM to have rwx access to everything. Seems a generally good idea on Windows, and at least r permission on files and rx on directories is needed for my backup program to access things. But if I get group:SYSTEM:rwx and default:group:SYSTEM:rwx, then ls always lists rwx for the group part of any such file, and chmod, if applied, affects SYSTEM's access bits. What I'd like is for SYSTEM's role here to be hidden. If there are any files where I want to restrict SYSTEM, I can use Windows tools or setfacl to manipulate them. Is this simply not possible with the new scheme? Regards -- Eliot Moss -- 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: static vs. shared linking
Greetings, David Stacey! >>> Back to the matter in hand - I don't suppose you had thoughts on why my >>> simple application crashes when linked as shared, but works fine when >>> linked statically? >> Probably I've missed this bit before, forgive me if I did, but have you >> rebased your library after linking? > Thank you for your reply. I tried this two different ways: >- Running 'rebase -s' on cygcrash_library.dll; >- Moving 'cygcrash_library.dll' into /usr/bin and triggering a full > rebase using 'rebase-trigger full' and then running setup-x86_64.exe. I think you need to rebase both your app and library (assuming they both Cygwin dependent). Simply moving it around wouldn't help, rebase only tend to apps in its list(s). > Sadly, neither of these made any difference - the application still > crashed :-( Well, shoot... was worth a try, at the very least. -- With best regards, Andrey Repin Tuesday, March 31, 2015 03:22:01 Sorry for my terrible english... -- 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: static vs. shared linking
On 30/03/2015 21:30, Andrey Repin wrote: Greetings, David Stacey! Back to the matter in hand - I don't suppose you had thoughts on why my simple application crashes when linked as shared, but works fine when linked statically? Probably I've missed this bit before, forgive me if I did, but have you rebased your library after linking? Thank you for your reply. I tried this two different ways: - Running 'rebase -s' on cygcrash_library.dll; - Moving 'cygcrash_library.dll' into /usr/bin and triggering a full rebase using 'rebase-trigger full' and then running setup-x86_64.exe. Sadly, neither of these made any difference - the application still crashed :-( Thanks for the suggestion anyway, Dave. -- 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: static vs. shared linking
Greetings, David Stacey! > Back to the matter in hand - I don't suppose you had thoughts on why my > simple application crashes when linked as shared, but works fine when > linked statically? Probably I've missed this bit before, forgive me if I did, but have you rebased your library after linking? -- With best regards, Andrey Repin Monday, March 30, 2015 23:29:13 Sorry for my terrible english... -- 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: Rebase, Peflags, and cygserver
On 3/27/2015 9:55 PM, Ken Brown wrote: Depends, but anything that could interfere with the rebase is a potential problem. I've run into the OP's problem occasionally, where a full rebase doesn't fix all rebase/fork problems. What's worked for me on those occasions is to reboot the computer and then run a full rebase. I once saw an explanation of why rebooting makes a difference, but I don't remember what it was. Ken One possible way is: ps -x to identify the PID of the program with problems less /proc/PID/maps to look on memory space used by the several dll's Regards Marco -- 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
Adding font path to X server
I need the Cygwin X server to have access to fonts from dosemu; currently I have to add the path manually each time I start. I thought I was following the manual by setting up .startxwinrc as xset fp+ /usr/share/fonts/dosemu xterm but startxwin fails to start (details below). How do I avoid having to set the path manually? I'd appreciate cc's as my subscription to the list is currently in an odd state, and may not be working. $ startxwin Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.17.1.0 OS: CYGWIN_NT-6.1 WIHS-1QS3PW1-DT 1.7.35(0.287/5/3) 2015-03-04 12:09 x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.17.1-2 built 2015-02-23 XWin was started with the following command line: /usr/bin/XWin :0 -multiwindow -auth /home/rdboylan/.serverauth.5388 .. winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. winClipboardProc - XOpenDisplay () returned and successfully opened the display. xset: bad font path element (#6), possible causes are: Directory does not exist or has wrong permissions Directory missing fonts.dir Incorrect font server address or syntax /home/rdboylan/.startxwinrc: line 2: $'xterm\r': command not found xinit: connection to X server lost The commands in .startwinxrc work fine when typed into an xterm after X launches. -- 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: static vs. shared linking
On 30/03/15 11:55, Corinna Vinschen wrote:
On Mar 25 22:42, David Stacey wrote:
I've never had much joy out of addr2line before, and I'm struggling to
recreate what you've done. I've added '-g' to the command line, run 'go.sh'
again. This generates a fresh stackdump file, and then I do:
awk '/^[0-9]/{print $2}' shared_test.exe.stackdump | addr2line -f -e
shared_test.exe
but I just see question marks. Please could you show the exact lines you're
using.
addr2line is a bit dumb and needs help. What I do is to cat the
stackdump file and look at the addresses. They usually show where
the stuff comes from:
$ gawk '/^0/{print $2}' mkgroup.exe.stackdump
7FFBDC82DDB6
001800FEC36
001800FE188
001800CF471
001800CF53D
0018007EAC1
00100402DE6
00180049411
00180046369
00180046180
00180049488
00100401351
00100401010
7FFBD9FE13D2
7FFBDC85EB64
The 7f addresses are from OS DLLs you can't read with addr2line.
0018xxx is the Cygwin DLL, 0010xxx is the application itself. Other
addresses are other DLLs. Just check the addresses against
/etc/rebase.db.x86_64.
Then call addr2line for each object file, e.g.:
$ addr2line -e /usr/bin/cygwin1.dll 001800FEC36 001800FE188 001800CF471
[...]/cygwin/passwd.cc:576
[...]/cygwin/passwd.cc:353
[...]/cygwin/grp.cc:413
$ addr2line -e /usr/bin/mkgroup.exe 00100401351 00100401010
/usr/src/debug/cygwin-1.7.35-1/winsup/cygwin/lib/cygwin_crt0.c:22
/usr/src/debug/cygwin-1.7.35-1/winsup/cygwin/crt0.c:34
Thank you for your reply and the explanation. That requires quite a bit
of knowledge before addr2line is usable - no wonder I've never had
anything sensible out of it before!
Back to the matter in hand - I don't suppose you had thoughts on why my
simple application crashes when linked as shared, but works fine when
linked statically?
Dave.
--
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: New cygport: perl-WWW-Curl
Yaakov Selkowitz writes: >> Producing a cygport file for a Perl distribution is not a problem. The >> question here is how stable the libcurl API is, since that determines if >> the package should be updated by the curl maintainer or somebody else >> (me, most likely). > > The libcurl API is quite stable. OK, I'll prepare an ITP. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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: New cygport: perl-WWW-Curl
On Mon, 2015-03-30 at 20:20 +0200, Achim Gratz wrote: > Florian Friesdorf writes: > > attached is a cygport file for perl-WWW-Curl and I'd kindly like to ask, > > whether you could include it into the mirrored package collection. > > Producing a cygport file for a Perl distribution is not a problem. The > question here is how stable the libcurl API is, since that determines if > the package should be updated by the curl maintainer or somebody else > (me, most likely). The libcurl API is quite stable. -- 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: New cygport: perl-WWW-Curl
Florian Friesdorf writes: > attached is a cygport file for perl-WWW-Curl and I'd kindly like to ask, > whether you could include it into the mirrored package collection. Producing a cygport file for a Perl distribution is not a problem. The question here is how stable the libcurl API is, since that determines if the package should be updated by the curl maintainer or somebody else (me, most likely). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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
cygrunsrv no longer allows domain user
This used to work (before Corinna's db work): $ cygrunsrv -I myservice -d 'myservice' -u 'ISCINTERNAL\build' -w donotuseme -p /cygdrive/f/tut/install.sh cygrunsrv: Error installing a service: CreateService: Win32 error 1057: The account name is invalid or does not exist, or the password is invalid for the account name specified. Using + doesn't help either: $ cygrunsrv -I myservice -d 'myservice' -u 'ISCINTERNAL+build' -w donotuseme -p /cygdrive/f/tut/install.sh cygrunsrv: Error installing a service: CreateService: Win32 error 1057: The account name is invalid or does not exist, or the password is invalid for the account name specified. Is there an incantation that will work? -- -Len -- 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: Rebase, Peflags, and cygserver
>-Original Message- >From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of >Ken Brown >Sent: Friday, March 27, 2015 3:56 PM >To: cygwin@cygwin.com >Subject: Re: Rebase, Peflags, and cygserver > >On 3/27/2015 4:28 PM, Achim Gratz wrote: >> J. David Boyd writes: >>> What I'm doing (with some success)is this: >>> >>> 1. get latest cygwin update >>> 2. del /etc/rebase* >>> 3. rebaseall -v >>> 4. peflagsall -v >>> 5. don't restart cygserver (This means my bash shell window starts a >>> little slower, but I can live with that.) >> >> From the announcement of _autorebase: >> >> To perform a full rebase, execute "rebase-trigger fullrebase". Then >> shut down Cygwin and simply run setup.exe. The rebase will be >> performed even when the installation did not get modified in any way. >> Any subsequent runs of setup.exe will again rebase in incremental >> mode. >> >>> I usually have to do this 2 to 3 times before I can get emacs to >>> start without vfork errors. >> >> Do you use Cygwin Emacs or something else? >> >>> Also, I often run Cygwin Setup (to get something I've missed, like >>> wget..., or check for updates) while emacs is running. Should I shut it >>> down first? >> >> Depends, but anything that could interfere with the rebase is a >> potential problem. > >I've run into the OP's problem occasionally, where a full rebase doesn't fix >all rebase/fork problems. What's worked for me on those >occasions is to >reboot the computer and then run a full rebase. I once saw an explanation of >why rebooting makes a difference, but I >don't remember what it was. >Ken This morning I had to do *two* reboots followed by rebaseall. Is there any way to know what BLODA is making this so time consuming, i.e., painful? -- 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: Possible chmod problem with a path [WARNING: SPF validation failed]
Well well -- making that fstab change alone (and rebooting) seems to have fixed it! Release notes says: Since 1.7.34, chmod does not always affect the POSIX permission mask as returned by stat(2) or printed by ls(1), due to the improved POSIX ACL handling. However, that's still far from perfect, so, as a temporary workaround, chmod now checks if secondary groups and users in the ACL have more permissions than the primary group. If so, the permissions of the secondary users and groups will be reduced according to the mask given by the new primary group permissions. I.e, chmod 600 will remove all permissions from the primary group as well as all secondary user and group entries in the ACL. I read that as, "Here be dragons, and your mileage may vary". So I'll be wary of this, and tell the rest of the team about it, lest they hit similar problems (and spend a bunch of time banging heads on walls!) For the record, if someone is reading this later: - I don't believe SVN is involved, since it happens with C:\temp (and C:/temp) as well - Cygwin seems to have been getting in the way of all file access, since even Windows utilities could not read the files Thanks for the help! ...phsiii -Original Message- From: Andrey Repin [mailto:anrdae...@yandex.ru] Sent: Monday, March 30, 2015 11:28 AM To: Phil Smith; cygwin@cygwin.com Subject: Re: Possible chmod problem with a path [WARNING: SPF validation failed] Greetings, Phil Smith! >>Please use Cygwin paths with Cygwin tools. >>Windows paths are not guaranteed to work with every Cygwin tool. > This is scripted, and while I can hack it to use Cygwin paths, it probably > shouldn't be lying to me, saying that it worked. And it did work before, > still does with older Cygwin (on another machine). "It did work before" doesn't automatically mean "nothing has changed". Please read the release notes for Cygwin 1.7.34 and the relevant article in the documentation http://cygwin.com/cygwin-ug-net/ntsec.html >>What you are doing may or may not work, depends, if you are using Cygwin or >>native Subversion client. >>In either case, it isn't very bright idea to enforce POSIX access mask outside >>Cygwin tree, unless you know what you are doing and absolutely need it. >>From your description, you don't need it at all. > I'm not actually trying to enforce POSIX anything--I'm trying to be able to > read the build artifacts, You are trying to solve your issue by bending Windows permission model into POSIX access mask. Which by definition is prone to be sloppy and approximate at best. > which were put there via mv and cp. Assuming you did it under the same user, I see no reason for it to not be readable. But since it is not, it automatically raises a red flag - SOMETHING IS FUNDAMENTALLY WRONG. I suspect you are trying to cure a symptom of a failed system design. > The compiler is native Windows, isn't creating the artifacts with any special > permissions. So, remove any special permissions treatment in Cygwin - mount the dir with "noacl" flag. > So there's actually another mystery, which is why the artifacts > don't have the right permissions in the first place. They do have right permissions, I presume. But they are not POSIX permissions. Do note the little "+" at the end of POSIX access mask - it is subtly hinting that there's more to it, than what meets the eye. > With the cobbled-together environment (CMake, the Dignus compiler, Cygwin) > this may not be really diagnosable, I realized. I was hoping that there was > some clue in the fact that the path makes a difference. > SVN client is Tortoise. So, I was right. Mixing native and Cygwin tools is only possible, when you 100% know what you are doing. And account for consequences in advance. > I have done a fresh checkout and the problem persists, so it isn't some > weirdness with a tainted file in the source tree, I don't think. /etc/fstab: none /cygdrive cygdrive noacl,binary,posix=0,user 0 0 This may help. Scrap the current checkout/build you;ve messed with and try again after changing the mount options. Make sure you've restarted all the Cygwin apps (rebooting the box isn't a bad idea). -- With best regards, Andrey Repin Monday, March 30, 2015 18:14:31 Sorry for my terrible english... -- 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
New cygport: perl-WWW-Curl
Dear Cygwin maintainers, attached is a cygport file for perl-WWW-Curl and I'd kindly like to ask, whether you could include it into the mirrored package collection. best regards Florian perl-WWW-Curl.cygport Description: Binary data -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 signature.asc Description: PGP signature
Re: Possible chmod problem with a path [WARNING: SPF validation failed]
Greetings, Phil Smith! >>Please use Cygwin paths with Cygwin tools. >>Windows paths are not guaranteed to work with every Cygwin tool. > This is scripted, and while I can hack it to use Cygwin paths, it probably > shouldn't be lying to me, saying that it worked. And it did work before, > still does with older Cygwin (on another machine). "It did work before" doesn't automatically mean "nothing has changed". Please read the release notes for Cygwin 1.7.34 and the relevant article in the documentation http://cygwin.com/cygwin-ug-net/ntsec.html >>What you are doing may or may not work, depends, if you are using Cygwin or >>native Subversion client. >>In either case, it isn't very bright idea to enforce POSIX access mask outside >>Cygwin tree, unless you know what you are doing and absolutely need it. >>From your description, you don't need it at all. > I'm not actually trying to enforce POSIX anything--I'm trying to be able to > read the build artifacts, You are trying to solve your issue by bending Windows permission model into POSIX access mask. Which by definition is prone to be sloppy and approximate at best. > which were put there via mv and cp. Assuming you did it under the same user, I see no reason for it to not be readable. But since it is not, it automatically raises a red flag - SOMETHING IS FUNDAMENTALLY WRONG. I suspect you are trying to cure a symptom of a failed system design. > The compiler is native Windows, isn't creating the artifacts with any special > permissions. So, remove any special permissions treatment in Cygwin - mount the dir with "noacl" flag. > So there's actually another mystery, which is why the artifacts > don't have the right permissions in the first place. They do have right permissions, I presume. But they are not POSIX permissions. Do note the little "+" at the end of POSIX access mask - it is subtly hinting that there's more to it, than what meets the eye. > With the cobbled-together environment (CMake, the Dignus compiler, Cygwin) > this may not be really diagnosable, I realized. I was hoping that there was > some clue in the fact that the path makes a difference. > SVN client is Tortoise. So, I was right. Mixing native and Cygwin tools is only possible, when you 100% know what you are doing. And account for consequences in advance. > I have done a fresh checkout and the problem persists, so it isn't some > weirdness with a tainted file in the source tree, I don't think. /etc/fstab: none /cygdrive cygdrive noacl,binary,posix=0,user 0 0 This may help. Scrap the current checkout/build you;ve messed with and try again after changing the mount options. Make sure you've restarted all the Cygwin apps (rebooting the box isn't a bad idea). -- With best regards, Andrey Repin Monday, March 30, 2015 18:14:31 Sorry for my terrible english... -- 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: Possible chmod problem with a path [WARNING: SPF validation failed]
Thanks for the reply. Some thoughts: >Please use Cygwin paths with Cygwin tools. >Windows paths are not guaranteed to work with every Cygwin tool. This is scripted, and while I can hack it to use Cygwin paths, it probably shouldn't be lying to me, saying that it worked. And it did work before, still does with older Cygwin (on another machine). >What you are doing may or may not work, depends, if you are using Cygwin or >native Subversion client. >In either case, it isn't very bright idea to enforce POSIX access mask outside >Cygwin tree, unless you know what you are doing and absolutely need it. >From your description, you don't need it at all. I'm not actually trying to enforce POSIX anything--I'm trying to be able to read the build artifacts, which were put there via mv and cp. The compiler is native Windows, isn't creating the artifacts with any special permissions. So there's actually another mystery, which is why the artifacts don't have the right permissions in the first place. With the cobbled-together environment (CMake, the Dignus compiler, Cygwin) this may not be really diagnosable, I realized. I was hoping that there was some clue in the fact that the path makes a difference. SVN client is Tortoise. I have done a fresh checkout and the problem persists, so it isn't some weirdness with a tainted file in the source tree, I don't think. -- 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: Handles returned by mq_open are not valid file descriptors as supposed to be under native linux distributions
>For a start, since what you're doing sounds pretty commercial to me,
>may I point out https://cygwin.com/licensing.html? May I assume your
>code is open source?
We're doing researches, principally under native linux. Different target
platforms
are evaluated. That's why we're trying Cygwin as well, but so far, due to the
described
inconsistencies, were not able to generate any useful outputs. It would be
great,
if mqd_t will be a file descriptor one day.
Thanks for your fast response.
>-Original Message-
>From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of
>Corinna Vinschen
>Sent: Monday, March 30, 2015 2:37 PM
>To: cygwin@cygwin.com
>Subject: Re: Handles returned by mq_open are not valid file descriptors as
>supposed to be under native linux distributions
>
>On Mar 27 09:30, KEREP, Mladen wrote:
>> We're using POSIX message queues to pass messages between processes.
>> For this we've build a library layer to be able to use message queues
>> on different platforms. Basically linux (debian, Ubuntu, archlinux,
>> rasbian) is the development platform, but also vxworks platforms are
>> supported.
>>
>> Several message queues are opened through mq_open calls and the
>> returned handles are organized in file descriptor sets (fd_set). The
>> set is then passed over to a select(2) call, which blocks processing
>> and returns as soon as any message in any of the queues arrives.
>>
>> This works under linux, since the handles returned are valid file
>> descriptors and the macros FD_ZERO / FD_SET are able to handle that
>> handles.
>>
>> However, under Cygwin,
>
>For a start, since what you're doing sounds pretty commercial to me,
>may I point out https://cygwin.com/licensing.html? May I assume your
>code is open source?
>
>> mq_open does not directly return file handles,
>> but pointers to (unknown) data structures in memory (ref.
>> http://sourceware.org/ml/cygwin/2013-07/msg00179.html), which cannot
>> be used with FD_ZERO, FD_SET, so not with select(2). I know from the
>> man pages (mq_open): "Polling message queue descriptors On Linux, a
>> message queue descriptor is actually a file descriptor, and can be
>> monitored using select(2), poll(2), or epoll(7). This is not
>> portable."
>>
>> mq_open() and select() conform to POSIX.1-2001, at least under linux,
>> but also under Cygwin ? How can this be modified, so that it works
>> under Cygwin as well ?
>
>"This is not portable" is the important hint in the Linux man page. On
>Cygwin we're using basically the implementation from W. Richard Stevens,
>as published for his book "UNIX Network Programming, Volume 2,
>Interprocess communication". It doesn't support the Linux extensions
>but, yes, it's POSIX compliant, see POSIX.1-2008:
>
> "A message queue descriptor *may* be implemented using a file descriptor,
> in which case applications can open up to at least {OPEN_MAX} file and
> message queues." [emphasis mine]
>
>Note that mq_open doesn't return an int, but a special message queue type
>mqd_t for a reason. Again, if you use message queues with select, you're
>creating non-portable code.
>
>Having said that, it *would* be possible to change the implementation to
>make mqd_t a file descriptor and to support the Linux extension, but I'm
>not planning to do so for the time being.
>
>But, as always, patches are welcome.
>
>
>Corinna
>
>--
>Corinna Vinschen Please, send mails regarding Cygwin to
>Cygwin Maintainer cygwin AT cygwin DOT com
>Red Hat
>
>This mail has originated outside your organization, either from an external
>partner or the Global Internet.
>Keep this in mind if you answer this message.
>
Re: Possible chmod problem with a path
Greetings, Phil Smith! > The short description is that chmod *with a path* says it works, but > doesn't. If I cd to the directory and do it from there, it works. > This behavior *seems* to have started recently, after I installed gawk (and > in the process updated some other Cygwin bits). Our scaffolding for some > cross-platform builds uses Cygwin (and CMake), and I started having > permissions problems with the build artifacts on my machine. > I've tried with both forward and backslashes. In the examples below, the > path is longish, but I can reproduce it to C:\temp as well. A colleague with > an older Cygwin cannot reproduce it. Of course it's possible this is Windows > somehow having become confused, but it's hard to see how (but then, it's > Windows...OK, I'm looping). > I've read the FAQ and searched the archives as best I can -- there are lots > of hits for "chmod" and "path", of course. > Any suggestions (besides "reformat and reinstall Windows") welcome. > Environment: > Windows 7 Professional, fully patched, 64-bit, Genuine Intel. > uname -r 1.7.35(0.287/5/3) > Asterisked lines are my comments: > * OK, I'm in C:\SVN\zFPE610: > C:\SVN\zFPE610>cat ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1 > cat: ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1: Permission denied > * Let's chmod: > C:\SVN\zFPE610>chmod -v 777 C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/* > mode of 'C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/VSHPCRT1' changed > from 0644 (rw-r--r--) to 0777 (rwxrwxrwx) Please use Cygwin paths with Cygwin tools. Windows paths are not guaranteed to work with every Cygwin tool. > * Nope: > C:\SVN\zFPE610>cat ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1 > cat: ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1: Permission denied > * Let's look: > C:\SVN\zFPE610>ls -l ZFP-BUILD-2015-03-27-001/Updated/* > rwx---+ 1 phsiii None 6800 Mar 27 15:24 > ZFP-BUILD-2015-03-27-001/Updated/VSHPCRT1 > * That sneaky chmod lied! > * Let's go to the directory: > C:\SVN\zFPE610>cd C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/ > * Nope, as expected: > C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>cat VSHPCRT1 > cat: VSHPCRT1: Permission denied > * Now let's chmod again from there: > C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>chmod 777 * > * Hey, it works! > C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>cat VSHPCRT1 > ¦Q¦@@X¦¦^G¦¦b¦¦a¦¦aK¦¦@@@Ö¦¦¦@`¦¦@@¦8@@¦8@@ What you are doing may or may not work, depends, if you are using Cygwin or native Subversion client. In either case, it isn't very bright idea to enforce POSIX access mask outside Cygwin tree, unless you know what you are doing and absolutely need it. From your description, you don't need it at all. -- With best regards, Andrey Repin Monday, March 30, 2015 17:16:28 Sorry for my terrible english...
Re: Xorg server always starting up on DISPLAY 3.0
On 27/03/2015 15:48, Jim Reisert AD1C wrote: I'm running Cygwin/X server Version 1.17.1. For the last couple of weeks, it's always starting on DISPLAY 3.0: DISPLAY=:3.0 I can't figure out how to get it back to 0.0. There must be some piece of state somewhere that I can't find. You have stale lock files /tmp/.X0-lock etc. Unfortunately startx(|win) is not as smart as it should be about detecting that the process owning the lock file is no longer running. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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
Possible chmod problem with a path
The short description is that chmod *with a path* says it works, but doesn't. If I cd to the directory and do it from there, it works. This behavior *seems* to have started recently, after I installed gawk (and in the process updated some other Cygwin bits). Our scaffolding for some cross-platform builds uses Cygwin (and CMake), and I started having permissions problems with the build artifacts on my machine. I've tried with both forward and backslashes. In the examples below, the path is longish, but I can reproduce it to C:\temp as well. A colleague with an older Cygwin cannot reproduce it. Of course it's possible this is Windows somehow having become confused, but it's hard to see how (but then, it's Windows...OK, I'm looping). I've read the FAQ and searched the archives as best I can -- there are lots of hits for "chmod" and "path", of course. Any suggestions (besides "reformat and reinstall Windows") welcome. Environment: Windows 7 Professional, fully patched, 64-bit, Genuine Intel. uname -r 1.7.35(0.287/5/3) Asterisked lines are my comments: * OK, I'm in C:\SVN\zFPE610: C:\SVN\zFPE610>cat ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1 cat: ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1: Permission denied * Let's chmod: C:\SVN\zFPE610>chmod -v 777 C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/* mode of 'C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/VSHPCRT1' changed from 0644 (rw-r--r--) to 0777 (rwxrwxrwx) * Nope: C:\SVN\zFPE610>cat ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1 cat: ZFP-BUILD-2015-03-27-001\Updated\VSHPCRT1: Permission denied * Let's look: C:\SVN\zFPE610>ls -l ZFP-BUILD-2015-03-27-001/Updated/* rwx---+ 1 phsiii None 6800 Mar 27 15:24 ZFP-BUILD-2015-03-27-001/Updated/VSHPCRT1 * That sneaky chmod lied! * Let's go to the directory: C:\SVN\zFPE610>cd C:/SVN/zFPE610/ZFP-BUILD-2015-03-27-001/Updated/ * Nope, as expected: C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>cat VSHPCRT1 cat: VSHPCRT1: Permission denied * Now let's chmod again from there: C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>chmod 777 * * Hey, it works! C:\SVN\zFPE610\ZFP-BUILD-2015-03-27-001\Updated>cat VSHPCRT1 ¦Q¦@@X¦¦^G¦¦b¦¦a¦¦aK¦¦@@@Ö¦¦¦@`¦¦@@¦8@@¦8@@ -- 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: Input method in cygwin-x ?
On 27/03/2015 06:41, Arthur Tu wrote: I did some experiments with ibus. I have a linux machine with ibus installed. When using that machine natively, I can use ibus without any further configuration, except for ibus daemon startup. Applications like gnome-terminal, xfce4-terminal, emacs24, google-chrome and chromium work fine ibus. When I access that machine from another Windows computer with "ssh -Y machine" and start ibus daemon with "ibus-daemon&", the following behavior was obeserved. 1. ibus worked fine with gnome-terminal, xfce4-terminal and goolge-chrome. 2. ibus didn't work with xterm, emacs24 and chromium. Thanks for these details. I did a bit of experimentation with a Ubutunu 14.10 remote host ibus-daemon -drx export XMODIFIERS="@im=ibus" Gives me working ibus with xterm. I couldn't get emacs working with ibus even locally, and setting that up seems to be a bit obscure. Are you using ibus.el? Chromium just works for me. On Thu, Mar 26, 2015 at 11:38 PM, Jon TURNEY wrote: On 25/03/2015 06:44, Arthur Tu wrote: Is there a way to use input method in cygwin-x environment? For example, when I invoke emacs with " ssh -X remote-machine emacs "" I can't use either input methods in local windows machine or those in remote linux server. This is something that I want to work, but I'm afraid I have no experience using IMEs, so I'm not sure what needs doing, which is why the section [1] in the User's Guide is currently empty. I hope you can help me with identifying what that needs to say! I believe it should possible to start your IME (ibus, scim, etc.) in the remote sessions and have that work. Alternatively, there was some work done a while ago to provide a bridge between the native Windows IME and the server, which I believe allowed using the native Windows IME to input into X windows. If that is useful, I can probably bring that up to date. [1] http://x.cygwin.com/docs/ug/using-i18n.html#using-i18n-ime [2] https://www.cygwin.com/ml/cygwin-xfree/2005-01/msg00066.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: X11Forward and xauth problems
On 26/03/2015 22:06, Andrew DeFaria wrote: On 3/26/2015 12:12 PM, Jon TURNEY wrote: On 25/03/2015 17:40, Andrew DeFaria wrote: Prediction: This problem probably will end up having something to do with the permissions and file system that ~/.Xauthority resides on, which is, I believe, a NetApp. This file system is the file system for the Linux Home directories (Windows "home" directories are somewhere else). In an attempt to have a transparently workable environment I set my Cygwin home directory to access the same directory my Linux servers use for the home directory - this NetApp. If you need more information about that then let me know and perhaps tell me how I can get that. This seems very plausible. If I am understanding you correctly, ~/.Xauthority is the same file on the NetApp at both ends. I think perhaps that is somehow the cause of the problem. Yes. The sequence of actions is something like: - startx(|win) generates a random cookie and stores it in ~/.serverauth. and uses that file as the server -auth option - it also uses 'xauth add' to put that cookie into ~/.Xauthority for the display (e.g. :0) I'm not using startx - I just do C:\Cygwin\bin\XWin.exe -multiwindow -listen tcp Sorry, I don't think you had mentioned that before. It's even simpler then: - ssh looks for a cookie for $DISPLAY (e.g. :0) in ~/.Xauthority using 'xauth list', discovers there isn't one so makes one up and sends it to the far end (this what "Warning: No xauth data; using fake authentication data for X11 forwarding." is telling you) - sshd tries to store that cookie using xauth for the proxy display (e.g :10) Reading the source of xauth [1], it does try to lock the ~/.Xauthority file for up to 20 seconds before giving up, which perhaps corresponds to the delay you see? Sounds plausible. Is that configurable? Unfortunately, no. Possibly you could set XAuthLocation in ssh(|d)_config to a wrapper script which uses 'xauth -i' to ignore locks. Does 20 seconds actually match the length of the delay you see? However, the "unable to link authority file .Xauthority, use .Xauthority-n" message indicates that the working file .Xauthority-n cannot renamed as .Xauthority (xauth tries both to hard-link it as .Xauthority, and to rename it) After I ssh -X to this system I do see ~/.Xauthority and ~/.Xauthority-n. They are the same size but differ binarily. I can do mv ~/.Xauthority-n ~/.Xauthority without issue. Why can't sshd do that? Once I rename the file X clients work! From that machine... So the plot thickens... Why was mv denied permission when I can easily do it once I get a prompt? It kind of looks like perhaps there is some kind of delay in releasing the file lock? You might like to try running something like 'xauth -f ~/foo add :99 . `mcookie`' at both ends in rapid succession and see if that works or fails in the same way? Any idea why setting ForwardX11 yes and ForwardX11Trusted don't seem to work? I thought it was that setting ForwardX11 yes is equivalent to specifying -X and setting ForwardX11Trusted yes is equivalent to specifying -Y but they are not behaving that way! Adefaria-lt:echo "ForwardX11 yes" > ~/.ssh/config Adefaria-lt:ssh cm-db-ldev01 "echo DISPLAY = \'\$DISPLAY\'" Warning: untrusted X11 forwarding setup failed: xauth key data not generated Warning: No xauth data; using fake authentication data for X11 forwarding. X11 forwarding request failed on channel 0 This seems to be a separate question, but the first thing I would check is if is X11Forwarding permitted by the sshd_config on cm-db-ldev01? I find all of this behavior erratic and unreliable. Indeed. But I think that the erratic and unreliable thing is the networked file system, not ssh. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- 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: Handles returned by mq_open are not valid file descriptors as supposed to be under native linux distributions
On Mar 27 09:30, KEREP, Mladen wrote:
> We're using POSIX message queues to pass messages between processes.
> For this we've build a library layer to be able to use message queues
> on different platforms. Basically linux (debian, Ubuntu, archlinux,
> rasbian) is the development platform, but also vxworks platforms are
> supported.
>
> Several message queues are opened through mq_open calls and the
> returned handles are organized in file descriptor sets (fd_set). The
> set is then passed over to a select(2) call, which blocks processing
> and returns as soon as any message in any of the queues arrives.
>
> This works under linux, since the handles returned are valid file
> descriptors and the macros FD_ZERO / FD_SET are able to handle that
> handles.
>
> However, under Cygwin,
For a start, since what you're doing sounds pretty commercial to me,
may I point out https://cygwin.com/licensing.html? May I assume your
code is open source?
> mq_open does not directly return file handles,
> but pointers to (unknown) data structures in memory (ref.
> http://sourceware.org/ml/cygwin/2013-07/msg00179.html), which cannot
> be used with FD_ZERO, FD_SET, so not with select(2). I know from the
> man pages (mq_open): "Polling message queue descriptors On Linux, a
> message queue descriptor is actually a file descriptor, and can be
> monitored using select(2), poll(2), or epoll(7). This is not
> portable."
>
> mq_open() and select() conform to POSIX.1-2001, at least under linux,
> but also under Cygwin ? How can this be modified, so that it works
> under Cygwin as well ?
"This is not portable" is the important hint in the Linux man page. On
Cygwin we're using basically the implementation from W. Richard Stevens,
as published for his book "UNIX Network Programming, Volume 2,
Interprocess communication". It doesn't support the Linux extensions
but, yes, it's POSIX compliant, see POSIX.1-2008:
"A message queue descriptor *may* be implemented using a file descriptor,
in which case applications can open up to at least {OPEN_MAX} file and
message queues." [emphasis mine]
Note that mq_open doesn't return an int, but a special message queue type
mqd_t for a reason. Again, if you use message queues with select, you're
creating non-portable code.
Having said that, it *would* be possible to change the implementation to
make mqd_t a file descriptor and to support the Linux extension, but I'm
not planning to do so for the time being.
But, as always, patches are welcome.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpbAt36Rj19v.pgp
Description: PGP signature
Re: "cannot create hard link X to Y: Operation not permitted" on ext2fsd-mounted ext2 drive from cygwin cp -al
On Mar 26 08:53, Kevin Field wrote: > Hi everyone. > > This is a cross-post from SuperUser.com . If you're a StackExchange member > please feel free to answer it at > http://superuser.com/questions/894015/cannot-create-hard-link-x-to-y-operation-not-permitted-on-ext2-drive-from-cyg > > In one comment you'll see there, someone has proposed that cygwin will only > try NTFS hardlinks, even if the mounted drive is ext2 via ext2fsd. Maybe > someone here could confirm that, or if it's not true...help me find a > solution :) Thanks, -Kev > > --- > > /cygdrive/d/ is a USB hard disk formatted as ext2 and mounted with > [ext2fsd][1]. > > When I try `cp -al /cygdrive/d/X /cygdrive/d/Y` where X is a file, I get the > error in the title. > > Things I've Tried/Verified > --- > > I did `chmod -R 777 /cygdrive/d` but I still get the same result. > > I am running as local administrator, who is the owner of /cygdrive/d. > > X is a file, not a directory. > > Windows Server 2012 R2 running cygwin64 current as of today. > > It's ext2 because I can, for example, `touch > /cygdrive/d/filename_with_a_colon:in_it` and it works and I can see it with > `ls`. Not to mention, it says so in ext2fsd and the Windows Disk Manager. > > Ironically, the same syntax on an NTFS drive works fine and creates an NTFS > hardlink. > > I've also tried reformatting the drive as ext3, with the same results. I > *had* figured on ext2 being more likely to be fully supported on account of > it being older than ext3/4, but I guess it doesn't make a difference. > > The question > -- > > How can I create simple ext2 hardlinks with cygwin? Does ext2fsd support creating hardlinks? The reason I'm asking is that Cygwin does not create hardlinks out of the blue. It certainly doesn't communicate with a driver directly. It just calls the underlying system call NtSetInformationFile(FileLinkInformation). If that doesn't work, neither Cygwin nor any other Windows applications have a chance to create a hardlink. Alternatively, does the CMD.exe `mklink /h' call work? If so, ext2fsd requires another set of flags to create hardlinks than NTFS, apparently. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpOH4pCJWpWS.pgp Description: PGP signature
Re: With bad UTF-8, cygwin can create files it can't read
On Mar 25 14:34, Kyzer wrote: > Hello, > > I've found that if you use cygwin to create a file with badly-encoded > UTF-8, readdir() gives out an entry with a name that cygwin won't > subsequently accept. > > * create a file using filename with hex bytes F4 8F BF BF > * readdir() reports the filename as hex bytes E2 8E B3 ED BF BF > * attempting to open or unlink the filename E2 8E B3 ED BF BF fails > * attempting to open or unlink the filename F4 8F BF BF succeeds Thanks for the testcase. I'll have a look later this week (I hope). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpp5D2s5CD6N.pgp Description: PGP signature
Re: static vs. shared linking
On Mar 25 22:42, David Stacey wrote:
> On 25/03/2015 09:04, Corinna Vinschen wrote:
> > If you
> >install the cygwin-debuginfo package, addr2line returns something like this
> >as the call stack (non-required path components removed):
> >
> >[...]/cygwin/exceptions.cc:1247
> >[...]/cygwin/exceptions.cc:1501
> >[...]/cygwin/sigproc.cc:717
> >[...]/cygwin/signal.cc:252
> >[...]/cygwin/signal.cc:303
> >[...]/cygwin/signal.cc:313
> >[...]/cygwin/signal.cc:289
> >[...]/cygwin/signal.cc:375
>
> Thank you for your comments - they were really helpful. Yes, I should have
> specified '-g' on the command line - that was an omission on my part -
> sorry.
>
> I've never had much joy out of addr2line before, and I'm struggling to
> recreate what you've done. I've added '-g' to the command line, run 'go.sh'
> again. This generates a fresh stackdump file, and then I do:
>
> awk '/^[0-9]/{print $2}' shared_test.exe.stackdump | addr2line -f -e
> shared_test.exe
>
> but I just see question marks. Please could you show the exact lines you're
> using.
addr2line is a bit dumb and needs help. What I do is to cat the
stackdump file and look at the addresses. They usually show where
the stuff comes from:
$ gawk '/^0/{print $2}' mkgroup.exe.stackdump
7FFBDC82DDB6
001800FEC36
001800FE188
001800CF471
001800CF53D
0018007EAC1
00100402DE6
00180049411
00180046369
00180046180
00180049488
00100401351
00100401010
7FFBD9FE13D2
7FFBDC85EB64
The 7f addresses are from OS DLLs you can't read with addr2line.
0018xxx is the Cygwin DLL, 0010xxx is the application itself. Other
addresses are other DLLs. Just check the addresses against
/etc/rebase.db.x86_64.
Then call addr2line for each object file, e.g.:
$ addr2line -e /usr/bin/cygwin1.dll 001800FEC36 001800FE188 001800CF471
[...]/cygwin/passwd.cc:576
[...]/cygwin/passwd.cc:353
[...]/cygwin/grp.cc:413
$ addr2line -e /usr/bin/mkgroup.exe 00100401351 00100401010
/usr/src/debug/cygwin-1.7.35-1/winsup/cygwin/lib/cygwin_crt0.c:22
/usr/src/debug/cygwin-1.7.35-1/winsup/cygwin/crt0.c:34
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpzH6ixPFbL4.pgp
Description: PGP signature
