Re: Fatal error using flock
On Dec 3 18:25, Kyle R. wrote: > On Dec 2 16:52, Corinna Vinshen wrote: ^^^ oops > > Ouch. The handle in the parent got created non-inheritable. That's > > bad if the handle is utilized in subsequent child processes which rely > > on being able to access the handle. > > > > I applied a patch and created a new developer snapshot on > > https://cygwin.com/snapshots/ > > > > Please give it a try. > > Thanks Corinna, that works perfectly! Thanks for testing. And thanks again for providing an STC, that's very helpful. > On Dec 2 14:48, Corrina Vinshen wrote: ^^^ it's getting worse :) > > Pity. When I created the locking code I added lots and lots of comments > > in the hope that > > > > a) other people would have a chance to understand how the code is > > supposed to work and > > > > b) *I* have a chance to understand how the code is supposed to work > > after not looking at the code for a year or longer... > > I should mention that I'm only a grad student with more of a focus in > hardware and computer architecture than softare, so I don't have much > experience in Linux land yet. Give me a year or so on the job and I may > be able to understand and debug this kind of code. :) Sure, I'd be glad! Only... it's mostly Win32/NT, not Linux code at this eoint in the source ;) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp4apUrq9P6Q.pgp Description: PGP signature
Re: Cygwin AD integration home/shell changes
On Dec 3 16:44, Andrey Repin wrote: > Greetings, Corinna Vinschen! > > >> > Here's what you get: > >> > >> I finally realized, what was tingling me all this time. > >> The implicit fallback mechanics. I'd rather want to have explicit > >> declaration > >> and a failure message in case something isn't right. Much easier to fix > >> system > >> issues, when the system tell you about them. > > > The fallback mechanism is pretty much required to have a sane default > > which works for home users without having to change nsswitch.conf at > > all. Also, not everybody will want error messages rather than some sane > > fallback (for any given value of "sane"), while if you don't want a sane > > fallback, you can easily create an unsane fallback to help you maintain > > your solution, e.g. > > > db_home: cygwin /invalid/read-only-path > > Why not set defaults (in case of db_home) to > > db_home: cygwin desc /home/%U > > and remove fallback? > It just not seems right - creating workarounds to implement straight behavior. It's not a workaround from my POV to provide a fallback. Creating a workable passwd entry is important. If I implement it as you suggest above, I would still provide the typical "set home to the root dir" default. Sure, that might be an option. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpoh3AvWDGvU.pgp Description: PGP signature
Re: Instability with signals and threads
Mikulas, ping? On Nov 28 22:12, Corinna Vinschen wrote: > On Nov 21 15:43, Corinna Vinschen wrote: > > I'm going to take a step back for now, and reevaluate what happens > > before trying to apply even more hacks. Ultimately the problem is that > > the cygtls area is accessed from other threads (mainly the signal > > thread) without locking, and worse, that the lock for the cygtls area is > > a member of _cygtls itself. The latter needs certainly a patch, and I'm > > contemplating to extend cygheap::threadlist to become a per-thread > > structure containing the _cygtls pointer, the thread ID, the main thread > > HANDLE, and the tls muto. This should allow to serialize access to the > > cygtls area in a way which avoids the aforementioned problems without > > a complete redesign. > > I applied a patch which is supposed to fix this problem. Your STC > works for me and everything else I tried, including X and Emacs in X11 > GUI mode still work. > > Please try the latest snapshot from https://cygwin.com/snapshots/ > > I'm not expecting that my first cut works OOTB, so I'd be glad for > more testing. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpVKy_ADdDv9.pgp Description: PGP signature
Re: Fatal error using flock
On Dec 4 10:33, Corinna Vinschen wrote: > On Dec 3 18:25, Kyle R. wrote: > > On Dec 2 16:52, Corinna Vinshen wrote: >^^^ >oops > > > Ouch. The handle in the parent got created non-inheritable. That's > > > bad if the handle is utilized in subsequent child processes which rely > > > on being able to access the handle. > > > > > > I applied a patch and created a new developer snapshot on > > > https://cygwin.com/snapshots/ > > > > > > Please give it a try. > > > > Thanks Corinna, that works perfectly! > > Thanks for testing. And thanks again for providing an STC, that's > very helpful. > > > On Dec 2 14:48, Corrina Vinshen wrote: >^^^ >it's getting worse :) > > > Pity. When I created the locking code I added lots and lots of comments > > > in the hope that > > > > > > a) other people would have a chance to understand how the code is > > > supposed to work and > > > > > > b) *I* have a chance to understand how the code is supposed to work > > > after not looking at the code for a year or longer... > > > > I should mention that I'm only a grad student with more of a focus in > > hardware and computer architecture than softare, so I don't have much > > experience in Linux land yet. Give me a year or so on the job and I may > > be able to understand and debug this kind of code. :) > > Sure, I'd be glad! Only... it's mostly Win32/NT, not Linux code at this > eoint in the source ;) Weird typo. s/eoint/point/ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpGgBXCG_L8G.pgp Description: PGP signature
Re: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"
On Dec 3 18:07, Dave Lindbergh wrote: > On Wed, Dec 3, 2014 at 3:42 PM, Jason Pyeron wrote: > > [copy off list, because the sourceware system admins throws temper tantrums] > >> -Original Message- > >> From: Dave L > >> Sent: Wednesday, December 03, 2014 15:30 > >> > >> ...but the git from github.com works fine. > >> > >> I installed Cygwin's version of git, and get this: > >> > >> $ git clone https://github.com/nerdfever/pic32mx-bmf > >> Cloning into 'pic32mx-bmf'... > >> remote: Counting objects: 12, done. > >> remote: Total 12 (delta 0), reused 0 (delta 0) > >> error: failed to read delta-pack base object > >> 300bdeb2fd209d24afb865584da10b78aa8fefc4 > >> fatal: unpack-objects failed > > > > What file system are you on? Local NTFS or remote? > > Aha - you're right. > > It works fine on a local NTFS volume. > > I get the error when I do it on Z:, which is mapped to a network drive > (on another Windows box). It works fine for me on a network drive mounted from another Windows machine used via the cygdrive prefix: $ mount | grep cygdrive/z Z: on /cygdrive/z type ntfs (binary,posix=0,user,noumount,auto) $ cd /cygdrive/z $ git clone https://github.com/nerdfever/pic32mx-bmf Cloning into 'pic32mx-bmf'... remote: Counting objects: 12, done. remote: Total 12 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (12/12), done. Checking connectivity... done. I tried with two different mount points, one to a Cygwin-created remote dir, one to a Windows-created remote dir. > Is there a workaround? Why does this happen? No idea. How do you mount the drive, e.g., what does `mount' print for the drive? Or could this be a permission problem? If all else fails you could try to find out what happens via strace. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBuf7end31M.pgp Description: PGP signature
zsh newline issues
$uname -a CYGWIN_NT-6.1 host 1.7.33-2(0.280/5/3) 2014-11-13 15:47 x86_64 Cygwin $mintty --version mintty 1.2-beta1 (x86_64-pc-cygwin) (C) 2013 Andy Koppe License GPLv3+: GNU GPL version 3 or later There is no warranty, to the extent permitted by law. $zsh --version zsh 5.0.6 (x86_64-unknown-cygwin) experiencing strange issues with newline, which is not constantly being printed with carriage return. E.g. $cd ~ $mkdir foo $vim ^Z [1] + 4936 suspended vim $vim ^Z [1] + 4936 continued vim [1] + 4936 suspended vim $cd foo $vim ^Z [1] + 4936 continued vim (pwd : ~) [1] + 4936 suspended vim (pwd now: ~/foo) $vim :q [1] + 4936 continued vim (pwd : ~) (pwd now: ~/foo) This happens every time with jobs and sometimes with other programs, like python printing lines. First time I thought it's because of a multi-line prompt, but changing it to a single-line one did nothing. Next thing I tried was messing with PROMPT_SP and PROMPT_CR, but one does not simply mess with nopromptcr and nopromptsp. The list of options (kshoptionprint) is as follows: noaliases off allexport off noalwayslastpromptoff alwaystoend on noappendhistory off autocdon autocontinue off noautolistoff noautomenuoff autonamedirs on noautoparamkeys off noautoparamslash off autopushd on noautoremoveslash off autoresumeon nobadpattern off nobanghistoff nobareglobqualoff bashautolist off bashrematch off nobeepoff nobgnice on braceccl on bsdecho off nocaseglobon nocasematch off cbasesoff cdablevarson chasedots off chaselinksoff nocheckjobs on noclobber on combiningcharson completealiases off completeinwordon continueonerror off correct on correctalloff cprecedences off cshjunkiehistory off cshjunkieloopsoff cshjunkiequotes off cshnullcmdoff cshnullglob off nodebugbeforecmd off dvorakoff emacs off noequals off errexit off errreturn off noevallineno off noexecoff extendedglob on extendedhistory on noflowcontrol on forcefloatoff nofunctionargzero off nogloboff noglobalexportoff noglobalrcs off globassignoff globcomplete off globdots off globsubst off nohashcmdsoff nohashdirsoff hashexecutablesonly off nohashlistall off histallowclobber off nohistbeepoff histexpiredupsfirst on histfcntllock off histfindnodupson histignorealldups on histignoredupson histignorespace on histlexwords off histnofunctions off histnostore off histreduceblanks off nohistsavebycopy off histsavenodupson histsubstpattern off histverifyon nohup on ignorebraces off ignoreclosebraces off ignoreeof off incappendhistory on incappendhistorytime off interactive on interactivecomments off ksharrays off kshautoload off kshglob off kshoptionprinton kshtypesetoff kshzerosubscript off nolistambiguous off nolistbeepoff listpackedoff listrowsfirst off nolisttypes off localloopsoff localoptions off localpatterns off localtrapsoff login on longlistjobs on magicequalsubst off mailwarning off markdirs off menucomplete off monitor off nomultibyte off nomultifuncdefoff nomultios off nonomatch off nonotify off nullglob off numericglobsort off octalzeroes off overstrikeoff pathdirs on pathscriptoff pipefail off posixaliases off posixargzero off posixbuiltins off posixcd off posixidentifiers off posixjobs off posixstrings off posixtrapsoff printeightbit off printexitvalueoff privilegedoff promptbangoff nopromptcroff nopromptpercent off nopromptspoff promptsubst off pushdignoredups on pushdminusoff pushdsilent on pushdtohome on rcexpandparam off rcquotes on norcs off recexac
Re: RFC: 1.7.33 problem with user's home directory
Andrey Repin wrote: Greetings, cyg Simple! Don't forget that CMD will not create a second connection to a \\host\share if Cygwin already has one open. What do you mean by that? $ cd //somehost/someshare $ cmd /c start cmd cmd will complain about UNC paths and start in %WINDIR% instead. Try it the other way around. You'll get the same result. It has nothing to do with cygwin opening it first. It has to do with cmd not handling a "\\network\share" style address. MS was too lazy to deal with command.com's "1-CurDir / drive" scenario that is embedded in the Win32 interface. If you cd to //host/, //host isn't a drive letter. So what happens when the user uses an absolute path? "/tmp"... where is that /tmp? Ends up at the root of each drive, but on a UNC-based-net-connection? Undefined. So cmd.exe can't be used on a UNC-based path, only on DOS compatible (drive letter assummed) based-path. -- 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: pdfnup ignores ~/.pdfjam.conf
On 12/3/2014 6:01 PM, Paul wrote: I'm using pdfjam that comes with 64-bit cygwin's texlive-collection-binextra package, dated 29 May 2013. I have the following in my ~/.pdfjam.conf: paper='letterpaper' nup='1x2' landscape='landscape' frame='true' I invoke pdfjam using pdfnup filename.pdf and the messages show that the ~/.pdfjam.conf is being read, as are the switches therein. pdfjam: This is pdfjam version 2.08. pdfjam: Reading any site-wide or user-specific defaults... ## ## From /home/User.Name/.pdfjam.conf: ## paper='letterpaper' nup='1x2' landscape='landscape' frame='true' pdfjam: Effective call for this run of pdfjam: /bin/pdfjam --suffix nup --nup '2x1' --landscape -- filename.pdf - pdfjam: Calling pdflatex... pdfjam: Finished. Output was to '/home/User.Name/tmp/filename-nup.pdf'. The "Effective call" above shows that ~/.pdfjam.conf is being ignored, even though the switch settings are being read. The output confirms this. However, if I specify the switch settings in the pdfnup statement itself, they are accepted. I've never used pdfnup, but it's a shell script whose last line is exec pdfjam --suffix nup --nup 2x1 --landscape "$@" So it's explicitly supplying options that will override the settings in ~/.pdfjam.conf. This is consistent with the documentation for pdfnup. The latter doesn't mention ~/.pdfjam.conf; it says to supply command line options to override the defaults. Ken -- 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: RFC: 1.7.33 problem with user's home directory
On Dec 4 04:20, Linda Walsh wrote: > Andrey Repin wrote: > >Greetings, cyg Simple! > Don't forget that CMD will not create a second connection to a > \\host\share if Cygwin already has one open. > >>>What do you mean by that? > > > >>$ cd //somehost/someshare > >>$ cmd /c start cmd > > > >>cmd will complain about UNC paths and start in %WINDIR% instead. > > Try it the other way around. You'll get the same result. > > It has nothing to do with cygwin opening it first. It has > to do with cmd not handling a "\\network\share" style address. > > MS was too lazy to deal with command.com's "1-CurDir / drive" > scenario that is embedded in the Win32 interface. If you cd to > //host/, //host isn't a drive letter. It will get interesting with the new CMD from Windows 10. MSFT has a whole team now working on pulling CMD into the 21st century of CLIs. Allowing UNC paths as CWD is apparently on their radar, though the current latest CMD in the W10 preview is still missing this feature. > So what happens when the user uses an absolute path? "/tmp"... > where is that /tmp? Ends up at the root of each drive, but on > a UNC-based-net-connection? Undefined. So cmd.exe can't be used > on a UNC-based path, only on DOS compatible (drive letter > assummed) based-path. Allowing CMD as shell wouldn't change how Cygwin tools see the world. Yes, with current CMDs you won't be able to utilize network paths as CWD, among other restrictions. Still, evaluating "db_shell: windows" as using CMD, rather than being a no-op might hvae some value. I would never use it myself, but there may be some people, or, let's assume, special maintainance accounts, for which this might come in handy. Would it hurt to implement it, even only for symmetry with the other options? I'm not sure. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpaBNGOAmU47.pgp Description: PGP signature
Cipher Issue while Connecting from AIX
Hi All, I have an AIX machine which is trying to connect to an SSH server I’ve setup through Cygwin on a Win 2008 Server. The connection is unsuccessful due to unmatched key exchange algorithms. As far as I can tell, both the AIX machine and the Cygwin SSH server have at least a few SSH cipher algorithms in common. However, even setting a specific cipher on the AIX side (via "ssh -c cipher-type" command) does not work. Connection from any Linux server to the AIX and to the Cygwin SSH are successful. In addition, connecting from the Cygwin to the AIX is successful. I’d appreciate any help here. Please see below the output of “ssh -v windows-server” command on the AIX server: [aix-host] # ssh -v windows-server OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.6l 04 Nov 2003 debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Connecting to windows-server [windows-server-ip] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/identity type -1 debug1: identity file /home/user/.ssh/id_rsa type 1 debug1: identity file /home/user/.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7 debug1: match: OpenSSH_6.7 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-sha1 none debug1: kex: client->server aes128-ctr hmac-sha1 none no kex alg [aix-host] # Thanks. Yair Zaretski -- 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: RFC: 1.7.33 problem with user's home directory
On Nov 26 21:56, Corinna Vinschen wrote: > On Nov 11 12:14, Corinna Vinschen wrote: > > On Nov 11 11:05, Achim Gratz wrote: > > > Corinna Vinschen cygwin.com> writes: > > > > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of > > > > the above: > > > > > > > > home: [unix|win|home]... > > > > > > > >- "unix" means, set pw_dir to unixHomeDirectory > > > >- "win" means, set pw_dir to homeDirectory > > > >- "home" means, set pw_dir to /home/$USER > > > >- Multiple entries are possible. > > > >- Default in the absence of this setting is: always set pw_dir to > > > > /home/$USER. > > > > > > Looks good, but maybe allow the AD attribute to be explicitly named (e.g. > > > cygwinHomeDirectory). > > > > Cygwin schema extension? :) > > I just created a patch and a matching snapshot on > https://cygwin.com/snapshots/ > > The new stuff is still missing documentation, [...] If you're wondering why I didn't create a test release yet, it's all about this dreaded documentation. Did I mention already how much I hate writing documentation? Yes? Whatever. I really hate writing documentation! It's infinitely worse than writing the code. I'm just working on the documentation and it's going forward really tenaciously, so I felt the need to vent^Wkeep you informed. When I have a more or less working piece of documentation, I'll create a new Cygwin test release again, for installation via setup. I'd appreciate if those not shy to install developer snapshots would give this stuff a try in the meantime. Also, if you don't understand the settings, or some of the settings, feel free to ask. The developer (that's me, I guess) sometimes just doesn't know if the description makes sense or not. It will very likely help to make the documentation better. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp3EaFZunbc2.pgp Description: PGP signature
Re: pdfnup ignores ~/.pdfjam.conf
Ken Brown cornell.edu> writes: |On 12/3/2014 6:01 PM, Paul wrote: |> I'm using pdfjam that comes with 64-bit cygwin's |> texlive-collection-binextra package, dated 29 May 2013. I have the |> following in my ~/.pdfjam.conf: |> |> paper='letterpaper' |> nup='1x2' |> landscape='landscape' |> frame='true' |> |> I invoke pdfjam using |> |> pdfnup filename.pdf |> |> and the messages show that the ~/.pdfjam.conf is being read, as are |> the switches therein. <...snip...> |> The "Effective call" above shows that ~/.pdfjam.conf is being |> ignored, even though the switch settings are being read. The |> output confirms this. However, if I specify the switch settings in |> the pdfnup statement itself, they are accepted. | | I've never used pdfnup, but it's a shell script whose last line is | |exec pdfjam --suffix nup --nup 2x1 --landscape "$ " | | So it's explicitly supplying options that will override the settings | in ~/.pdfjam.conf. This is consistent with the documentation for | pdfnup. The latter doesn't mention ~/.pdfjam.conf; it says to | supply command line options to override the defaults. Shucks. Thanks for sleuthing that out. Looks like I'll have to create my own variation of the script. Or just create an alias for pdfnup. -- 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
[ANNOUNCEMENT] Updated: w32api-headers 3.3.0-2
Now released for both 32bit and 64bit Cygwin: w32api-headers-3.3.0-2 Notable changes: * userenv.h (CreateProfile): backport prototype from master. * lmaccess.h (USER_INFO_24): backport struct declaration from master. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. signature.asc Description: OpenPGP digital signature
Re: pdfnup ignores ~/.pdfjam.conf
Paul gmail.com> writes: |Ken Brown cornell.edu> writes: |> |> I've never used pdfnup, but it's a shell script whose last line is |> |>exec pdfjam --suffix nup --nup 2x1 --landscape "$ " |> |> So it's explicitly supplying options that will override the settings |> in ~/.pdfjam.conf. This is consistent with the documentation for |> pdfnup. The latter doesn't mention ~/.pdfjam.conf; it says to |> supply command line options to override the defaults. | | Shucks. Thanks for sleuthing that out. Looks like I'll have to | create my own variation of the script. Or just create an alias for | pdfnup. Or just directly invoke pdfjam (what was I thinking). -- 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: Ctrl-C does not work from Cygwin for the java program
Warren Young writes: > On Dec 3, 2014, at 2:12 PM, Michelle Ma wrote: > >> If I type Ctrl-C from the windows command prompt, the "Ouput" line got >> called. However, if I type Ctrl-c from the Cygwin, the "Output" line >> didn't get called. > > I assume you are trying this from the default MinTTY shell. What happens if > you run it under cmd.exe instead? > > That is: > > c:\> cd cygwin > c:\cygwin> cygwin > $ java /path/to/my/program/pgm.jar > > This may be the old native EXE console compatibility problem. (Same > reason native ftp.exe doesn’t work right under Cygwin.) I tried to > find a FAQ entry for it, but there doesn’t seem to be one. I tried it under cmd.exe. Doesn't give me output 1 out of 4 or 5 times 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: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"
>> It works fine on a local NTFS volume. >> >> I get the error when I do it on Z:, which is mapped to a network drive >> (on another Windows box). > >It works fine for me on a network drive mounted from another Windows >machine used via the cygdrive prefix: >[..] >I tried with two different mount points, one to a Cygwin-created remote >dir, one to a Windows-created remote dir. > >> Is there a workaround? Why does this happen? > >No idea. How do you mount the drive, e.g., what does `mount' print for >the drive? Or could this be a permission problem? If all else fails >you could try to find out what happens via strace. Mount gives: Z: on /cygdrive/z type ntfs (binary,posix=0,user,noumount,auto) It's an ordinary LAN share on another local Windows box, mapped to drive Z: via "Map network drive" in Explorer (Win7). I have full permissions. You are more than welcome to read the strace output if that'll give you a clue (it doesn't give me one). All 1.7 MBytes of it are at http://nerdfever.com/files/strace.txt (That comes from "strace git clone https://github.com/nerdfever/pic32mx-bmf >strace.txt") I'm still stumped. -- 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
advice about setting up the eigen library for use with cygwin g++
Hello, As stated, I am writing a few tools with cygwin g++. These tools will make use of the eigen library for some linear algebra (PCA and matrix manipulations). I have never built with a library that was not installed through the cygwin package manager, so I thought I would ask if there was anything I needed to be aware of. Eigen is a header only kind of thing, so my understanding is that all I need to do is to unpack the src somewhere add the location to the include path. I was thinking of putting Eigen in, /cygdrive/c/cygwin/lib/eigen/ and using, g++ -I /cygdrive/c/cygwin/lib/eigen/ Does anyone see any issue with this approach? Will there be a problem having a non-cygwin directory in cygwin/lib, meaning something the cygwin install isn't formally aware of? Is there a preferred method for setting up something like this? Thanks LMH -- 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: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"
On Thu, Dec 04, 2014 at 04:27:51PM -0500, Dave Lindbergh wrote: > You are more than welcome to read the strace output if that'll give > you a clue (it doesn't give me one). All 1.7 MBytes of it are at > http://nerdfever.com/files/strace.txt > > (That comes from "strace git clone > https://github.com/nerdfever/pic32mx-bmf >strace.txt") > > I'm still stumped. Okay, I'm looking through this trace in the hope of finding something. The below looks suspicious, but I'm not sufficiently familiar with either Git or Cygwin internals to know (a) whether this is a problem at all or (b) if it is a problem, whether it's a symptom of an earlier problem I haven't spotted on my brief skim. 616 12330609 [main] git 2348 unlink_nt: Trying to delete \??\Z:\pic32mx-bmf\.git\objects\30, isdir = 1 3190 12333799 [main] git 2348 unlink_nt: Setting delete disposition on \??\Z:\pic32mx-bmf\.git\objects\30 failed, status = 0xC101 6362 12340161 [main] git 2348 unlink_nt: Try-to-bin \??\Z:\pic32mx-bmf\.git\objects\30 24341 12364502 [main] git 2348 try_to_bin: \??\Z:\pic32mx-bmf\.git\objects\30, return bin_status 3 645 12365147 [main] git 2348 unlink_nt: Try \??\Z:\pic32mx-bmf\.git\objects\30 again 12250 12377397 [main] git 2348 unlink_nt: Setting delete disposition on \??\Z:\pic32mx-bmf\.git\objects\30 failed, status = 0xC101 22680 12400077 [main] git 2348 unlink_nt: Try \??\Z:\pic32mx-bmf\.git\objects\30 again 8487 12408564 [main] git 2348 unlink_nt: Setting delete disposition on \??\Z:\pic32mx-bmf\.git\objects\30 failed, status = 0xC101 1903 12410467 [main] git 2348 unlink_nt: Try \??\Z:\pic32mx-bmf\.git\objects\30 again I'm also curious about the difference between the MinGW32 version and the Cygwin version. Possibly it's barking up completely the wrong tree, but what versions of each are you running? In the hunt for a simple test case, is it just this repository that's causing problems, or are others being difficult too? Specifically, I'm wondering about a trivial repository with only a handful of objects. Do you know anything about that 300bdeb object? In particular, is it particularly big or unusual in some other way? -- 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: advice about setting up the eigen library for use with cygwin g++
Eliot Moss wrote: > On 12/4/2014 4:43 PM, LMH wrote: >> Hello, >> >> As stated, I am writing a few tools with cygwin g++. These tools will >> make use of the eigen library for some linear algebra (PCA and matrix >> manipulations). I have never built with a library that was not installed >> through the cygwin package manager, so I thought I would ask if there >> was anything I needed to be aware of. >> >> Eigen is a header only kind of thing, so my understanding is that all I >> need to do is to unpack the src somewhere add the location to the >> include path. >> >> I was thinking of putting Eigen in, >> >> /cygdrive/c/cygwin/lib/eigen/ >> >> and using, >> >> g++ -I /cygdrive/c/cygwin/lib/eigen/ >> >> Does anyone see any issue with this approach? Will there be a problem >> having a non-cygwin directory in cygwin/lib, meaning something the >> cygwin install isn't formally aware of? Is there a preferred method for >> setting up something like this? > > I'm not sure what you mean about a "header only kind of thing". > Unless already provided in a format built for cygwin, libraries > have to be recompiled and relinked for use on cygwin, even if > all your app does is include a header file and then link with > the library. Put another way, cygwin is not a Unix virtual > machine like say, Virtual Box or VMWare. It is a library that > translates Unix-like calls into Windows calls, and things have > to be built specifically to work with it. > > SO I think you need to build and install the library, and then > build your application using the header files. > > Regards -- Eliot Moss > Thanks for the reply. > I'm not sure what you mean about a "header only kind of thing". I guess my understanding of eigen is that it not a library that is linked to and then accessed dynamically at runtime but rather is an archive of cpp src code and header files. You use it by including the header files for the functions you need and the linker bundles the code specified in the header files into your application. This works no differently than the other src and header files for your program. There is no config or make files included with eigen with which to configure, build, or compile anything. >From the Eigen site, "How to "install" Eigen? In order to use Eigen, you just need to download and extract Eigen's source code (see the wiki for download instructions). In fact, the header files in the Eigen sub directory are the only files required to compile programs using Eigen. The header files are the same for all platforms. It is not necessary to use CMake or install anything." "There is no library to link to. The only thing that you need to keep in mind when compiling is that the compiler must be able to find the Eigen header files. The directory in which you placed Eigen's source code must be in the include path. With GCC you use the -I option to achieve this." I wouldn't have posted this question if I was at all clear on how this is supposed to work, so the above is just my current understanding. It may be entirely incorrect. Do you think I am misunderstanding how this is supposed to work? LMH -- 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: advice about setting up the eigen library for use with cygwin g++
On 2014-12-04 15:43, LMH wrote: As stated, I am writing a few tools with cygwin g++. These tools will make use of the eigen library for some linear algebra (PCA and matrix manipulations). I have never built with a library that was not installed through the cygwin package manager, so I thought I would ask if there was anything I needed to be aware of. eigen2 and eigen3 are both available in Ports. You can see how they are built in Ports git: https://sourceforge.net/p/cygwin-ports/eigen2/ci/master/tree/ https://sourceforge.net/p/cygwin-ports/eigen3/ci/master/tree/ -- 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: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"
Greetings, Dave Lindbergh! >> [copy off list, because the sourceware system admins throws temper tantrums] >>> -Original Message- >>> From: Dave L >>> Sent: Wednesday, December 03, 2014 15:30 >>> >>> ...but the git from github.com works fine. >>> >>> I installed Cygwin's version of git, and get this: >>> >>> $ git clone https://github.com/nerdfever/pic32mx-bmf >>> Cloning into 'pic32mx-bmf'... >>> remote: Counting objects: 12, done. >>> remote: Total 12 (delta 0), reused 0 (delta 0) >>> error: failed to read delta-pack base object >>> 300bdeb2fd209d24afb865584da10b78aa8fefc4 >>> fatal: unpack-objects failed >> >> What file system are you on? Local NTFS or remote? > Aha - you're right. > It works fine on a local NTFS volume. > I get the error when I do it on Z:, which is mapped to a network drive > (on another Windows box). > Is there a workaround? Why does this happen? Is this Z: drive on a machine in the same domain? -- WBR, Andrey Repin (anrdae...@yandex.ru) 05.12.2014, <07:58> 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: Cygwin AD integration home/shell changes
Greetings, Corinna Vinschen! >> >> > Here's what you get: >> >> >> >> I finally realized, what was tingling me all this time. >> >> The implicit fallback mechanics. I'd rather want to have explicit >> >> declaration >> >> and a failure message in case something isn't right. Much easier to fix >> >> system >> >> issues, when the system tell you about them. >> >> > The fallback mechanism is pretty much required to have a sane default >> > which works for home users without having to change nsswitch.conf at >> > all. Also, not everybody will want error messages rather than some sane >> > fallback (for any given value of "sane"), while if you don't want a sane >> > fallback, you can easily create an unsane fallback to help you maintain >> > your solution, e.g. >> >> > db_home: cygwin /invalid/read-only-path >> >> Why not set defaults (in case of db_home) to >> >> db_home: cygwin desc /home/%U >> >> and remove fallback? >> It just not seems right - creating workarounds to implement straight >> behavior. > It's not a workaround from my POV to provide a fallback. Creating a > workable passwd entry is important. If I implement it as you suggest > above, I would still provide the typical "set home to the root dir" > default. Sure, that might be an option. If you mean "complain and set home to the root", then I'm happy with this solution. -- WBR, Andrey Repin (anrdae...@yandex.ru) 05.12.2014, <08:06> 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: RFC: 1.7.33 problem with user's home directory
Greetings, Corinna Vinschen! >> On Nov 11 12:14, Corinna Vinschen wrote: >> > On Nov 11 11:05, Achim Gratz wrote: >> > > Corinna Vinschen cygwin.com> writes: >> > > > 1. Add a setting to /etc/nsswitch.conf which allows to specify one of >> > > > the above: >> > > > >> > > > home: [unix|win|home]... >> > > > >> > > >- "unix" means, set pw_dir to unixHomeDirectory >> > > >- "win" means, set pw_dir to homeDirectory >> > > >- "home" means, set pw_dir to /home/$USER >> > > >- Multiple entries are possible. >> > > >- Default in the absence of this setting is: always set pw_dir to >> > > > /home/$USER. >> > > >> > > Looks good, but maybe allow the AD attribute to be explicitly named (e.g. >> > > cygwinHomeDirectory). >> > >> > Cygwin schema extension? :) >> >> I just created a patch and a matching snapshot on >> https://cygwin.com/snapshots/ >> >> The new stuff is still missing documentation, [...] > If you're wondering why I didn't create a test release yet, it's all > about this dreaded documentation. > Did I mention already how much I hate writing documentation? Yes? > Whatever. I really hate writing documentation! It's infinitely worse > than writing the code. Every 10 lines of documentation I write for my projects make me want to rewrite at least one line of the code. Because it feels stupid now, that I've explained, how it works. > I'm just working on the documentation and it's going forward really > tenaciously, so I felt the need to vent^Wkeep you informed. > When I have a more or less working piece of documentation, I'll create > a new Cygwin test release again, for installation via setup. > I'd appreciate if those not shy to install developer snapshots would > give this stuff a try in the meantime. I think I'm about to make a script to install snapshots, at this rate it seems the right thing to do. Is there a direct way to query for the latest snapshot? I'm not very fond of HTML parsing. > Also, if you don't understand the settings, or some of the settings, > feel free to ask. The developer (that's me, I guess) sometimes just > doesn't know if the description makes sense or not. It will very likely > help to make the documentation better. -- WBR, Andrey Repin (anrdae...@yandex.ru) 05.12.2014, <08:16> 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
