Re: subversion 1.7.10-1 failure: CRYPTO_memcmp entry point not found in cygcrypto-1.0.0.dll
Hi Pascal, On Wed, Jun 19, 2013 at 1:51 AM, Yaakov (Cygwin/X) wrote: > > > First, be sure to exit ALL Cygwin processes, including services. (Failure to > do so is what causes these installation hiccups in the first place.) The easiest way I found for this is to install Process Explorer from http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx Run it, and search for cygwin Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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 MSYS functionality to Cygwin
I want point all who read this ML to mingw-w64 ML discussion about MSYS: http://sourceforge.net/mailarchive/message.php?msg_id=31008339 Also I want to say that all changes that I do in Cygwin DLL (except symlink-copy) do not break any Cygwin stuff and only applied to non-cygwin applications. For Cygwin applications doesn't changed anything. 1. OSNAME By default is Cygwin, but if you want - you can change it. 2. Paths translating - only for Win32 applications. 3. Symlink-to-copy I think can be implementing for stupid or crazy (what you want) guys as me by something like CYGWIN=symlinks:wincompat. Regards, Alexey. -- 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 MSYS functionality to Cygwin
On Jun 18 22:03, Christopher Faylor wrote: > On Tue, Jun 18, 2013 at 03:24:52PM -0600, Warren Young wrote: > >On 6/18/2013 13:31, Christopher Faylor wrote: > >> On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote: > 3. In MSYS mode Cygwin need to be very portable > >>> > >>> It would indeed be nice to have a portable Cygwin. That is, one that > >>> could be run from a copied directory or USB key, without being formally > >>> installed. Such a thing would need to solve the 3PP problem, though, > >>> which is Hard (tm). > >> > >> Why wouldn't that work now? You can copy cygwin1.dll anywhere you want. > > > >Because FAQ item 4.19, and because 3PP. > > The FAQ is out-of-date. Multiple Cygwin copies should coexist peacefully > these days although it still is something that we wouldn't necessarily > advocate for a novice user. I'll rewrite that FAQ. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated Git build
Git 1.7.10 is now over one year old http://github.com/git/git/tree/v1.7.10 and it contains some significant improvements, such as git clone --single-branch http://stackoverflow.com/a/9920956 Not to mention version 1.8.0 has been out for almost 8 months. I would he happy to make the build, or help with the process if we can just get the ball rolling. -- 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 MSYS functionality to Cygwin
On Jun 19 10:15, Corinna Vinschen wrote: > On Jun 18 22:03, Christopher Faylor wrote: > > On Tue, Jun 18, 2013 at 03:24:52PM -0600, Warren Young wrote: > > >On 6/18/2013 13:31, Christopher Faylor wrote: > > >> On Tue, Jun 18, 2013 at 01:10:06PM -0600, Warren Young wrote: > > 3. In MSYS mode Cygwin need to be very portable > > >>> > > >>> It would indeed be nice to have a portable Cygwin. That is, one that > > >>> could be run from a copied directory or USB key, without being formally > > >>> installed. Such a thing would need to solve the 3PP problem, though, > > >>> which is Hard (tm). > > >> > > >> Why wouldn't that work now? You can copy cygwin1.dll anywhere you want. > > > > > >Because FAQ item 4.19, and because 3PP. > > > > The FAQ is out-of-date. Multiple Cygwin copies should coexist peacefully > > these days although it still is something that we wouldn't necessarily > > advocate for a novice user. > > I'll rewrite that FAQ. Done. Please have a look: http://cygwin.com/faq.html#faq.using.multiple-copies http://cygwin.com/faq.html#faq.using.third-party.multiple-copies Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Updated Git build
Steven Penny wrote: > Git 1.7.10 is now over one year old > > http://github.com/git/git/tree/v1.7.10 > > and it contains some significant improvements, such as > > git clone --single-branch > > http://stackoverflow.com/a/9920956 > > Not to mention version 1.8.0 has been out for almost 8 months. I would he > happy > to make the build, or help with the process if we can just get the ball > rolling. I posted on this topic yesterday. I'm currently using a home-built v1.8.3.1 Git with no immediate issues other than not being able to compile with pthreads support and some obscure failing test cases. I see Cygwin Ports[0] appears to be offering a compiled v1.8.3 version of Git[1], and Yaakov has already suggested moving some of the patches made there into the main Cygwin package build[2]. I'm not sure who the current maintainer is, or how to find out, but my current plan is to wait a week or so to see if there's any reason for not upgrading (other than the current maintainer's time). If that gets nowhere, I'll offer to package up the latest version of Git myself. [0]: http://sourceware.org/cygwinports/ [1]: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/git;a=summary [2]: http://cygwin.com/ml/cygwin/2013-06/msg00474.html -- Adam Dinwoodie Messages posted to this list are made in a personal capacity. -- 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: Updated Git build
Adam Dinwoodie metaswitch.com> writes: > Git with no immediate issues other than not being able > to compile with pthreads support and some obscure failing > test cases. You might want to try pthreads again when gcc-4.7.3 is out. > I'm not sure who the current maintainer is, The Cygwin git maintainer is Eric Blake > or how to find out, $ cat /usr/share/doc/Cygwin/git.README ... or look up the announcement for the latest release? Regards, Achim. -- 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: Updated Git build
2013/6/19 Adam Dinwoodie: > I'm not sure who the current maintainer is, or how to find out, This is the list of all packages and their maintainers. http://cygwin.com/cygwin-pkg-maint Not sure where to find a link to this on the cygwin site though. Regards, Frank -- 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 MSYS functionality to Cygwin
On Jun 19 10:53, Алексей Павлов wrote:
> Today I investigate in this direction and find that logic works well
> except one line in spawn.cc that I think can be fixed without break
> anything.
>
> Index: cygwin/spawn.cc
> ===
> RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v
> retrieving revision 1.345
> diff -u -p -r1.345 spawn.cc
> --- cygwin/spawn.cc 3 May 2013 19:39:01 - 1.345
> +++ cygwin/spawn.cc 19 Jun 2013 05:53:36 -
> @@ -406,7 +406,7 @@ child_info_spawn::worker (const char *pr
> }
> else
> {
> - if (wascygexec)
> + if (real_path.iscygexec ())
Line 374:
wascygexec = real_path.iscygexec ();
Do you have an example why your change should make a difference?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Adding MSYS functionality to Cygwin
2013/6/19 Corinna Vinschen :
> On Jun 19 10:53, Алексей Павлов wrote:
>> Today I investigate in this direction and find that logic works well
>> except one line in spawn.cc that I think can be fixed without break
>> anything.
>>
>> Index: cygwin/spawn.cc
>> ===
>> RCS file: /cvs/src/src/winsup/cygwin/spawn.cc,v
>> retrieving revision 1.345
>> diff -u -p -r1.345 spawn.cc
>> --- cygwin/spawn.cc 3 May 2013 19:39:01 - 1.345
>> +++ cygwin/spawn.cc 19 Jun 2013 05:53:36 -
>> @@ -406,7 +406,7 @@ child_info_spawn::worker (const char *pr
>> }
>> else
>> {
>> - if (wascygexec)
>> + if (real_path.iscygexec ())
>
> Line 374:
>
> wascygexec = real_path.iscygexec ();
>
> Do you have an example why your change should make a difference?
>
My opinion is next:
wascygexec is initialized before calling av::fixup that determine is
executable depends on Cygwin1.dll and always (for me) is 0. But in
av::fixup real_path.iscygexec () can be changed.
And code always go to condition with one_line.fromargv.
Regards, Alexey.
--
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
magic failure
Surprised that this didn't work: $ ls -ld /usr/bin/gcc-? ls: cannot access /usr/bin/gcc-?: No such file or directory $ while the following did: $ ls -ld /usr/bin/gcc-?.exe -rwxr-xr-x 2 knellis Domain Users 94741 Feb 25 2009 /usr/bin/gcc-3.exe -rwxr-xr-x 3 knellis Domain Users 231438 Oct 26 2011 /usr/bin/gcc-4.exe $ Not a biggie. I can cope. --Ken Nellis -- 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: magic failure
I believe the correct syntax is: $ ls -ld /usr/bin/gcc-* On 6/19/2013 9:01 AM, Nellis, Kenneth wrote: > Surprised that this didn't work: > > $ ls -ld /usr/bin/gcc-? > ls: cannot access /usr/bin/gcc-?: No such file or directory > $ > > while the following did: > > > $ ls -ld /usr/bin/gcc-?.exe > -rwxr-xr-x 2 knellis Domain Users 94741 Feb 25 2009 /usr/bin/gcc-3.exe > -rwxr-xr-x 3 knellis Domain Users 231438 Oct 26 2011 /usr/bin/gcc-4.exe > $ > > Not a biggie. I can cope. > > --Ken Nellis > > -- > 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 > > > -- 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 MSYS functionality to Cygwin
On 6/18/2013 6:04 PM, Warren Young wrote: It would be possible, though somewhat evil, for Cygwin's exec() implementation to peek at the DLL dependency list of a program before starting it, and from that infer whether it should automatically translate paths. The I/O hit this would cause would be nontrivial. Keep in mind that one of the core ideas behind Unix is that fork() is cheap, and exec() is even cheaper. This deeply affects how software native to Unixy systems gets designed. As a result, Cygwin already has a problem with its slow fork() implementation; this idea makes exec() expensive, too, with predictable consequences to overall system speed. I don't see how Cygwin couldn't afford to behave this way by default. Maybe as an option? This is what MSYS-1 does. If the executable depends on the msys dll, then no path translation is done. If the executable does NOT depend on the msys dll, then path translation heuristics are employed. The speed hit of this check is relatively insignificant, all things considered. The biggest bugaboo is that "heuristic" == "a guess that is sometimes wrong". MSYS handles things like scanning argv[] for stuff like -I/unixy/path and -L/unixy/path (also, I think, --some-opt=/unixy/path), in addition to standalong args that look like paths. That stuff is slow...and often erroneous (e.g. in "dumpbin.exe /symbols", '/symbols' is an option, not a path...) So there are workarounds: bash-3.1$ dumpbin /symbols Microsoft (R) COFF/PE Dumper Version 10.00.40219.01 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file C:/MinGW/msys/1.0/symbols LINK : fatal error LNK1181: cannot open input file 'C:/MinGW/msys/1.0/symbols' Using multiple leading '/' disables path translation (*): bash-3.1$ dumpbin //symbols Microsoft (R) COFF/PE Dumper Version 10.00.40219.01 Copyright (C) Microsoft Corporation. All rights reserved. Summary (*) except that there are ADDITIONAL heuristics to determine if the argument is actually a UNC path, which SHOULD start with 2 / !! http://www.mingw.org/wiki/Posix_path_conversion This is not a simple task. 2. Translating paths in arguments and environment variables to Windows I just re-read this, and realized the implications of "and environment variables." You're proposing some kind of global search-and-replace operation, which will inevitably turn into a Whac-a-Mole game. (http://goo.gl/vpYfA) Yes, yes it is. Welcome to MSYS. notepad /home/user/mydoc.txt From my explanation above, you do see how expensive it would be for Cygwin to implement your desired behavior, right? Also when you using autoconf utilities generated Makefile has Cygwin paths and you cannot use it with native compiler. Those on the Automake list have wrestled with this off and on. It's more or less impossible to solve, which is why competing systems like CMake, SCons and Bakefile were created. And why msys's make.exe exists. It understands the "cygwin" paths in the Makefile, but when it launches (the native win32 "mingw" compiler) gcc.exe via the MSYS fork()/exec() codepath, all of the above heuristics come into play and (win32)gcc.exe gets all the wonderful X:/dos/style paths it likes. OR so goes the idea. I think the best you can hope for is that if you run ./configure under Cygwin with CC=i686-pc-mingw32-gcc and such, it creates a Makefile that works with Cygwin make, which calls out to the MinGW cross-compiler. Since the cross-compiler is a Cygwin app, not a native executable, it understands POSIX paths yet still builds native Windows executables. Or, you could say "./configure CC=mingw32-gcc" and depend on my proposed answer to your point #1. 4. Ability to change OSNAME that controlled by uname function in Cygwin DLL. What's wrong with using the MinGW cross-compiler from the Cygwin package repository instead? Not all packages are cross-compiler-compatible. Arguably and ideally, THAT is what should be fixed, but we don't live in an ideal world. Here's something for you to try on your own system: $ cd /bin $ mv ln.exe sane-ln.exe $ ln -s cp.exe ln.exe Or if you're feeling really ambitious, do it at the cygwin1.dll level, by changing its implementations of link(2) and symlink(2) to recursive copy operations. You have the source. This is what MSYS-1 does. If the resulting system works well at all, it will be much slower. It is. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Adding MSYS functionality to Cygwin
On 6/18/2013 10:05 PM, Christopher Faylor wrote: Let me state it again: Corinna and I have been having private discussion about this and are open to talking about the possibility of adding MSYS capability to Cygwin. I'm advocating adding hooks to the DLL which would accomplish that. Wow, that's VERY interesting. Thanks for clarifying your stance. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Where is getclip?
Where's getclip.exe gone? I still see it in cygutils-1.4.12-1.tar.bz2 while cygutils-1.4.12-2.tar.bz2 is fairly empty: $ tar tvf /c/MyStuff/NCygwinDist/http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f/release/cygutils/cygutils-1.4.12-2.tar.bz2 -rwxr-xr-x cwilson/Users 15901 2013-06-07 04:40 usr/bin/cygstart.exe -rwxr-xr-x cwilson/Users 27165 2013-06-07 04:40 usr/bin/mkshortcut.exe -rwxr-xr-x cwilson/Users 24605 2013-06-07 04:40 usr/bin/readshortcut.exe -rw-r--r-- cwilson/Users 1674 2013-06-07 04:40 usr/share/man/man1/cygstart.1.gz -rw-r--r-- cwilson/Users 2006 2013-06-07 04:40 usr/share/man/man1/mkshortcut.1.gz -rw-r--r-- cwilson/Users 1402 2013-06-07 04:40 usr/share/man/man1/readshortcut.1.gz Is that intended? Thanks, Michael -- 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: Where is getclip?
On 6/19/2013 9:59 AM, Lemke, Michael SZ/HZA-ZSW wrote: Where's getclip.exe gone? I still see it in cygutils-1.4.12-1.tar.bz2 while cygutils-1.4.12-2.tar.bz2 is fairly empty: $ tar tvf /c/MyStuff/NCygwinDist/http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f/release/cygutils/cygutils-1.4.12-2.tar.bz2 -rwxr-xr-x cwilson/Users 15901 2013-06-07 04:40 usr/bin/cygstart.exe -rwxr-xr-x cwilson/Users 27165 2013-06-07 04:40 usr/bin/mkshortcut.exe -rwxr-xr-x cwilson/Users 24605 2013-06-07 04:40 usr/bin/readshortcut.exe -rw-r--r-- cwilson/Users 1674 2013-06-07 04:40 usr/share/man/man1/cygstart.1.gz -rw-r--r-- cwilson/Users 2006 2013-06-07 04:40 usr/share/man/man1/mkshortcut.1.gz -rw-r--r-- cwilson/Users 1402 2013-06-07 04:40 usr/share/man/man1/readshortcut.1.gz Is that intended? Yes. Install cygutils-extra. See: http://cygwin.com/ml/cygwin-announce/2013-06/msg7.html -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Where is getclip?
On Wed, 19 Jun 2013 10:06:49 -0400 Charles Wilson wrote: >On 6/19/2013 9:59 AM, Lemke, Michael SZ/HZA-ZSW wrote: >> Where's getclip.exe gone? I still see it in cygutils-1.4.12-1.tar.bz2 while >> cygutils-1.4.12-2.tar.bz2 is fairly empty: >> >> $ tar tvf >> /c/MyStuff/NCygwinDist/http%3a%2f%2fftp-stud.hs-esslingen.de%2fpub%2fMirrors%2fsources.redhat.com%2fcygwin%2f/release/cygutils/cygutils-1.4.12-2.tar.bz2 >> -rwxr-xr-x cwilson/Users 15901 2013-06-07 04:40 usr/bin/cygstart.exe >> -rwxr-xr-x cwilson/Users 27165 2013-06-07 04:40 usr/bin/mkshortcut.exe >> -rwxr-xr-x cwilson/Users 24605 2013-06-07 04:40 usr/bin/readshortcut.exe >> -rw-r--r-- cwilson/Users 1674 2013-06-07 04:40 >> usr/share/man/man1/cygstart.1.gz >> -rw-r--r-- cwilson/Users 2006 2013-06-07 04:40 >> usr/share/man/man1/mkshortcut.1.gz >> -rw-r--r-- cwilson/Users 1402 2013-06-07 04:40 >> usr/share/man/man1/readshortcut.1.gz >> >> Is that intended? > >Yes. Install cygutils-extra. See: >http://cygwin.com/ml/cygwin-announce/2013-06/msg7.html > Thanks for the quick reply, I found it. Nevertheless, all I did was updating cygwin and suddenly installed stuff was gone. Not funny. Michael -- 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: Where is getclip?
On 6/19/2013 10:16 AM, Lemke, Michael SZ/HZA-ZSW wrote: On Wed, 19 Jun 2013 10:06:49 -0400 Charles Wilson wrote: On 6/19/2013 9:59 AM, Lemke, Michael SZ/HZA-ZSW wrote: Is that intended? Yes. Install cygutils-extra. See: http://cygwin.com/ml/cygwin-announce/2013-06/msg7.html Thanks for the quick reply, I found it. Nevertheless, all I did was updating > cygwin and suddenly installed stuff was gone. Not funny. Ordinarily, package splits such as this one would ALSO incorporate modifications to the package requirements list, so that this sort of thing doesn't happen. That is, the "slimmed down" cygutils package would 'require:' the cygutils-extra and cygutils-x11 packages, so that anybody who previously had the "old, fat" cygutils package installed would automatically get the two new packages, as part of the upgrade -- and would so no visible changes in their installation. However, the purpose of this package split was specifically to *cut down* on the default installation footprint of cygutils -- because several elements in the 'Base' category require cygutils (specifically, they required mkshortcut, readshortcut, and cygstart). Thus, in THIS case, we could NOT do the "normal" thing in manipulating the requirements specifications. Which means..."I updated cygwin and suddenly installed stuff was gone". There just wasn't any better solution available. Sorry for the trouble. -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Where is getclip?
On Wed, 19 Jun 2013 10:28:10 -0400 Charles Wilson wrote: >On 6/19/2013 10:16 AM, Lemke, Michael SZ/HZA-ZSW wrote: >> On Wed, 19 Jun 2013 10:06:49 -0400 Charles Wilson wrote: >>> On 6/19/2013 9:59 AM, Lemke, Michael SZ/HZA-ZSW wrote: Is that intended? >>> >>> Yes. Install cygutils-extra. See: >>> http://cygwin.com/ml/cygwin-announce/2013-06/msg7.html >>> >> Thanks for the quick reply, I found it. Nevertheless, all I did was updating > > cygwin and suddenly installed stuff was gone. Not funny. > >Ordinarily, package splits such as this one would ALSO incorporate >modifications to the package requirements list, so that this sort of >thing doesn't happen. > ... > >However, the purpose of this package split was specifically to *cut >down* on the default installation footprint of cygutils I expected something like that after reading your reply. > >Which means..."I updated cygwin and suddenly installed stuff was gone". >There just wasn't any better solution available. Hm, couldn't you just have introduced a new package, say, cygbaseutils and remove cygutils entirely? At least, I would have noticed something's different while updating. >Sorry for the trouble. No problem. And I am out of here as I am currently not subscribed and don't want to keep breaking the threads here. Michael -- 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 MSYS functionality to Cygwin
On Tue, Jun 18, 2013 at 2:40 PM, Алексей Павлов wrote: > I want to add MSYS functionality to Cygwin. One issue with that would be copyright assignment. Alexey has been in the MSYS code so someone who hasn't looked would need to implement similar functionality. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: magic failure
Matt D. wrote: > I believe the correct syntax is: > > $ ls -ld /usr/bin/gcc-* There are multiple pattern matching characters. http://www.gnu.org/software/bash/manual/bashref.html#Pattern-Matching They have different uses. I intended to use '?' as written. --Ken Nellis -- 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 MSYS functionality to Cygwin
On 6/19/2013 03:05, Corinna Vinschen wrote: Done. Please have a look: http://cygwin.com/faq.html#faq.using.multiple-copies http://cygwin.com/faq.html#faq.using.third-party.multiple-copies Thanks! It looks like 4.22 is still out of date, though. The "must be run serially" bit, at least, conflicts with the new explanation in 4.19. -- 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: getclip and cygutils and cygcheck
I got so dependent on getclip and putclip on Cygwin, that I added these aliases to my universal .bashrc file so I have them on Linux: if [ -n "$(type -P xclip)" ]; then test -z "$(type -P putclip)" && \ alias putclip="$(type -P xclip) -sel clip -i" test -z "$(type -P getclip)" && \ alias getclip="$(type -P xclip) -sel clip -o" fi -Ken On 06/13/2013 02:13 PM, Jeremy Hetzler wrote: I use getclip/putclip every day. ... Please please keep these utilities unless there is a fully functional replacement. -- 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: Updated Git build
On Wed, Jun 19, 2013 at 12:10:58PM +0200, Frank Fesevur wrote: >2013/6/19 Adam Dinwoodie: >> I'm not sure who the current maintainer is, or how to find out, > >This is the list of all packages and their maintainers. >http://cygwin.com/cygwin-pkg-maint > >Not sure where to find a link to this on the cygwin site though. For the record, that list isn't intended as a convenient way to contact maintainers personally - that's why there are no email addresses there. If you have concerns then the cygwin list is the place to voice them. -- 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: getclip and cygutils and cygcheck
On Jun 17 14:54, Corinna Vinschen wrote: > On Jun 17 12:16, Corinna Vinschen wrote: > > On Jun 14 23:15, Jeremy Hetzler wrote: > > > After some testing, the limit seems to be 64k. It only happens when > > > reading data that was copied to the clipboard by a Windows program (in > > > this case Excel). > > > [...] > > > 583 $ cat /dev/clipboard >out.cat > > > cat: /dev/clipboard: Bad address > > > [...] > > > Does that help? > > > > Yes, thank you. There was an ill-conceived check for the last character > > in the buffer being a high surrogate UTF-16 character. It worked only > > if the clipboard content was small enough to fit into a single read of > > the application. If it was too big, and the application had to call > > read again to fetch more from the clipboard, it tried to read the > > character beyond the array boundary. I fixed that in CVS. I'll probably > > create a new developer snapshot and a 64 bit test version later today. > > FYI, I'm just uploading a new developer snapshot 2013-06-17 to > http://cygwin.com/snapshots/, as well as a new 64 bit Cygwin test > release 1.7.21-4. Please give one of them a try. Guys? Ping? Any testers? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Adding MSYS functionality to Cygwin
On 6/18/2013 20:02, Christopher Faylor wrote: On Tue, Jun 18, 2013 at 04:04:06PM -0600, Warren Young wrote: It would be possible, though somewhat evil, for Cygwin's exec() implementation to peek at the DLL dependency list of a program before starting it, and from that infer whether it should automatically translate paths. Cygwin already does this. It detects whether the program it is about to run uses the Cygwin DLL and, if not, makes decisions on how to handle exec. It would be relatively easy to extend this. Well, given that we're already paying the "peek" cost, I don't have any objection to making exec() take longer for the native Windows case only. Do you know how you want to cope with my contrived "xcopy /bin a b" example? The point of the example, of course, is that "/bin" looks like a real, existing POSIX path, but isn't. From Chuck's explanation of MSYS, looks like "/b /i /n" would also get caught in their heuristics, since it apparently doesn't do file existence checks. (Else, Chuck's dumpbin example wouldn't need a workaround.) File existence checks would fix that, but would then prevent this from doing what you want: $ notepad ~/tmp/newfile.txt So, it looks like MSYS is right not to try file existence checks. (Yes, I realize you can rewrite my xcopy example using dashes for the flags. That's beside the broader point, which is that not all things that look like POSIX paths are such.) -- 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: getclip and cygutils and cygcheck
On Wed, Jun 19, 2013 at 1:21 PM, Corinna Vinschen <...> wrote: >> FYI, I'm just uploading a new developer snapshot 2013-06-17 to >> http://cygwin.com/snapshots/, as well as a new 64 bit Cygwin test >> release 1.7.21-4. Please give one of them a try. > > Guys? Ping? Any testers? > > > Corinna > I tested the snapshot and it seems to have fixed the problem. Thanks! Yours, Jeremy Hetzler -- 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 MSYS functionality to Cygwin
On Jun 19 10:53, Warren Young wrote: > On 6/19/2013 03:05, Corinna Vinschen wrote: > > > >Done. Please have a look: > >http://cygwin.com/faq.html#faq.using.multiple-copies > >http://cygwin.com/faq.html#faq.using.third-party.multiple-copies > > Thanks! > > It looks like 4.22 is still out of date, though. The "must be run > serially" bit, at least, conflicts with the new explanation in 4.19. Thanks for checking. I dropped the 4.22 FAQ entry completely. It just doesn't make sense anymore. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: getclip and cygutils and cygcheck
On Jun 19 13:31, Jeremy Hetzler wrote: > On Wed, Jun 19, 2013 at 1:21 PM, Corinna Vinschen <...> wrote: > >> FYI, I'm just uploading a new developer snapshot 2013-06-17 to > >> http://cygwin.com/snapshots/, as well as a new 64 bit Cygwin test > >> release 1.7.21-4. Please give one of them a try. > > > > Guys? Ping? Any testers? > > > > > > Corinna > > > > I tested the snapshot and it seems to have fixed the problem. Thanks! Ah, thanks for testing! Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Adding MSYS functionality to Cygwin
On Wed, Jun 19, 2013 at 11:30:11AM -0600, Warren Young wrote: >On 6/18/2013 20:02, Christopher Faylor wrote: >> On Tue, Jun 18, 2013 at 04:04:06PM -0600, Warren Young wrote: >>> It would be possible, though somewhat evil, for Cygwin's exec() >>> implementation to peek at the DLL dependency list of a program before >>> starting it, and from that infer whether it should automatically >>> translate paths. >> >> Cygwin already does this. It detects whether the program it is about >> to run uses the Cygwin DLL and, if not, makes decisions on how to >> handle exec. It would be relatively easy to extend this. > >Well, given that we're already paying the "peek" cost, I don't have any >objection to making exec() take longer for the native Windows case only. > >Do you know how you want to cope with my contrived "xcopy /bin a b" >example? The point of the example, of course, is that "/bin" looks like >a real, existing POSIX path, but isn't. I don't think people are getting this: *How this is implemented doesn't matter*. I'm talking about providing hooks so that an add-on MSYS dll could modify the windows command-line. Then we wouldn't care what MSYS does with the command-line since it isn't a Cygwin DLL decision. The goal is to allow a small DLL to hook into Cygwin and do whatever MSYS wants to do. Something like: callout (CO_EXEC, &command_line); Where it is expected that the command line could be modified. The "check-for-windows" code is already there. Calling out would be close to a no-op in the non-MSYS cost. Otherwise, I really don't care what it costs. I understand the objections to the way that MSYS does things. I really do. I don't like what it does, either (and I've voiced the same objections in the past) but we're willing to selectively modify Cygwin to allow it to be used as the engine that drives future MSYS development. The goal would be to collapse the fork back into Cygwin with minimal cost to the Cygwin DLL. cgf -- 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 MSYS functionality to Cygwin
On 6/19/2013 07:31, Charles Wilson wrote: http://www.mingw.org/wiki/Posix_path_conversion That's good info. I'm glad to see that relative paths are never molested. I tried for a while to confuse Cygwin and native Windows programs using relative paths, and failed to find a case where the path doesn't mean the same thing to both sides. Not all packages are cross-compiler-compatible. Is that another way of saying that not all packages use autotools? :) You're not talking about anything different than the sort of thing Cygwin package maintainers go through, sometimes needing to arm-twist odd build systems to behave according to cygport's expectations? -- 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 MSYS functionality to Cygwin
On 2013-06-19 12:57, Warren Young wrote: Not all packages are cross-compiler-compatible. Is that another way of saying that not all packages use autotools? :) autotools can certainly make cross-compiling easier than most other build systems, but it's not a guarantee either. For instance, anything that requires in-tree compiled executables to run (e.g. AC_RUN_IFELSE configure tests, GObject Introspection generation, etc.) requires either workarounds, or simply cannot be cross-compiled. You're not talking about anything different than the sort of thing Cygwin package maintainers go through, sometimes needing to arm-twist odd build systems to behave according to cygport's expectations? I think you mean Cygwin's expectations? 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: Adding MSYS functionality to Cygwin
On Jun 19 11:04, Earnie Boyd wrote: > On Tue, Jun 18, 2013 at 2:40 PM, Алексей Павлов wrote: > > I want to add MSYS functionality to Cygwin. > > One issue with that would be copyright assignment. Alexey has been in > the MSYS code so someone who hasn't looked would need to implement > similar functionality. Only if it becomes part of Cygwin. If we implement the plugin/hook method, the licensing is no problem. The plugin could certainly use plain GPLv3+ again. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Adding MSYS functionality to Cygwin
On 6/19/2013 1:45 PM, Christopher Faylor wrote: I'm talking about providing hooks so that an add-on MSYS dll could modify the windows command-line. Then we wouldn't care what MSYS does with the command-line since it isn't a Cygwin DLL decision. The goal is to allow a small DLL to hook into Cygwin and do whatever MSYS wants to do. Something like: callout (CO_EXEC, &command_line); Where it is expected that the command line could be modified. Interesting. Obviously, there's more to a "complete" MSYS replacement/reimplementation, but cmd-line manipulation for exec'ing native apps is really the biggest MSYS-ism of the bunch. I assume that, eventually and as-needed, a *small* number of additional "hooks" could be added to other code paths than exec/spawn/etc -- such as the aforementioned uname(3) thing. (One of the "deltas" between cygwin and msys was msys used a really stupid ownership/permission model -- pretend current user owns everything; check the DOS R/O bit for +w; check the file extension for +x; -- but this can be approximated with existing $CYGWIN entries or mount options. I think. So reimplementing that "feature" of MSYS would not require any additional hooks). The goal would be to collapse the fork back into Cygwin with minimal cost to the Cygwin DLL. +1 -- Chuck -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem with FAQ heading
http://cygwin.com/faq/faq.html#faq.programming.msvs-mingw 6.19. How do I use cygwin1.dll with Visual Studio or MinGW? This section doesn't actually mention MinGW except in its heading. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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: Bug with Cygwin's 'quilt' is actually in 'patch'
I've been looking further into this and it appears as though the problem is in 'patch' not 'quilt'. quilt is actually a collection of bash scripts and calls patch to do the actual patching. Using the same example I provided earlier in the thread, the same error occurs when calling patch directly: $ patch Imakefile patches/test.patch Running dos2unix on test.patch will allow the patch to apply successfully. However, this is WRONG. Imakefile and the initially created test.patch both use CRLF line endings. The patch should definitely NOT apply by introducing actual disparity. To summarize, the patch to Imakefile (CRLF) will apply if it is converted to LF line endings. Using the '--binary' switch seems to be a workaround for this issue. On 6/18/2013 1:36 AM, Matt D. wrote: Built the latest source 0.60 (same version as Cygwin) from http://freecode.com/projects/quilt. Built on CentOS 6.4 and passes my previously provided test just fine. Downloaded the same source to Cygwin, rebuilt, replaced quilt in /bin; test still errors out. I also tried the latest cygwin1.dll snapshot; same problem. On 6/18/2013 1:09 AM, Matt D. wrote: The last e-mail I supplied to the mailing list was missing the link to the example. See this one for the link. --- There seems to be a problem with Cygwin's quilt. This simple example simply alters a #define from 'MESAGL' to 'NX_MESAGL'. That's it. New quilt created, ok. New patch, ok. Edit file, ok. Refresh (create patch), ok. Rollback changes, ok. Reapply patch.. error: >>> quilt push >>> Applying patch test.patch >>> patching file Imakefile >>> Hunk #1 FAILED at 2. >>> 1 out of 1 hunk FAILED -- rejects in file Imakefile >>> Patch test.patch does not apply (enforce with -f) http://codespunk.com/files/upload/cygwin_quilt_00.zip Extract to a directory, cd in, and run 'quilt push' to generate the error. -- 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 -- 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 -- 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: Bug with Cygwin's 'quilt' is actually in 'patch'
On Wed, Jun 19, 2013 at 11:31:48PM -0400, Matt D. wrote: >I've been looking further into this and it appears as though the problem >is in 'patch' not 'quilt'. quilt is actually a collection of bash >scripts and calls patch to do the actual patching. > >Using the same example I provided earlier in the thread, the same error >occurs when calling patch directly: > >$ patch Imakefile patches/test.patch > >Running dos2unix on test.patch will allow the patch to apply >successfully. However, this is WRONG. Imakefile and the initially >created test.patch both use CRLF line endings. The patch should >definitely NOT apply by introducing actual disparity. > >To summarize, the patch to Imakefile (CRLF) will apply if it is >converted to LF line endings. Using the '--binary' switch seems to be a >workaround for this issue. Sorry but we're emulating Linux here. You shouldn't have CRLF endings on your text file if you want the tools to work reliably. cgf -- 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: Bug with Cygwin's 'quilt' is actually in 'patch'
I'm building from Linux source from the X2Go git repository. The patches are being applied downstream to the last base nx libraries provided by NoMachine. It can't be helped if the original source has CRLF in this case. I understand that Cygwin is trying to emulate Linux here, but I don't believe that is the appropriate response regarding tools like 'patch' which should not have this kind of limitation. The fact that it thinks: > \r\n <> \r\n but.. > \r\n == \n As I mentioned previously, patch does NOT have this issue on Linux using the EXACT SAME test case. This is definitely a bug. On 6/20/2013 1:47 AM, Christopher Faylor wrote: On Wed, Jun 19, 2013 at 11:31:48PM -0400, Matt D. wrote: I've been looking further into this and it appears as though the problem is in 'patch' not 'quilt'. quilt is actually a collection of bash scripts and calls patch to do the actual patching. Using the same example I provided earlier in the thread, the same error occurs when calling patch directly: $ patch Imakefile patches/test.patch Running dos2unix on test.patch will allow the patch to apply successfully. However, this is WRONG. Imakefile and the initially created test.patch both use CRLF line endings. The patch should definitely NOT apply by introducing actual disparity. To summarize, the patch to Imakefile (CRLF) will apply if it is converted to LF line endings. Using the '--binary' switch seems to be a workaround for this issue. Sorry but we're emulating Linux here. You shouldn't have CRLF endings on your text file if you want the tools to work reliably. cgf -- 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 -- 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
