http://permalink.gmane.org/gmane.os.cygwin.applications hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.cygwin.applications/25892 <pre>Hi A new 64bit version of 'ted' has been uploaded to a server near you. o Build for cygwin 1.7.19-4 with gcc-4.8.0 CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO ====================================== If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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-xfree-announce-unsubscribe-you=yourdomain.com &lt;at&gt; 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. </pre> Dr.Volker 2013-05-17T15:40:19 http://permalink.gmane.org/gmane.os.cygwin.applications/25891 <pre>Hi A new 64bit version of 'squid' has been uploaded to a server near you. o Build for cygwin 1.7.19 with gcc-4.8.0 CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ================================ If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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.com &lt;at&gt; 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. </pre> Dr.Volker 2013-05-17T11:26:11 http://permalink.gmane.org/gmane.os.cygwin.applications/25890 <pre> Huh. The old dependencies came back. That was surprising and puzzling. It's too late to investigate why now. I put the blank requires: back in the setup.hint. cgf </pre> Christopher Faylor 2013-05-17T06:13:11 http://permalink.gmane.org/gmane.os.cygwin.applications/25889 <pre> I've confirmed that setup.exe now has a blank requires line. Hmm. Actually, I think that means that the requires line could actually be deleted since upset will no longer try to use the line from setup.ini. </pre> Christopher Faylor 2013-05-17T05:58:13 http://permalink.gmane.org/gmane.os.cygwin.applications/25888 <pre> Thanks, I've updated the copy in mintty svn accordingly. Andy </pre> Andy Koppe 2013-05-17T04:41:05 http://permalink.gmane.org/gmane.os.cygwin.applications/25887 <pre> What??? No! Of course it doesn't! What a daft notion! Oh. Actually, now that I think of it, the way upset is run, it's the union of an existing setup.ini and setup.hint. So, if there is no requires: line it would get pulled from setup.ini. I've taken the liberty of adding a "requires:" line to mintty's setup.hint. I'll have to think about whether the way I'm running upset now makes sense. It probably doesn't. Sorry for contributing to the confusion. cgf </pre> Christopher Faylor 2013-05-16T22:59:55 http://permalink.gmane.org/gmane.os.cygwin.applications/25886 <pre> Hmm, mintty doesn't depend on cygutils anymore since setup.exe creates the "Cygwin Terminal" shortcut for it, and its setup.hint reflects that. Yet setup.ini does indeed contain the following line for mintty: requires: bash cygutils cygwin Is the problem that the setup.hint doesn't contain a 'requires:' line at all (since mintty has no dependencies apart from the implicit 'cygwin')? Does upset keep previous dependencies in that case? Andy </pre> Andy Koppe 2013-05-16T18:39:59 http://permalink.gmane.org/gmane.os.cygwin.applications/25885 <pre>Hi A new 64bit version of 'initscripts' has been uploaded to a server near you. CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ================================ If you want to unsubscribe from the cygwin-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then 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.com &lt;at&gt; 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. </pre> Dr.Volker 2013-05-16T08:18:22 http://permalink.gmane.org/gmane.os.cygwin.applications/25884 <pre>Hi New 64bit versions of 'gnutls/libgnutls28/gnutls-devel/gnutls-doc/gnutls-guile' have been uploaded to a server near you. o Update to latest upstream version o Build for cygwin 1.7.19-4 with gcc-4.8.0 gnutls NEWS: =============== ** libgnutls: Use nettle's elliptic curve implementation. ** libgnutls: Added Salsa20 cipher ** libgnutls: Added UMAC-96 and UMAC-128 ** libgnutls: Added ciphersuites involving Salsa20 and UMAC-96. As they are not standardized they are defined using private ciphersuite numbers. ** libgnutls: Added support for DTLS 1.2. ** libgnutls: Added support for the Application Layer Protocol Negotiation (ALPN) extension. ** libgnutls: Removed support for the RSA-EXPORT ciphersuites. ** libgnutls: Avoid linking to librt (that also avoids unnecessary linking to pthreads if p11-kit isn't used). ** API and ABI modifications: gnutls_cipher_get_iv_size: Added gnutls_hmac_set_nonce: Added gnutls_mac_get_nonce_size: Added CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ==========================</pre> Dr.Volker 2013-05-16T07:50:16 http://permalink.gmane.org/gmane.os.cygwin.applications/25883 <pre>Hi folks, I almost forgot: Yesterday I uploaded a new Cygwin DLL to the 64 bit distro: 1.7.19-4. It's just a rebuild from the latest in CVS. Corinna </pre> Corinna Vinschen 2013-05-15T14:12:45 http://permalink.gmane.org/gmane.os.cygwin.applications/25882 <pre> Yes, this usage is fine, of course. What I meant above was, if the configury uses a link test to figure out if it should compile Windows or UNIX code, then such a test is kind of borderline. The link failed on 32 bit more or less haphazardly. The function *is* available, the link only failed because the compiler didn't know about the required symbol decoration, which is only added for *one* of multiple supported platforms. Corinna </pre> Corinna Vinschen 2013-05-15T08:24:01 http://permalink.gmane.org/gmane.os.cygwin.applications/25881 <pre> cygutils uses a similar check in its configury to figure out if it should build the windows-only getclip/putclip programs... AC_CHECK_STDCALL_FUNC([OpenClipboard],[void *]) AM_CONDITIONAL(WITH_WINDOWS_PROGRAMS, test "$ac_cv_func_OpenClipboard" = yes) But this still works for both 32- and 64- bit cygwin because those lines are *preceded* by AC_CHECK_HEADERS([... windows.h]) which insures that future test programs have #include &lt;windows.h&gt; in them (assuming the header is found), so the proper declaration/decorations are present for OpenClipboard. -- Chuck </pre> Charles Wilson 2013-05-15T00:19:11 http://permalink.gmane.org/gmane.os.cygwin.applications/25880 <pre>Il 5/14/2013 9:05 PM, Corinna Vinschen ha scritto: not a big problem in this case I can split the check and add a conditional tests from AC_CHECK_FUNCS([_getvideoconfig gettextinfo GetConsoleScreenBufferInfo]) to AC_CHECK_FUNCS([_getvideoconfig gettextinfo ]) case $host_os in CYGWIN*) ;; *) AC_CHECK_FUNCS([GetConsoleScreenBufferInfo]) ;; esac the problem is to identify such issue on other softwares. Thanks Marco </pre> marco atzeri 2013-05-14T20:13:53 http://permalink.gmane.org/gmane.os.cygwin.applications/25879 <pre> I think this is another problem. It's not exactly a problem in fact, but just the way the 64 bit ABI works. On 32 bit, all functions exported by Windows DLLs are using the "stdcall" calling convention. This calling convention uses a symbol decoration which denotes the number of bytes on stack used by the arguments of the function. That's what WINAPI does in the Windows header files. OTOH, the "cdecl" default calling convention does not add this decoration to the symbol name. So what happens is this: Given that you didn't include the windows.h header file, gcc assumes that GetConsoleScreenBufferInfo is using the default "cdecl" calling convention. It emits a reference to the external function "_GetConsoleScreenBufferInfo" (the leading underscore is an integral part of all C calling conventions on 32 bit ix86). However, GetConsoleScreenBufferInfo is a stdcall function exported by kernel32.dll. So the exported symbol is "_GetConsoleScreenBufferInfo&lt; at &gt;8". Therefore, on 32 bit, even though all executabl</pre> Corinna Vinschen 2013-05-14T19:05:05 http://permalink.gmane.org/gmane.os.cygwin.applications/25878 <pre>the attached test extracted by configure of hdf5 is failing on 32 bit as expected with /tmp/cc5L84Vo.o: In function `main': /cygdrive/e/cygwin64/tmp/conftest.c:140: undefined reference to `_GetConsoleScreenBufferInfo' collect2: ld returned 1 exit status but it is passing on 64 bit ls -sh conftest.exe 64K conftest.exe so I guess there is some weird include pulling w32api as the definition is only on the w32api $ grep -rH GetConsoleScreenBufferInfo /usr/include/* /usr/include/w32api/wincon.h: WINBASEAPI WINBOOL WINAPI GetConsoleScreenBufferInfo(HANDLE hConsoleOutput,PCONSOLE_SCREEN_BUFFER_INFO lpConsoleScreenBufferInfo); /usr/include/w32api/wincon.h:WINBASEAPI WINBOOL WINAPI GetConsoleScreenBufferInfoEx( To test just ". config_test.txt" Regards Marco gcc -o conftest.exe -std=c99 -pedantic -Wall -Wextra -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wre</pre> marco atzeri 2013-05-14T18:30:04 http://permalink.gmane.org/gmane.os.cygwin.applications/25877 <pre> I fixed it with "alias vi=vim" in my .bashrc. I've had to do that on assorted Linuxes before, too. </pre> Warren Young 2013-05-14T14:47:14 http://permalink.gmane.org/gmane.os.cygwin.applications/25876 <pre> :( Er... what? Since when does syntax highlighting require perl? The old vim package I compiled when I maintained it was built with the --with-features=huge setting but didn't pull in any of the possible dependencies. No perl, no python, no ruby. But syntax highlighting worked fine. Apart from that, I guess calling vi (and that's what *many* users are used to) will now result in the same error Frank reported. Any chance to build vim-minimal with a bigger default set of features which is only based on avoiding external deps? Corinna </pre> Corinna Vinschen 2013-05-14T11:27:05 http://permalink.gmane.org/gmane.os.cygwin.applications/25875 <pre>2013/5/14 Frank Fesevur: Raspbian and Ubuntu install vim.tiny and vi.basic executables and then use alternatives to avoid the conflict. I don't very little about alternatives, but I guess something similar must be possible on cygwin as well. Install them as vim.tiny.exe and vim.basic.exe (or whatever the right name is) and add a postinstall script to vim-minimal and update the existing postinstall script for vim. The /etc/postinstall/vim.sh.done currently on my system uses update-alternatives and refers to /usr/bin/vim-nox.exe but that is not in /usr/bin. The postinstall of vim.common refers to vim-nox.exe as well. And I assume the order of running the postinstall scripts is important. Regards, Frank </pre> Frank Fesevur 2013-05-14T11:25:39 http://permalink.gmane.org/gmane.os.cygwin.applications/25874 <pre>2013/5/14 Yaakov (Cygwin/X): It overrides the symlink from vi to vim.exe and so this "breaks" my current setup: $ vi Error detected while processing /home/Frank/.vimrc: line 1: E319: Sorry, the command is not available in this version: syntax on Press ENTER or type command to continue Any thought other then fixing the symlink manually? Regards, Frank </pre> Frank Fesevur 2013-05-14T10:19:00 http://permalink.gmane.org/gmane.os.cygwin.applications/25873 <pre> I followed Fedora's lead and compiled vim-minimal --with-features=small, which excludes many features and avoids the need for vim-common (which requires perl and xxd, the former of which being what started this discussion), which e.g. syntax highlighting would require. But this affects *only* ex/vi; vim/view/vimdiff/vimtutor and evim/gvim/etc. are fully loaded, and now more than ever with the (dynamically loaded) lua/perl/python/python3/ruby interfaces. Done. Yaakov </pre> Yaakov (Cygwin/X 2013-05-14T09:35:36 http://permalink.gmane.org/gmane.os.cygwin.applications/25872 <pre> And the other way around? On existing installations it should not replace the full vim with the minimal one when it is added to Base. I had to do a clean installation today and installed vim-minimal. It worked fine for the occasional editing I needed to do. Thanks! Regards, Frank </pre> Frank Fesevur 2013-05-14T09:29:16 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.cygwin.applications