Re: runing ./configure on gdb 7.5.50 sources
On Jul 23 01:38, Kris Thielemans wrote:
> 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?
Here's my cygport file from the 64 bit GDB package:
NAME="gdb"
VERSION="7.6"
RELEASE=1
CATEGORY="Devel"
SUMMARY="The GNU Debugger"
DESCRIPTION="The GNU debugger, allows you to debug programs written in C, C++,
and other languages, by executing them in a controlled fashion
and printing their data."
HOMEPAGE="http://sourceware.org/gdb/";
SRC_URI="ftp://sourceware.org/pub/gdb/releases/${P}.tar.bz2";
#CVS_URI=":pserver:anon...@sourceware.org:/cvs/src"
#CVS_BRANCH="HEAD"
#SRC_DIR="src"
#inherit cvs
CYGCONF_ARGS="--disable-gdbtk --with-system-readline"
src_compile() {
cd ${B}
cygconf
cygmake
}
HTH,
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: 64-bit gcc-4.8.1 package installs source instead
On 2013-07-23 02:22, Corinna Vinschen wrote: On Jul 23 17:47, Ryan Johnson wrote: On 07/22/2013 05:38 PM, Yaakov (Cygwin/X) wrote: 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. Shouldn't we introduce an empty gcc binary archive for just this situation? This is one case where IMO genini is better than upset: genini-generated setup.ini's don't list source-only packages in setup's package selector, while still being available through the "Src" option of any of its subpackages. Could upset be changed to match, which would avoid this problem for *all* source-only packages? 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134
On 2013-07-23 02:21, Corinna Vinschen wrote: On Jul 22 23:40, Yaakov (Cygwin/X) wrote: 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. The base-cygwin script usually creates the /dev dir. Do we have a dependency loop which let bash.sh run before base-cygwin? The only package that depends on base-cygwin is cygwin itself, and neither depend on bash. 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 I'd prefer `echo a4 > /etc/papersize' ;) I suppose you would. :-) Any idea how to provide a sane default that most people on both sides of the pond would be happy with? 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134
On Jul 23 03:27, Yaakov (Cygwin/X) wrote: > On 2013-07-23 02:21, Corinna Vinschen wrote: > >On Jul 22 23:40, Yaakov (Cygwin/X) wrote: > >>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. > > > >The base-cygwin script usually creates the /dev dir. Do we have > >a dependency loop which let bash.sh run before base-cygwin? > > The only package that depends on base-cygwin is cygwin itself, and > neither depend on bash. A deps loop could screw this up. What does the full setup log say to the deps order? Maybe that gives us a hint... > >>>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 > > > >I'd prefer `echo a4 > /etc/papersize' ;) > > I suppose you would. :-) Any idea how to provide a sane default > that most people on both sides of the pond would be happy with? We don't support LC_PAPER so we also don't have this information in some DB. Just use letter and let us europeans with their weird paper formats handle this manually. 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: 64-bit gcc-4.8.1 package installs source instead
On Jul 23 03:20, Yaakov (Cygwin/X) wrote: > On 2013-07-23 02:22, Corinna Vinschen wrote: > >On Jul 23 17:47, Ryan Johnson wrote: > >>On 07/22/2013 05:38 PM, Yaakov (Cygwin/X) wrote: > >>>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. > > > >Shouldn't we introduce an empty gcc binary archive for just this > >situation? > > This is one case where IMO genini is better than upset: > genini-generated setup.ini's don't list source-only packages in > setup's package selector, while still being available through the > "Src" option of any of its subpackages. Could upset be changed to > match, which would avoid this problem for *all* source-only > packages? I guess so, but this is one for Chris. 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: runing ./configure on gdb 7.5.50 sources
Corinna Vinschen cygwin.com> writes: > > > > > I'm using gdb-7.6.50-2 on cygwin 1.7.22-1. All freshly updated today. > > Here's my cygport file from the 64 bit GDB package: > > CYGCONF_ARGS="--disable-gdbtk --with-system-readline" Hi Corinna excellent! This worked for me (on 32bit cygwin) : ../../gdb-7.6.50-2/configure CFLAGS="-g -O0" --disable-gdbtk --with-system-readline Thanks Kris PS: now on to http://cygwin.com/frysk/bugzilla/show_bug.cgi?id=15650 -- 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
1.7.22: CTRL+C on mingw applications
Hi... Due to some odd hangs in some past versions of cywin1.dll (1.7.18 - 1.7.21) I was still using 1.7.17. Now I gave 1.7.22 a new try. The blocks seem to be resolved but well it appears that cygwin can now no longer break running standard windows/mingw tools. I am using 1.7.22 (32bit) with mintty on windows 7 Ultimate 64bit. All cygwin packages are up to date. My $CYGWIN is set to "nodosfilewarning". Pressing CTRL+C is simply ignored for mingw apps while it works for cygwin executables. When I run cywin from within a windows dos box my exes stop to work but the console than hangs until execution of the started executable has finished. stdout of the executable seem to be redirected to /dev/null after pressing CTRL+C in console window. I today tried all officially released cygwin1.dlls from 1.7.17 to 1.7.22 but all versions starting with 1.7.18 do show this problem. Have I missed something in the time between 1.7.17 and now or is this a "new" bug (I could only loosely follow the mailing list in the past months)? Thanks for your help, Roland -- 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()
I've wiped my old version of Cygwin and installed it fresh on my computer
and 1.7.21 doesn't work for me, either 32 or 64 bit. I have tried a Win
7 x86
virtual machine and it worked, on a Win 8 x86 virtual machine though I see
the same error. Therefore I guess it is a Windows 8 issue unless you are
running it?
I tried replacing the cygwin1.dll with the latest snapshots 1.7.22s x86
and that still had the fork error. I have also tried running in safe
mode and
stopping all my anti-virus software just incase that was interfering
somehow.
So I get as an output now...
Daniel@XPS15z ~
$ uname -r
1.7.22s(0.268/5/3)
Daniel@XPS15z ~
$ ./a.exe
I'm an openmp thread...
I'm an openmp thread...
I'm an openmp thread...
I'm an openmp thread...
Parent fork 1 [main] a 5832 C:\cygwin\home\Daniel\a.exe: *** fatal error
in forked process - failed
to create new win32 semaphore, currentvalue -2, Win32 error 87
However if I reduce the number of threads from 4 to 2 with:
#pragma omp parallel num_threads(2)
{
printf("I'm an openmp thread...\n");
}
it works fine, if I use 3 threads then the error comes back.
Interestingly the the value of currentvalue
changes each time I run the program if I use 4 or more threads, if I use
3 then it is always -1.
Looking at the source in thread.cc _fixup_after_fork() the win32 error
87 is ERROR_INVALID_PARAMETER
which is due to currentvalue < 0.
My only guess is that there is a race condition on the currentvalue--
operations perhaps?
Thanks,
Daniel
On 22/07/2013 09:06, Corinna Vinschen wrote:
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
--
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: Basic gcc compilation on cygwin64
On 7/23/2013 07:51, Richard H Lee wrote:
> 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.
>
Try rerunning setup again, there was a mistake in the w32api-runtime -1
release. -2 should have this fixed.
signature.asc
Description: OpenPGP digital signature
Re: Mingw build problem for TCL
I have had problems with file permissions myself - in my case editing a file that is part of a fairly large project may cause build errors later on, when such a file is copied during the build process, because the Windows permissions are translated into "---". It may very well be that you are dealing with something similar. Regards, Arjen 2013/7/23 Jonathan Kelly : >> 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 > -- 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: Basic gcc compilation on cygwin64
On 23/07/2013 13:35, JonY wrote: Try rerunning setup again, there was a mistake in the w32api-runtime -1 release. -2 should have this fixed. Yeah, I just installed xxd 5 mins ago and I saw w32api-runtime flash up on the download bar. I figured that was the package and gave gcc another shot. It compiles fine now. -- 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: 1.7.22: CTRL+C on mingw applications
On Jul 23 12:51, Roland Schwingel wrote:
> Hi...
>
> Due to some odd hangs in some past versions of cywin1.dll (1.7.18 -
> 1.7.21) I was still using 1.7.17. Now I gave 1.7.22 a new try. The
> blocks seem to be resolved but well it appears that cygwin can now
> no longer break running standard windows/mingw tools.
>
> I am using 1.7.22 (32bit) with mintty on windows 7 Ultimate 64bit.
> All cygwin packages are up to date. My $CYGWIN is set to
> "nodosfilewarning".
>
> Pressing CTRL+C is simply ignored for mingw apps while it works for
> cygwin executables.
I would check for BLODA. I just tried it with 1.7.22/32 bit on Windows
8/64. I can break a system ping just fine, and I created a simple Mingw
application. I tested them from bash and tcsh in mintty as well as in a
Windows console with identical behaviour:
$ ping www.wdr.de
Pinging e2636.g.akamaiedge.net [2.19.250.210] with 32 bytes of data:
Reply from 2.19.250.210: bytes=32 time=59ms TTL=59
Ping statistics for 2.19.250.210:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 59ms, Maximum = 59ms, Average = 59ms
Control-C
$ cat > x.c <
#include
int main(void)
{
for (;;)
{
printf ("Hallo\n");
fflush (stdout);
Sleep (1000L);
}
return 0;
}
EOF
$ i686-w64-mingw32-gcc -g -o x x.c
$ ./x
Hallo
Hallo
[Press ^C]
$
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: Win32 error in C program using openmp and fork()
On 7/23/2013 8:28 AM, Daniel Brown wrote: I've wiped my old version of Cygwin and installed it fresh on my computer and 1.7.21 doesn't work for me, either 32 or 64 bit. I have tried a Win 7 x86 virtual machine and it worked, on a Win 8 x86 virtual machine though I see the same error. Therefore I guess it is a Windows 8 issue No, I can reproduce it consistently on my Windows 7 system, running 1.7.22, on both 32-bit and 64-bit. It also just happened to me while running emacs. This is not reproducible, but it was previously reported by another user: http://cygwin.com/ml/cygwin/2013-07/msg00198.html On 64-bit, the output is $ ./openmp-test.exe I'm an openmp thread... I'm an openmp thread... I'm an openmp thread... I'm an openmp thread... Parent fork 0 [main] openmp-test 6640 C:\cygwin64\home\kbrown\openmp-test.exe: *** fatal error in forked process - failed to create new win32 semaphore, currentvalue 4294967294, Win32 error 87 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: Win32 error in C program using openmp and fork()
On Jul 23 13:28, Daniel Brown wrote:
> I've wiped my old version of Cygwin and installed it fresh on my computer
> and 1.7.21 doesn't work for me, either 32 or 64 bit. I have tried a
> Win 7 x86
> virtual machine and it worked, on a Win 8 x86 virtual machine though I see
> the same error. Therefore I guess it is a Windows 8 issue unless you are
> running it?
Yes, Windows 8/64 is my major test machine.
>
> I tried replacing the cygwin1.dll with the latest snapshots 1.7.22s x86
> and that still had the fork error. I have also tried running in safe
> mode and
> stopping all my anti-virus software just incase that was interfering
> somehow.
> So I get as an output now...
>
> Daniel@XPS15z ~
> $ uname -r
> 1.7.22s(0.268/5/3)
>
> Daniel@XPS15z ~
> $ ./a.exe
> I'm an openmp thread...
> I'm an openmp thread...
> I'm an openmp thread...
> I'm an openmp thread...
> Parent fork 1 [main] a 5832 C:\cygwin\home\Daniel\a.exe: *** fatal
> error in forked process - failed
> to create new win32 semaphore, currentvalue -2, Win32 error 87
>
> However if I reduce the number of threads from 4 to 2 with:
>
> #pragma omp parallel num_threads(2)
> {
> printf("I'm an openmp thread...\n");
> }
Ah, now there's something different. If I set the number of threads to
4, I can reproduce this problem almost every try with currentvalue -2,
occassionally with currentvalue -1.
> Looking at the source in thread.cc _fixup_after_fork() the win32
> error 87 is ERROR_INVALID_PARAMETER
> which is due to currentvalue < 0.
>
> My only guess is that there is a race condition on the
> currentvalue-- operations perhaps?
Apparently. I investigate...
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: Win32 error in C program using openmp and fork()
I've wiped my old version of Cygwin and installed it fresh on my computer and
1.7.21 doesn't work for me, either 32 or 64 bit. I have tried a Win 7 x86
virtual machine and it worked, on a Win 8 x86 virtual machine though I see the
same error. Therefore I guess it is a Windows 8 issue unless you are running it?
I tried replacing the cygwin1.dll with the latest snapshots 1.7.22s x86 and
that still had the fork error. I have also tried running in safe mode and
stopping all my anti-virus software just incase that was interfering somehow.
So I get as an output now...
Daniel@XPS15z ~
$ uname -r
1.7.22s(0.268/5/3)
Daniel@XPS15z ~
$ ./a.exe
I'm an openmp thread...
I'm an openmp thread...
I'm an openmp thread...
I'm an openmp thread...
Parent fork 1 [main] a 5832 C:\cygwin\home\Daniel\a.exe: *** fatal error
in forked process - failed
to create new win32 semaphore, currentvalue -2, Win32 error 87
However if I reduce the number of threads from 4 to 2 with:
#pragma omp parallel num_threads(2)
{
printf("I'm an openmp thread...\n");
}
it works fine, if I use 3 threads then the error comes back. Interestingly the
the value of currentvalue changes each time I run the program if I use 4 or
more threads, if I use 3 then it is always -1.
Looking at the source in thread.cc _fixup_after_fork() the win32 error 87 is
ERROR_INVALID_PARAMETER which is due to currentvalue < 0.
My only guess is that there is a race condition on the currentvalue--
operations perhaps?
Thanks,
Daniel
--
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 23 15:08, Corinna Vinschen wrote:
> On Jul 23 13:28, Daniel Brown wrote:
> > and that still had the fork error. I have also tried running in safe
> > mode and
> > stopping all my anti-virus software just incase that was interfering
> > somehow.
> > So I get as an output now...
> >
> > Daniel@XPS15z ~
> > $ uname -r
> > 1.7.22s(0.268/5/3)
> >
> > Daniel@XPS15z ~
> > $ ./a.exe
> > I'm an openmp thread...
> > I'm an openmp thread...
> > I'm an openmp thread...
> > I'm an openmp thread...
> > Parent fork 1 [main] a 5832 C:\cygwin\home\Daniel\a.exe: *** fatal
> > error in forked process - failed
> > to create new win32 semaphore, currentvalue -2, Win32 error 87
> >
> > However if I reduce the number of threads from 4 to 2 with:
> >
> > #pragma omp parallel num_threads(2)
> > {
> > printf("I'm an openmp thread...\n");
> > }
>
> Ah, now there's something different. If I set the number of threads to
> 4, I can reproduce this problem almost every try with currentvalue -2,
> occassionally with currentvalue -1.
>
> > Looking at the source in thread.cc _fixup_after_fork() the win32
> > error 87 is ERROR_INVALID_PARAMETER
> > which is due to currentvalue < 0.
> >
> > My only guess is that there is a race condition on the
> > currentvalue-- operations perhaps?
>
> Apparently. I investigate...
Yes, there was a race condition in setting the value of the semaphore
private "currentvalue" member. The only reason to keep track of the
value is to allow _fixup_after_fork to set the right value, but here the
race comes into play. I redesigned this part so that it only sets
currentvalue once, right from fork itself, to propagate the correct
value to the child process.
I'm just building new 32 and 64 bit snapshots. They should be available
on http://cygwin.com/snapshots/ in an hour at the latest. Please give
it a try.
Thanks,
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: [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). Sorry, this was my fault. I accidentally mangled your patch when I took PREFIX out. I fixed that, and it works fine in x86 now. So, I'll put a new release out shortly that includes your patch. Nice work, and thank you. Andrew -- 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 23 16:18, Corinna Vinschen wrote:
> On Jul 23 15:08, Corinna Vinschen wrote:
> > On Jul 23 13:28, Daniel Brown wrote:
> > > and that still had the fork error. I have also tried running in safe
> > > mode and
> > > stopping all my anti-virus software just incase that was interfering
> > > somehow.
> > > So I get as an output now...
> > >
> > > Daniel@XPS15z ~
> > > $ uname -r
> > > 1.7.22s(0.268/5/3)
> > >
> > > Daniel@XPS15z ~
> > > $ ./a.exe
> > > I'm an openmp thread...
> > > I'm an openmp thread...
> > > I'm an openmp thread...
> > > I'm an openmp thread...
> > > Parent fork 1 [main] a 5832 C:\cygwin\home\Daniel\a.exe: *** fatal
> > > error in forked process - failed
> > > to create new win32 semaphore, currentvalue -2, Win32 error 87
> > >
> > > However if I reduce the number of threads from 4 to 2 with:
> > >
> > > #pragma omp parallel num_threads(2)
> > > {
> > > printf("I'm an openmp thread...\n");
> > > }
> >
> > Ah, now there's something different. If I set the number of threads to
> > 4, I can reproduce this problem almost every try with currentvalue -2,
> > occassionally with currentvalue -1.
> >
> > > Looking at the source in thread.cc _fixup_after_fork() the win32
> > > error 87 is ERROR_INVALID_PARAMETER
> > > which is due to currentvalue < 0.
> > >
> > > My only guess is that there is a race condition on the
> > > currentvalue-- operations perhaps?
> >
> > Apparently. I investigate...
>
> Yes, there was a race condition in setting the value of the semaphore
> private "currentvalue" member. The only reason to keep track of the
> value is to allow _fixup_after_fork to set the right value, but here the
> race comes into play. I redesigned this part so that it only sets
> currentvalue once, right from fork itself, to propagate the correct
> value to the child process.
>
> I'm just building new 32 and 64 bit snapshots. They should be available
> on http://cygwin.com/snapshots/ in an hour at the latest. Please give
> it a try.
Both snapshots are up. Test away.
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: emacs problem
On 7/11/2013 10:11 AM, Corinna Vinschen wrote: On Jul 11 09:34, J. David Boyd wrote: Ken Brown writes: On 7/10/2013 5:10 PM, Christopher Faylor wrote: Thanks. It's also possible that this isn't a Cygwin problem. There are known race conditions between emacs-24.3 and glib, which have been fixed in the newer version of emacs that I asked Dave to test. Dave, instead of trying the new emacs right away, would you be willing to install the cygwin snapshot and see if that fixes the problem? If not, could you report the error message and then try the new emacs? Thanks. Ken THanks, sure, no problem. Where do I get the latest snapshot from? Setup and all updates, or the EXP setting? http://cygwin.com/snapshots/ Dave, This should be fixed now in the latest snapshot (2013-07-23). See http://cygwin.com/ml/cygwin/2013-07/msg00481.html 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
Upgrade Challenges, ssh login failure after update
I just updated Cygwin to the latest version from one that had been installed in maybe 2009... old. During the update process there was a note to go to cygwin.com to see what had changed in the new version that might affect me, but in the "upgrade" or the "faq" area I could find nothing warning me about anything specific. I was installing this on a box 2000 miles away where I tunnel remote desktop through ssh. Thank goodness I took down the firewall before I rebooted, because ssh no longer worked after a reboot, and I had to make a direct remote desktop connection to the machine before I got ssh up and running. I'm sending this mail to warn other users trying to upgrade sshd... After the upgrade I got login failures even though sshd service was running. I Googled and Googled, but I couldn't find an answer; port was open, ssh was up, and ssh connections worked fine (even to the external IP) from the local cygwin ssh, but not from a remote ssh. Logging locally didn't help, ssh -vvv remotely didn't help. FINALLY I figured it out, it was that the USERNAMEs are now case sensitive!!! So "administrator" fails but "Administrator" succeeds. I read somewhere I can fix this now by going back and editing /etc/passwd, but I haven't tried that yet; right now I'm just happy to have my firewall back up and tunneling remote desktop through ssh again. (I did a ssh-host-config in the process of debugging but I don't think I needed to.) Since I couldn't find this answer I'm sending it now to the list, hopefully the next person that runs into this will find it. -- 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: [ANNOUNCEMENT] Updated: http://cygwin.com/setup*.exe
On 22/07/2013 16:23, Christopher Faylor wrote: > We have updated the setup.exe executables on cygwin.com in preparation > for the upcoming release of Cygwin 1.7.22. > ... I hit a couple of problems using the new 32-bit setup yesterday - during which it managed to break my installation. System is XP SP3 32-bit - no BLODA issues encountered before. I usually have no problems upgrading Cygwin - I normally stop any Cygwin processes if necessary to ensure the update can complete without a reboot, but even if I don't the fixup-on-reboot mechanism works fine. However, setup V2.814 (32 bit) didn't behave as well - it popped up a dialog box warning of processes in use, but no processes were listed. Clicking on "Stop processes" didn't stop any processes, and the dialog was redisplayed. Clicking on "Continue" allowed the install to complete, but after a reboot I had a broken installation - investigation showed several dlls (including cygwin1.dll) in /usr/bin and an exe in /usr/sbin had not been updated, and the new ones were still there with extension .new. Manually deleting and renaming fixed this issue - but clearly this shouldn't have happened! A look at setup.log showed nothing amiss - setup reported that it couldn't update the dlls/exes, and that a reboot was necessary - so it should have scheduled the renames for reboot. A second problem I hit was that I had a system crash (unrelated to Cygwin) while setup was downloading updated packages. This lost cached disk data, so when setup was restarted it detected several corrupt packages (MD5 sumchecks failed). It offered the choice of installing anyway or omitting the affected packages - but I couldn't see a way to make setup re-download them. Selecting reinstall didn't work - that would reinstall the old version but updating again complained of a corrupt new package (and choosing the install anyway option is *not* a good idea as it tries to use the corrupt package and fails to unpack). Manually deleting the affected packages from my install directory fixed this - but am I missing a better way? I also had a problem with cygports - I use the setup -K option - and yesterday the cygports site was missing the setup .ini/.bz2 files - but today I see that's fixed :-) -- Cliff -- 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 Tue, Jul 23, 2013 at 03:20:11AM -0500, Yaakov (Cygwin/X) wrote: >On 2013-07-23 02:22, Corinna Vinschen wrote: >> On Jul 23 17:47, Ryan Johnson wrote: >>> On 07/22/2013 05:38 PM, Yaakov (Cygwin/X) wrote: 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. >> >> Shouldn't we introduce an empty gcc binary archive for just this >> situation? > >This is one case where IMO genini is better than upset: genini-generated >setup.ini's don't list source-only packages in setup's package selector, >while still being available through the "Src" option of any of its >subpackages. Could upset be changed to match, which would avoid this >problem for *all* source-only packages? Why not just rename the package "gcc-src" to make it clear what's going on? 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134
On 7/23/2013 12:40 AM, Yaakov (Cygwin/X) wrote: On 2013-07-22 19:52, Kenneth Wolcott wrote: Postinstall errors: Package: xinit xinit.sh exit code 134 This is from a SIGABRT in mkshortcut. Chuck? From xinit.sh: /usr/bin/mkshortcut $CYGWINFORALL -P . where $CYGWINFORALL is probably -A This is the same bug as this one: http://www.cygwin.com/ml/cygwin/2013-01/msg00261.html I never replied directly to that message (I was still AWOL at the time), but I later referenced it here: http://cygwin.com/ml/cygwin/2013-06/msg00214.html I believe your report has to do with error handling when attempting to modify the All User's Desktop, when you don't actually retain the elevated permissions necessary to do so. However, mkshortcut shouldn't *hang* in that case, so it's definitely mkshortcut bug. I just haven't had the cycles to track it down and fix it. PTC... ...and that's still true. Is there are way for setup.exe to delegate its elevated credentials down to /bin/bash, and thence to mkshortcut.exe? Otherwise, even the *fix* for this bug will just make it not hang or crash; it will still fail to modify the all-users start menu/desktop. Do we need to extend setup.exe *itself* to accept instructions from packages somehow (maybe in the setup.ini?) so that setup.exe *itself* can do some of these privilege-requiring tasks? -- 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134
On Jul 23 14:14, Charles Wilson wrote: > On 7/23/2013 12:40 AM, Yaakov (Cygwin/X) wrote: > >On 2013-07-22 19:52, Kenneth Wolcott wrote: > >>Postinstall errors: > >> > >>Package: xinit > >> xinit.sh exit code 134 > > > >This is from a SIGABRT in mkshortcut. Chuck? > > From xinit.sh: > /usr/bin/mkshortcut $CYGWINFORALL -P . > where $CYGWINFORALL is probably -A > > This is the same bug as this one: > http://www.cygwin.com/ml/cygwin/2013-01/msg00261.html > > I never replied directly to that message (I was still AWOL at the > time), but I later referenced it here: > http://cygwin.com/ml/cygwin/2013-06/msg00214.html > > >I believe your report has to do with error handling when attempting > >to modify the All User's Desktop, when you don't actually retain the > >elevated permissions necessary to do so. > > > >However, mkshortcut shouldn't *hang* in that case, so it's definitely > >mkshortcut bug. I just haven't had the cycles to track it down and > >fix it. PTC... > > ...and that's still true. Is there are way for setup.exe to > delegate its elevated credentials down to /bin/bash, and thence to > mkshortcut.exe? Otherwise, even the *fix* for this bug will just > make it not hang or crash; it will still fail to modify the > all-users start menu/desktop. Setup does not give up any of it's permissions when starting the postinstall scripts via CreateProcess. The scripts have the same permissions as setup itself, which makes a lot of sense if you think about it. Missing permissions to change system dirs should only occur if setup has been started as non-admin, or if the UAC installer recognition has been switched off (affects only the 32 bit version). 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: emacs problem
Ken Brown writes: > On 7/11/2013 10:11 AM, Corinna Vinschen wrote: >> On Jul 11 09:34, J. David Boyd wrote: >>> Ken Brown writes: >>> On 7/10/2013 5:10 PM, Christopher Faylor wrote: Thanks. It's also possible that this isn't a Cygwin problem. There are known race conditions between emacs-24.3 and glib, which have been fixed in the newer version of emacs that I asked Dave to test. Dave, instead of trying the new emacs right away, would you be willing to install the cygwin snapshot and see if that fixes the problem? If not, could you report the error message and then try the new emacs? Thanks. Ken >>> >>> THanks, sure, no problem. Where do I get the latest snapshot from? Setup >>> and >>> all updates, or the EXP setting? >> >> http://cygwin.com/snapshots/ > > Dave, > > This should be fixed now in the latest snapshot (2013-07-23). See > > http://cygwin.com/ml/cygwin/2013-07/msg00481.html > > Ken Great, thanks. I'll get it right away and try it out for a day or so, then report back here. 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134
On 7/23/2013 2:46 PM, Corinna Vinschen wrote: On Jul 23 14:14, Charles Wilson wrote: I believe your report has to do with error handling when attempting to modify the All User's Desktop, when you don't actually retain the elevated permissions necessary to do so. Is there are way for setup.exe to delegate its elevated credentials down to /bin/bash, and thence to mkshortcut.exe? Otherwise, even the *fix* for this bug will just make it not hang or crash; it will still fail to modify the all-users start menu/desktop. Setup does not give up any of it's permissions when starting the postinstall scripts via CreateProcess. The scripts have the same permissions as setup itself, which makes a lot of sense if you think about it. Missing permissions to change system dirs should only occur if setup has been started as non-admin, or if the UAC installer recognition has been switched off (affects only the 32 bit version). But even if /bin/bash is elevated, it doesn't follow that any of the tools launched within a script -- via cygwin's fork/exec method -- ALSO retain that elevation. Does it? -- 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134
On Jul 23 15:08, Charles Wilson wrote: > On 7/23/2013 2:46 PM, Corinna Vinschen wrote: > >On Jul 23 14:14, Charles Wilson wrote: > >>>I believe your report has to do with error handling when attempting > >>>to modify the All User's Desktop, when you don't actually retain the > >>>elevated permissions necessary to do so. > > >>Is there are way for setup.exe to > >>delegate its elevated credentials down to /bin/bash, and thence to > >>mkshortcut.exe? Otherwise, even the *fix* for this bug will just > >>make it not hang or crash; it will still fail to modify the > >>all-users start menu/desktop. > > > >Setup does not give up any of it's permissions when starting the > >postinstall scripts via CreateProcess. The scripts have the same > >permissions as setup itself, which makes a lot of sense if you think > >about it. Missing permissions to change system dirs should only occur > >if setup has been started as non-admin, or if the UAC installer > >recognition has been switched off (affects only the 32 bit version). > > But even if /bin/bash is elevated, it doesn't follow that any of the > tools launched within a script -- via cygwin's fork/exec method -- > ALSO retain that elevation. > > Does it? Yes, it does. CreateProcess propagates its own user token untouched. Weird question. Did you ever start an elevated shell and lost your admin permissions in a child process? If that would occur, nothing would work right in an admin shell. Even the `id' call would not show the admins group in your supplementary group list. 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: emacs problem
da...@adboyd.com (J. David Boyd) writes: > Ken Brown writes: > >>> http://cygwin.com/snapshots/ >> >> Dave, >> >> This should be fixed now in the latest snapshot (2013-07-23). See >> >> http://cygwin.com/ml/cygwin/2013-07/msg00481.html >> >> Ken > > Great, thanks. I'll get it right away and try it out for a day or so, then > report back here. > > Dave I'm running it now, so far so good. I'll try everything I can think of, which is mostly just using org mode to track my work, and gnus for checking newsgroups. Usually takes no more than 1 hour or so for it to break. Thanks, 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: setup-x86_64: postinstall errors: Package bash 1, Package a2ps 2 and xinit 134
On 2013-07-23 03:59, Corinna Vinschen wrote: On Jul 23 03:27, Yaakov (Cygwin/X) wrote: On 2013-07-23 02:21, Corinna Vinschen wrote: On Jul 22 23:40, Yaakov (Cygwin/X) wrote: echo letter > /etc/papersize I'd prefer `echo a4 > /etc/papersize' ;) I suppose you would. :-) Any idea how to provide a sane default that most people on both sides of the pond would be happy with? We don't support LC_PAPER so we also don't have this information in some DB. So which Thursday isn't booked yet? :-) Just use letter and let us europeans with their weird paper formats handle this manually. I suppose "weird" is a matter of perspective, but I'll proceed as you suggest. Unless you think this is worth (ab)using a setup.hint message: tag? 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 2013-07-23 11:16, Christopher Faylor wrote: On Tue, Jul 23, 2013 at 03:20:11AM -0500, Yaakov (Cygwin/X) wrote: This is one case where IMO genini is better than upset: genini-generated setup.ini's don't list source-only packages in setup's package selector, while still being available through the "Src" option of any of its subpackages. Could upset be changed to match, which would avoid this problem for *all* source-only packages? Why not just rename the package "gcc-src" to make it clear what's going on? gcc is only one example; many packages (most being library-only) have a source-only "main" package. Not listing them while still allowing Src (as genini does) makes things very clear IMHO. 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: Upgrade Challenges, ssh login failure after update
Stefan Lisowski writes: > I just updated Cygwin to the latest version from one that had been > installed in maybe 2009... old. > > During the update process there was a note to go to cygwin.com to see > what had changed in the new version that might affect me, but in the > "upgrade" or the "faq" area I could find nothing warning me about > anything specific. > > I was installing this on a box 2000 miles away where I tunnel remote > desktop through ssh. Thank goodness I took down the firewall before I > rebooted, because ssh no longer worked after a reboot, and I had to > make a direct remote desktop connection to the machine before I got > ssh up and running. > > I'm sending this mail to warn other users trying to upgrade > sshd... After the upgrade I got login failures even though sshd > service was running. I Googled and Googled, but I couldn't find an > answer; port was open, ssh was up, and ssh connections worked fine > (even to the external IP) from the local cygwin ssh, but not from a > remote ssh. Logging locally didn't help, ssh -vvv remotely didn't > help. FINALLY I figured it out, it was that the USERNAMEs are now case > sensitive!!! So "administrator" fails but "Administrator" succeeds. I > read somewhere I can fix this now by going back and editing > /etc/passwd, but I haven't tried that yet; right now I'm just happy to > have my firewall back up and tunneling remote desktop through ssh > again. (I did a ssh-host-config in the process of debugging but I > don't think I needed to.) > > Since I couldn't find this answer I'm sending it now to the list, > hopefully the next person that runs into this will find it. Interesting. I'd just always assumed that usernames have always been case sensitive. Just used to Linux more than Windows, I guess. Glad you figured it out! -- 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: libpaper-1.1.24-2
The following packages have been updated for both arches: * libpaper1-1.1.24-2 * libpaper-common-1.1.24-2 * libpaper-devel-1.1.24-2 * paperconf-1.1.24-2 (replaces libpaper-bin) The libpaper paper-handling library automates recognition of many different paper types and sizes for programs that need to deal with printed output. This release changes the packaging scheme in order to provide a default /etc/papersize configuration of "letter", as some programs (notably a2ps) may require a configuration to be present. Those living outside North America may wish to change this to "a4" (without the quotes); see paperconf(1), papersize(5), and paperconfig(8) for details. -- Yaakov Cygwin/X 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@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. -- 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: Regression with 1.7.20-1
Christopher Faylor cygwin.com> writes: > There is no reason to be nervous about installing snapshots if you think > a new release will solve a problem. A snapshot potentially always > equals a new release. Snapshots never break things so severely that you > can't recover by just reinstalling cygwin. I checked out the FAQ on snapshot installation http://www.cygwin.com/faq.html#faq.setup.snapshots and it looks to be enough pain that I want to stick with setup.exe, if at all possible. (I custom install several extra packages beyond the base installation, but don't want to install all, and I really like how setup.exe has memory of that.) > And, yes, you should follow cygwin or cygwin-announce for update announcements. 1.7.21 came out last week http://cygwin.com/ml/cygwin-announce/2013-07/msg00017.html but I do not see a ctrl-c fix in it. Even better, 1.7.22 just came out yesterday http://cygwin.com/ml/cygwin-announce/2013-07/msg00030.html and I see this tantalizing bug fix: - 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 That sounds a lot like a fix for the Ctrl-C bug discussed here. I will gladly install 1.7.22 (heck, I will likely deinstall everything and try the 64 bit version) to check out if it fixes the bug if there is an easy way that I can go back to 1.7.18 using setup.exe. I am having a bit of a hard time, however, finding a mirror that has 1.7.18 and which works with setup.exe. Some candidate I tried: http://mirrors.xmission.com/cygwin/release/cygwin/ http://mirror.isoc.org.il/pub/cygwin/release/cygwin/ http://www.fruitbat.org/Cygwin/index.html#cygwinmirror Unfortunately, every time I try to run setup.exe and add one of the above mirrors I get an error message saying something about "Unable to get setup.ini". If anyone else has seen 1.7.22 fix their Ctrl-C bug, I will take your word for it and try 1.7.22 myself. -- 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 Jul 22 23:40, Yaakov (Cygwin/X) wrote: > 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. The base-cygwin script usually creates the /dev dir. Do we have a dependency loop which let bash.sh run before base-cygwin? > 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 I'd prefer `echo a4 > /etc/papersize' ;) > >Package: xinit > > xinit.sh exit code 134 > > This is from a SIGABRT in mkshortcut. Chuck? 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: 64-bit gcc-4.8.1 package installs source instead
On Jul 23 17:47, Ryan Johnson wrote: > 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. Shouldn't we introduce an empty gcc binary archive for just this situation? 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
No crypt.h for cygwin64?
I wanted to compile the WWW::Mechanize Perl library, which looked for crypt.h then could not find it. I installed the crypt-1.1-1 library but it was not there either. I ended up copying crypt.h from /usr/include in my 32-bit Cygwin installation to the same directory in my 64-bit Cygwin installation. That seemed to work OK. - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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
Rxvt font cycling without numpad
How can I cycle through my fonts in rxvt (non-X11 version) if I don't have a numeric keypad? The manpage mentions bigfont_key and smallfont_key "if enabled", but I haven't been successful getting them to do anything. Perhaps I need to recompile rxvt and enable that option? Thanks for any suggestions! -- Josh Litherland (j...@temp123.org) -- 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: No crypt.h for cygwin64?
On 2013-07-23 19:09, Jim Reisert AD1C wrote: I wanted to compile the WWW::Mechanize Perl library, which looked for crypt.h then could not find it. I installed the crypt-1.1-1 library but it was not there either. The crypt package provides just crypt(1); you need libcrypt-devel for the header and link library, and libcrypt0 for the DLL. 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: Rxvt font cycling without numpad
Greetings, Josh Litherland! > How can I cycle through my fonts in rxvt (non-X11 version) if I don't > have a numeric keypad? The manpage mentions bigfont_key and > smallfont_key "if enabled", but I haven't been successful getting them > to do anything. Perhaps I need to recompile rxvt and enable that > option? As far as I recall, rxvt is not maintained anymore. You're advised to switch to mintty or xterm, whichever is closer for your needs. mintty, which is largely based off the PuTTY codebase, is the current default terminal for new Cygwin installations. -- WBR, Andrey Repin (anrdae...@freemail.ru) 24.07.2013, <08:51> 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: 64-bit gcc-4.8.1 package installs source instead
On Tue, Jul 23, 2013 at 02:54:29PM -0500, Yaakov (Cygwin/X) wrote: >On 2013-07-23 11:16, Christopher Faylor wrote: >> On Tue, Jul 23, 2013 at 03:20:11AM -0500, Yaakov (Cygwin/X) wrote: >>> This is one case where IMO genini is better than upset: genini-generated >>> setup.ini's don't list source-only packages in setup's package selector, >>> while still being available through the "Src" option of any of its >>> subpackages. Could upset be changed to match, which would avoid this >>> problem for *all* source-only packages? >> >> Why not just rename the package "gcc-src" to make it clear what's going >> on? > >gcc is only one example; many packages (most being library-only) have a >source-only "main" package. Not listing them while still allowing Src >(as genini does) makes things very clear IMHO. Yes, I got that you like the probable bug that caused genini to not list these packages. The fact that there are multiple packages with this issue isn't really an advertisement for clarity. "I'm looking for the source for gcc but the only thing I could find was the source for gcc-java" isn't really very clear. Nor is the sdesc for gcc which says "GNU Compiler Collection". That's just misleading. 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: No crypt.h for cygwin64?
> The crypt package provides just crypt(1); you need libcrypt-devel for the > header and link library, and libcrypt0 for the DLL. Thanks, Yaakov. I don't see that package. In 64-bit setup, I found: cygwin64-crypt cygwin64-libgcrypt libgcrypt-devel libmcrypt-devel Which of these packages most closely matchese libcrypt-devel? -- Jim Reisert AD1C, , http://www.ad1c.us -- 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: No crypt.h for cygwin64?
Greetings, Jim Reisert AD1C! >> The crypt package provides just crypt(1); you need libcrypt-devel for the >> header and link library, and libcrypt0 for the DLL. > Thanks, Yaakov. I don't see that package. In 64-bit setup, I found: 64-bit Cygwin isn't ready for wide deployment, it is in test state and lacking a big number of packages. (Which you can easily see from analyzing of setup.ini for both versions.) > cygwin64-crypt > cygwin64-libgcrypt > libgcrypt-devel > libmcrypt-devel > Which of these packages most closely matchese libcrypt-devel? -- WBR, Andrey Repin (anrdae...@freemail.ru) 24.07.2013, <09:53> 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: No crypt.h for cygwin64?
On Wed, Jul 24, 2013 at 09:56:25AM +0400, Andrey Repin wrote: >Greetings, Jim Reisert AD1C! > >>> The crypt package provides just crypt(1); you need libcrypt-devel for the >>> header and link library, and libcrypt0 for the DLL. > >> Thanks, Yaakov. I don't see that package. In 64-bit setup, I found: > >64-bit Cygwin isn't ready for wide deployment, it is in test state and lacking >a big number of packages. (Which you can easily see from analyzing of setup.ini >for both versions.) It is not in test state but, as Corinna's announcement mentioned, it *is* lacking some packages. 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: No crypt.h for cygwin64?
On 2013-07-24 00:14, Jim Reisert AD1C wrote: The crypt package provides just crypt(1); you need libcrypt-devel for the header and link library, and libcrypt0 for the DLL. Thanks, Yaakov. I don't see that package. In 64-bit setup, I found: cygwin64-crypt cygwin64-libgcrypt libgcrypt-devel libmcrypt-devel Which of these packages most closely matchese libcrypt-devel? None of the above; libcrypt-devel is the package you need, and it is in the x86_64 distro. 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: [PATCH] Fix optional variables in libargp
Hello! > Sorry, this was my fault. I accidentally mangled your patch when I > took PREFIX out. I fixed that, and it works fine in x86 now. Good. Please don't forget that packages which make use of libargp (if there are any) have to be recompiled against new argp.h in order to take advantage of the fix. 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
