RE: [PATCH] Fix optional variables in libargp
Hello! > So at this point your patch doesn't work in x86 for me. I'd appreciate > it if someone else could test it, or suggest a modification to make it > work. Ok, i'll test it myself. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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: Win32 error in C program using openmp and fork()
On Jul 20 19:30, Daniel Brown wrote:
> Hi,
>
> So I have some code I am trying to port to Cygwin but I am getting the
> error:
>
> fatal error in forked process - failed to create new win32 semaphore,
> Win32 error 87
>
> when calling fork() in a C program when openmp code has been used
> beforehand. I've got the following test code which reduces the problem
> down to as little code as I could:
>
> #include
> #include
> #include
>
> int main(void)
> {
> pid_t childPID;
>
> #pragma omp parallel
> {
> printf("I'm an openmp thread...\n");
> }
>
> childPID =3D fork();
>
> if(childPID >=3D 0) {
> if(childPID =3D=3D 0) {
> printf("Child fork\n");
> } else {
> printf("Parent fork\n");
> }
> } else {
> printf("Fork failed");
> return 1;
> }
>
> return 0;
> }
>
> To build I just use "gcc -fopenmp para.c" and the output I get is...
>
> I'm an openmp thread...
> I'm an openmp thread...
> I'm an openmp thread...
> I'm an openmp thread...
> Parent fork 0 [main] a 18640 D:\usr\code\c\a.exe: *** fatal error
> in forked process - failed to create new win32 semaphore, Win32 error
> 87
I didn't try with 1.7.20, but with the current 1.7.21 and with the
latest snapshot from http://cygwin.com/snapshots/, on 32 and 64 bit,
and this is what I get on both cases:
$ uname -r
1.7.21(0.267/5/3)
$ gcc -g -fopenmp -o openmp-test openmp-test.c
$ ./openmp-test
I'm an openmp thread...
I'm an openmp thread...
Parent fork
Child fork
$
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: regex library fails git tests
On Jul 21 22:59, Mark Levedahl wrote: > On 07/21/2013 03:39 PM, Corinna Vinschen wrote: > > >So, what I did now was this: I added a workaround to Cygwin's regcomp. > >If the current codeset is ASCII, the characters in the pattern are > >converted to wchar_t by simply using their unsigned value verbatim. > >This allows to compile (and test) the patterns in the git testcases. > > > >However, please note that this behaviour, while being provided by glibc > >and now by Cygwin, is *not* standards-compliant. In the narrow sense > >the characters beyond 0x7f are still invalid ASCII chars, and other > >functions working with wchar_t strings won't be as forgiving when using > >invalid input. > > > > > >HTH, > >Corinna > > > > Thank you. I confirm that git passes the two test cases (t4018 and > t4034) using today's snapshot. Thanks for your feedback and for testing the snapshot. I created them yesterday but then forgot to mention them here. > I will pass your comments about use > of characters 0x80 and above to the git list to see if they wish to > change anything. After some sleep, I think I now understand why the glibc devs made regcomp to work this way. This behaviour is backward compatible to non locale-aware applications. In the "C" locale, a char is just some arbitrary byte between 0 and 255. So this pattern always worked before in the "C locale, therefore it makes sense that it continues to work, even if it won't when using other locales/codesets. 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: gcc - Is the C function select thread safe??
Snapshot tried successfully.. Magic! -- View this message in context: http://cygwin.1069669.n5.nabble.com/gcc-Is-the-C-function-select-thread-safe-tp100994p101050.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: [PATCH] Fix optional variables in libargp
Hello! I have successfully tested it on i386. Really, just remove PREFIX completely and it's okay. GetProcAddress() appears to be "clever" and adds the leading underscope by itself on i386. I don't know what you did wrong and why you could not reproduce the solution. However, i have one idea. After patching libargp you need to recompile your test case. Because it needs to pick up __declspec(dllexport). > Fedin, thanks for sending this. I've tested it for x86_64, and it > works there. However in x86, in my testing I can't get it to work. I > tried removing the PREFIX function, and after that it did work once, > but I've tried it again several times and now I can't reproduce that. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- 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: mingw64-*-runtime
Version 3.0b_svn5935-2 of "mingw64-i686-runtime" and "mingw64-x86_64-runtime" has been uploaded. The only change from the -1 release is the addition of the -headers package as dependency that was accidentally omitted in the last release. mingw64-* gcc should install correctly again for fresh installs. *** 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.com 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: Mingw build problem for TCL
On 7/21/2013 1:08 AM, Jonathan Kelly wrote: On Jul 20 08:08, Jonathan Kelly wrote: Not. Comes up with error "The application was unable to start correctly (0xc022). No, it's not - it compiles and runs as it should when I use the Mingw directly. It's what I'm using now. I was just trying to give back a little by reporting a problem. 0xc022 is the error code, IIRC, for "couldn't find a DLL that I needed at startup". For the (failing) binary that you compiled using cygwin's mingw-gcc package(s), could you post the result of the following command? $ i686-pc-mingw32-objdump -p tclsh.exe | grep 'DLL Name' -- 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: Mingw build problem for TCL
On Jul 22 09:19, Charles Wilson wrote: > On 7/21/2013 1:08 AM, Jonathan Kelly wrote: > >>On Jul 20 08:08, Jonathan Kelly wrote: > >>>Not. Comes up with error "The application was unable to start > >>>correctly (0xc022). > > >No, it's not - it compiles and runs as it should when I use the Mingw > >directly. It's what I'm using now. I was just trying to give back a > >little by reporting a problem. > > 0xc022 is the error code, IIRC, for "couldn't find a DLL that I > needed at startup". No, it's STATUS_ACCESS_DENIED, a permission problem. This could happen, for instance, if the executable or one of the required DLLs is not executable. 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
[ANNOUNCEMENT] Updated: http://cygwin.com/setup*.exe
We have updated the setup.exe executables on cygwin.com in preparation for the upcoming release of Cygwin 1.7.22. There are now two versions of setup. setup-x86.exe will install and update the 32-bit version of Cygwin. setup-x86_64.exe will install and update the 64-bit version of Cygwin. Although it is not strictly necessary, it is a good idea to clear out your download directory prior to running these programs. The new setup exe's create a different directory structure in the download directory and do not recognize the old layout. So, any files left over from running older versions of setup.exe will be ignored by the new version of setup. Older setup.exe's will no longer work with the setup.ini files used by the newer setup.exe versions so you'll definitely need to download the new version of the setup program if you want to install or update Cygwin. 32-bit Cygwin setup: http://cygwin.com/setup-x86.exe 64-bit Cygwin setup: http://cygwin.com/setup-x86_64.exe Or, just click on the links at http://cygwin.com/ . The old setup version (which only installed the 32-bit version of Cygwin) is still available and will be available for a few days. But, please don't rely on its continued existence. -- 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: Cygwin 1.7.22 (First offical 64 bit release)
Hi Cygwin friends and users, I just released Cygwin 1.7.22. === INTRODUCING A 64 BIT RELEASE === This is the first official Cygwin release which is publically available as a 64 bit version for AMD64 Windows systems. Right now the 64 bit Cygwin distribution doesn't come with as many packages as the 32 bit version, but it's as stable as the 32 bit version, and more packages will be available over time. If you're already running a 32 bit version of Cygwin on 64 bit Windows machines, you can continue to do so. If you're planning a new install of Cygwin on a 64 bit Windows machine, consider to use the new 64 bit Cygwin version, unless you need certain packages not yet available in the 64 bit release. To install 32-bit Cygwin use the new http://cygwin.com/setup-x86.exe To install 64 bit Cygwin use the new http://cygwin.com/setup-x86_64.exe === Other than that, 1.7.22 is mostly a bugfix release. What changed: --- - Support for /dev/mem, /dev/kmem and /dev/port removed, since OS support was limited to 32 bit Windows XP only. - Added cygwin GetCommandLine wrappers which will allow Cygwin programs to (appear to) use the Windows command line functions. - regcomp(3) now allows character values >= 0x80 if the current codeset is ASCII (default codeset in the "C"/"POSIX" locale). This allows patterns containing arbitrary byte values as GLibc's regcomp. Fixes: http://cygwin.com/ml/cygwin/2013-07/msg00405.html Bug fixes: -- - Fix an off-by-one error in path handling which made the access check for the existing path before a ".." component (introduced with 1.7.21) fail for UNC paths (//server/share/path). Fixes: http://cygwin.com/ml/cygwin/2013-07/msg00375.html - Fix long-standing problem which allows to access files via ".." using an invalid POSIX path, for instance, `cd nonexistant/../existing_dir". Fixes: http://cygwin.com/ml/cygwin/2013-05/msg00222.html - Fix an initialization bug in XSI IPC on, which could result in XSI IPC functions misbehave on x86_64. Fixes: http://cygwin.com/ml/cygwin-apps/2013-07/msg00063.html http://cygwin.com/ml/cygwin-apps/2013-07/msg00229.html - Fix a timer handle leak in sleep family of functions. Fixes: http://cygwin.com/ml/cygwin/2013-07/msg00379.html - Fix issue with raise() not causing the process to exit with a signal status. Also only set "dumped core" flag when it's a "kernel" signal. See: http://cygwin.com/ml/cygwin-apps/2013-07/msg00251.html Have fun, Corinna *** 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. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader 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
How I mirrored my 32-bit version of cygwin to 64-bit
I wanted to have roughly the same packages available in my 64-bit version of Cygwin as for my 32-bit version so, this is what I did: 1) Decide that the root of the 64-bit version would be c:\cygwin64. 2) mkdir -p /cygdrive/c/cygwin64/etc 3) sed 's/-[0-9][0-9.a-z]*-[0-9]*.tar.bz2/-0.0.0-0.tar.bz2/g' /etc/setup/installed.db > /cygdrive/c/cygwin64/etc/installed.db 4) Download http://cygwin.com/setup-x86_64.exe 5) Run setup-x86_64.exe, choose root/mirror, and then just hit Next until the installation is complete. You will, of course, after this, still have to set up services and perform any other customizations that you did for your 32-bit installation. 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: regex library fails git tests
On 07/22/2013 02:12 AM, Corinna Vinschen wrote: >>> However, please note that this behaviour, while being provided by glibc >>> and now by Cygwin, is *not* standards-compliant. In the narrow sense >>> the characters beyond 0x7f are still invalid ASCII chars, and other >>> functions working with wchar_t strings won't be as forgiving when using >>> invalid input. >>> > After some sleep, I think I now understand why the glibc devs made > regcomp to work this way. This behaviour is backward compatible to non > locale-aware applications. In the "C" locale, a char is just some > arbitrary byte between 0 and 255. So this pattern always worked before > in the "C locale, therefore it makes sense that it continues to work, > even if it won't when using other locales/codesets. By the way, there is currently a big debate going on in the Austin Group (the people responsible for POSIX) on whether the "C" locale must be 8-bit clean (the way glibc behaves) or whether it was intended to allow UTF-8 encoding by default (the way musl libc wants to behave); and resolution of the debate will require input from the C standards committee. There may be some interesting fallout, no matter which solution is finally reached. http://austingroupbugs.net/view.php?id=663 -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
64-bit setup: not a valid win32 application
Hi all, I tried to install 64-bit cygwin today, but I keep encountering the error message "setup-x86_64.exe is not a valid Win32 application." I found another message that said to clear IE's file cache and try again, but that didn't help. Plus, downloading the executable with the wget from 32-bit cygwin causes the same problem. Is there something else I should try? FYI, this is a brand new clean install of win7-64. Thanks, Ryan -- 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: 64-bit setup: not a valid win32 application
On Tue, Jul 23, 2013 at 12:10 PM, Ryan Johnson wrote: > > I tried to install 64-bit cygwin today, but I keep encountering the error > message "setup-x86_64.exe is not a valid Win32 application." I had the same problem today on Windows 8. The solution was to download the 64-bit setup program from a mirror instead of the cygwin.com site. Try here: * http://mirror.mcs.anl.gov/cygwin/64bit/setup64.exe -- Darik Horn -- 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: 64-bit setup: not a valid win32 application
On Tue, Jul 23, 2013 at 03:10:51PM -0400, Ryan Johnson wrote: >I tried to install 64-bit cygwin today, but I keep encountering the >error message "setup-x86_64.exe is not a valid Win32 application." Sorry about that. This problem is fixed. -- 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: 64-bit setup: not a valid win32 application
On Mon, Jul 22, 2013 at 12:19:18PM -0700, Darik Horn wrote: >On Tue, Jul 23, 2013 at 12:10 PM, Ryan Johnson > wrote: >> >> I tried to install 64-bit cygwin today, but I keep encountering the error >> message "setup-x86_64.exe is not a valid Win32 application." > >I had the same problem today on Windows 8. The solution was to >download the 64-bit setup program from a mirror instead of the >cygwin.com site. Try here: > >* http://mirror.mcs.anl.gov/cygwin/64bit/setup64.exe DO NOT USE THIS SETUP. It is an old version from the 64-bit beta testing days. The setup.ini associated with it has not been updated for a while. I've removed it from sourceware so it will soon be gone from the mirrors. 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: 64-bit setup: not a valid win32 application
On 07/22/2013 03:27 PM, Christopher Faylor wrote: On Tue, Jul 23, 2013 at 03:10:51PM -0400, Ryan Johnson wrote: I tried to install 64-bit cygwin today, but I keep encountering the error message "setup-x86_64.exe is not a valid Win32 application." Sorry about that. This problem is fixed. Works, thanks. Ryan -- 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
64-bit mercurial?
Hi mercurial manager, Is an official 64-bit mercurial coming soon? Meanwhile, is there any reason I shouldn't expect a wget/configure/make cycle to "just work" ? Thanks! Ryan -- 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: regex library fails git tests
On Jul 22 11:17, Eric Blake wrote: > On 07/22/2013 02:12 AM, Corinna Vinschen wrote: > > >>> However, please note that this behaviour, while being provided by glibc > >>> and now by Cygwin, is *not* standards-compliant. In the narrow sense > >>> the characters beyond 0x7f are still invalid ASCII chars, and other > >>> functions working with wchar_t strings won't be as forgiving when using > >>> invalid input. > >>> > > > After some sleep, I think I now understand why the glibc devs made > > regcomp to work this way. This behaviour is backward compatible to non > > locale-aware applications. In the "C" locale, a char is just some > > arbitrary byte between 0 and 255. So this pattern always worked before > > in the "C locale, therefore it makes sense that it continues to work, > > even if it won't when using other locales/codesets. > > By the way, there is currently a big debate going on in the Austin Group > (the people responsible for POSIX) on whether the "C" locale must be > 8-bit clean (the way glibc behaves) or whether it was intended to allow > UTF-8 encoding by default (the way musl libc wants to behave); and > resolution of the debate will require input from the C standards > committee. There may be some interesting fallout, no matter which > solution is finally reached. http://austingroupbugs.net/view.php?id=663 Thanks for letting us know. This really may get interesting... 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
Resume
Are you still looking for job? Email back at ...alicia.rooney1...@gmail.com -- 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
64-bit gcc-4.8.1 package installs source instead
Hi all, If I select the gcc-4.8.1-1 package from setup-64, it downloads and installs the gcc-4.8.1-src package, which AFAICT includes a tarball of the gcc sources, a patch, and a cygport file: $ for f in $(find /usr -name '*gcc*'); do echo "$f: $(cygcheck -f $f)"; done /usr/src/4.8-libgcc-cygwin64.patch: /usr/src/gcc-4.8.1.tar.bz2: /usr/src/gcc.cygport: /usr/bin/cyggcc_s-seh-1.dll: libgcc-4.8.1-1 Oddly (and the reason for the little script above): $ cygcheck -dc | grep gcc libgcc4.8.1-1 In other words, cygwin thinks that neither gcc nor gcc-src is actually installed, and will happily repeat the broken install as many times as I've tried so far. Packaging bug? Ryan -- 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: 64-bit gcc-4.8.1 package installs source instead
On 2013-07-23 16:26, Ryan Johnson wrote: If I select the gcc-4.8.1-1 package from setup-64, it downloads and installs the gcc-4.8.1-src package gcc is only a source-only meta-package; you want to install gcc-core, gcc-g++, etc. 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: 64-bit mercurial?
On 2013-07-23 14:53, Ryan Johnson wrote: Hi mercurial manager, That would be Jari, who hasn't been around recently and hence hasn't started on x86_64 packages yet. Is an official 64-bit mercurial coming soon? Meanwhile, is there any reason I shouldn't expect a wget/configure/make cycle to "just work" ? Hg is actually a Python distutils package, which is also pretty straightforward in its own way: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/mercurial;a=tree The subpackages are due to extra dependencies of some extensions; hg itself requires only Python and ca-certificates. 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: 64-bit gcc-4.8.1 package installs source instead
On 07/22/2013 05:38 PM, Yaakov (Cygwin/X) wrote: On 2013-07-23 16:26, Ryan Johnson wrote: If I select the gcc-4.8.1-1 package from setup-64, it downloads and installs the gcc-4.8.1-src package gcc is only a source-only meta-package; you want to install gcc-core, gcc-g++, etc. Oh, that's a little different than (a) the name suggests and (b) historical precedent, which IIRC had "gcc" as a meta package that pulled in all the other gcc-related stuff you'd need. Anyway, thanks for the tip, I'll try that. Ryan -- 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
uname vs. cygcheck output discrepancy
I downloaded the latest version of setup-x86.exe (and setup-x86_64.exe) and updated both my Cygwin installs. The 64bit version seems to be okay but on 32b Cygwin, I notice a discrepancy in the dll version number between uname and cygcheck. $ uname -a CYGWIN_NT-6.1-WOW64 [EDITED] 1.7.21(0.267/5/3) 2013-07-15 12:17 i686 Cygwin $ cygcheck -V cygcheck (cygwin) 1.7.22 System Checker for Cygwin Copyright (C) 1998 - 2013 Red Hat, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- 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: uname vs. cygcheck output discrepancy
On 7/22/2013 6:00 PM, Balaji Venkataraman wrote: I downloaded the latest version of setup-x86.exe (and setup-x86_64.exe) and updated both my Cygwin installs. The 64bit version seems to be okay but on 32b Cygwin, I notice a discrepancy in the dll version number between uname and cygcheck. $ uname -a CYGWIN_NT-6.1-WOW64 [EDITED] 1.7.21(0.267/5/3) 2013-07-15 12:17 i686 Cygwin $ cygcheck -V cygcheck (cygwin) 1.7.22 Are you sure you don't need to reboot? If cygwin1.dll was in use while you were installing and you didn't free it up, a reboot will be necessary before you see the new cygwin1.dll. -- Larry _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: uname vs. cygcheck output discrepancy
On Mon, Jul 22, 2013 at 3:04 PM, Larry Hall (Cygwin) wrote: > Are you sure you don't need to reboot? If cygwin1.dll was in use while > you were installing and you didn't free it up, a reboot will be necessary > before you see the new cygwin1.dll. Yes, the reboot fixed it. I've updated my Cygwin (dll) w/o a reboot many a time - after killing all server processes/services etc. - not sure what happened this time. Sorry about the noise. -- 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: Mingw build problem for TCL
No, it's STATUS_ACCESS_DENIED, a permission problem. This could happen, for instance, if the executable or one of the required DLLs is not executable. Corinna Ah, yes, there is a zlib dll shipped with the source that didn't have executable perms. I'll let the TCL people know. Thanks! Jonathan. -- 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
Basic gcc compilation on cygwin64
I'm trying to compile the following basic program on cygwin64:
int main() {
;
return 0;
}
But I get the following errors:
$ gcc test.c
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -ladvapi32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lshell32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -luser32
/usr/lib/gcc/x86_64-pc-cygwin/4.8.1/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lkernel32
collect2: error: ld returned 1 exit status
This is my first time using the 64-bit version of cygwin and I get the
feeling I am missing some sort of flag or library.
Richard
--
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: runing ./configure on gdb 7.5.50 sources
Ryan Johnson writes:
>
> On 09/01/2013 1:57 AM, Jose Munoz wrote:
> > I tried to build the original gdb sources, which I
> > downloaded using setup.exe and selecting them.
> >
> > Without modifying any source code of gdb, I run ./configure from my
> > source folder:
> >
> > C:\cygwin\usr\src\gdb-7.5.50-1
> >
> > After a set of checks, configure hangs at the gnum4 check, at least
> > more than 2 hours.
> I've never seen this exact error, but my first step in diagnosing
> configure issues is to check config.log for anomalies.
>
I'm using gdb-7.6.50-2 on cygwin 1.7.22-1. All freshly updated today.
I don't have this gnum4 problem.
> Also, you're not supposed to configure gdb in /under the directory
> containing its own sources. Try creating a "gdb-obj" somewhere else and
> then ../gdb-src/configure
>
I do this.
> > I also tried to run ./configure from the gdb folder
> > (C:\cygwin\usr\src\gdb-7.5.50-1\gdb), but in this case, after a longer
> > output, configure gives the following error message:
> >
> > "checking for Tcl private headers... configure: error: could not find
> > private Tcl headers"
I do have this problem as well (also when running the configure from
gdb-7.6.50-2 and then make).
> You probably need to install some tcl*-dev package.
>
There are no tcl*dev packages in cygwin.
Checking this a bit closer I see that this error is generated when looking
for tclInt.h. The relevant autoconf code in gdb/acinclude.m4:
AC_DEFUN([CY_AC_TCL_PRIVATE_HEADERS], [
AC_MSG_CHECKING([for Tcl private headers])
private_dir=""
dir=`echo ${TCL_INCLUDE_SPEC}/tcl-private/generic | sed -e s/-I//`
if test -f ${dir}/tclInt.h ; then
private_dir=${dir}
fi
...
Further investigation shows that
- this file exists in cygwin as /usr/include/tcl8.5/generic/tclInt.h
- /usr/lib/tclConfig.sh sets TCL_INCLUDE_SPEC='-I/usr/include'
- there is no /usr/include/tcl-private
- a similar problem exists in the next check CY_AC_TK_PRIVATE_HEADERS which
checks for ${TK_INCLUDE_SPEC}/tk-private/generic/tkInt.h, which is in fact
in /usr/include/tcl8.5/generic/tkInt.h.
A look in the tcl source package of cygwin shows that it has a tcl.m4 which
checks for ${TCL_SRC_DIR}/generic/tclInt.h
So, it seems to be that gdb/acinclude.m4 is incorrect and should use
TCL_SRC_DIR as well.
I can get round this problem by doing the following
cd /usr/include
ln -s tcl8.5 tcl-private
ln -s tcl8.5 tk-private
Kris
--
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
setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134
Hi; I think 64bit Cygwin is awesome :-) FYI: trivial postinstall errors: Downloaded setup-x86_64.exe from cygwin.com Selected c:\cygwin64 as install point Selected c:\cygwin64\download as download location Requested Install from Internet Postinstall errors: Package: bash bash.sh exit code 1 Package: a2ps a2ps.sh exit code 2 Package: xinit xinit.sh exit code 134 Thanks, Ken Wolcott -- 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: runing ./configure on gdb 7.5.50 sources
Kris Thielemans writes:
> I'm using gdb-7.6.50-2 on cygwin 1.7.22-1. All freshly updated today.
>
> Further investigation shows that
> - this file exists in cygwin as /usr/include/tcl8.5/generic/tclInt.h
> - /usr/lib/tclConfig.sh sets TCL_INCLUDE_SPEC='-I/usr/include'
> - there is no /usr/include/tcl-private
> - a similar problem exists in the next check CY_AC_TK_PRIVATE_HEADERS which
> checks for ${TK_INCLUDE_SPEC}/tk-private/generic/tkInt.h, which is in fact
> in /usr/include/tcl8.5/generic/tkInt.h.
>
> A look in the tcl source package of cygwin shows that it has a tcl.m4 which
> checks for ${TCL_SRC_DIR}/generic/tclInt.h
>
> So, it seems to be that gdb/acinclude.m4 is incorrect and should use
> TCL_SRC_DIR as well.
>
> I can get round this problem by doing the following
>
> cd /usr/include
> ln -s tcl8.5 tcl-private
> ln -s tcl8.5 tk-private
>
so, I now do get through the configure, but then "make" fails later with a
message that gcc cannot find guitcl.h. Indeed it's not on my system. Is this
supposed to be generated somehow?
In attempt to get through this, I configured:
../../gdb-7.6.50-2/gdb/configure CFLAGS="-g -O0" --without-tcl --without-tk
but that fails with the interesting double-negative error message.
checking for Tcl configuration... configure: error: no directory doesn't
contain tclConfig.sh
so... I still cannot compile gdb from source on cygwin. Any hints?
Kris
--
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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134
On 2013-07-22 19:52, Kenneth Wolcott wrote: Postinstall errors: Thanks for the feedback; remarks inline. Package: bash bash.sh exit code 1 I think the problem is that virtual /dev is a read-only filesystem, but if you make a real /dev directory; then you can write to it. Could you run 'mkdir -p /dev' (without the quotes) and then try rerunning setup-x86_64.exe? I suspect this will work then. FWIW, I wonder why this entire script isn't handled by base-files. Package: a2ps a2ps.sh exit code 2 This is due to a missing papersize(5) file. I'm working on a fix, but a workaround is to run the following command, then rerun setup-x86_64.exe: echo letter > /etc/papersize Package: xinit xinit.sh exit code 134 This is from a SIGABRT in mkshortcut. Chuck? 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
