configure --prerfix=/

2012-05-02 Thread Fedin Pavel
 Supplying prefix=/ to configure script causes it to lock up. It 
doesn't output any single line, just freezes. Even Ctrl-C doesn't help.
 I know this is maybe unusual, but i really know why i want to do it. 
And, in fact, this is a legitimate operation. So, i consider this to be 
a bug.


--
 Kind regards
 Pavel Fedin
 Expert engineer, Samsung Moscow research center


--
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: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)

2012-05-02 Thread Ryan Johnson

On 02/05/2012 1:16 PM, Ryan Johnson wrote:

On 02/05/2012 9:55 AM, Ken Brown wrote:

On 4/30/2012 11:52 PM, Ryan Johnson wrote:

On 30/04/2012 10:08 PM, Ken Brown wrote:

On 4/30/2012 9:07 PM, Ryan Johnson wrote:

On 30/04/2012 8:48 PM, Ryan Johnson wrote:

On 30/04/2012 4:08 PM, Ken Brown wrote:

Test releases of the emacs, emacs-X11, and emacs-el packages
(24.0.96-1) are now available. This is a pretest for the upcoming
release of emacs-24.1.

Emacs users are encouraged to try it and report any problems to the
cygwin mailing list.

I'm experiencing regular seg faults, often while using gdb but not
always (switching between buffers is another big offender). I'm not
sure what other information I can provide, other than the 
EIP=610CF707

reported in the .stackdump file...

Caught one in gdb (no symbols, sadly):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8128.0x3d0]
0x010c in ?? ()
(gdb) bt
#0 0x010c in ?? ()
#1 0x0054b0ac in ?? ()
#2 0x004e4303 in ?? ()
#3 0x0054afbe in ?? ()
#4 0x004e4e96 in ?? ()
#5 0x004e5180 in ?? ()
#6 0x004dfbec in ?? ()
#7 0x610070d8 in _cygwin_exit_return () from /usr/bin/cygwin1.dll
#8 0x0003 in ?? ()
#9 0x610050dd in _cygtls::call2(unsigned long (*)(void*, void*), 
void*,

void*)
() from /usr/bin/cygwin1.dll
Backtrace stopped: Not enough registers or memory available to unwind
further

HTH... I'm reverting for now (I can re-install if you've got specific
ideas to try out)


Thanks for testing. I'll try to make debugging symbols available so
that you can get a better backtrace. It might be a few days before I
get to it.


I can still make debugging symbols available for the version I built 
if you'd like, but you'll get a more reliable backtrace from a build 
without optimization.  Would you like to build it yourself (with 
CFLAGS='-g -O0') and send a backtrace?  If so, you can get the source 
from


  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.96.tar.gz

I'm copying Eli Zaretskii, one of the Emacs developers, who might be 
able to help with debugging if you can get a useful backtrace.  
Please keep him in the CC if you reply.


By the way, you can find some good hints about debugging emacs in 
etc/DEBUG in the emacs distribution.
I've downloaded the sources and will get back to you when I've had a 
chance to build and play with them.
Figures... after using the home-built version for about 4 hours, I've 
only had one seg fault, and it was deep in Windows code somewhere 
(something about acquiring a reader lock on a file, perhaps?); gdb 
couldn't find any cygwin or emacs code to pin a stacktrace on.


The gdb-mi integration also seems to work reasonably well, with a few 
exceptions:


1. The (gdb) prompt basically never displays.

2. Breakpoints don't always jump to the source file. I could have sworn 
this worked before, but the 4h run that didn't crash definitely doesn't. 
This may have something to do with the fact that I'm loading the target 
file manually (to avoid the long-standing endless initialization 
feature/bug).


3. Breakpoints having "commands" stuck to them do not display their 
name/args when triggered, nor do some outputs for commands (such as "fr 
0") which they issue. This makes it hard to see which breakpoint a given 
output corresponds to (print still works). The same applies for 
breakpoints that just stop.


The combination of all three makes it really hard to tell when gdb 
breaks into execution. The only indication is that the status line 
changes to [breakpoint], or [interrupt] if the target program faults.


One last note: I normally use emacs in terminal mode, but couldn't do 
that inside gdb (for obvious reasons). Some of the behaviors I observed 
before -- including seg faults -- may be terminal-specific, and some of 
the new strangeness I'm pointing out now may be X11-specific... or it 
might just be the difference between -O0 and -O2.


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



libffi-devel resp., extra libffi packages?

2012-05-02 Thread Reini Urban
For the upcoming rakudo + parrot releases I'd like to have ffi.h and
maybe a libff.dll.a import library.
Maybe it's better to provide an extra libffi package because our gcc
is so much far behind.
We are currently at API rev. libffi6, version 3.0.11.

Anyone interested?

I'll do it temp. by adding the ffi.h header for our cygffi-4.dll to
the parrot build
in my src patch, needed only for building.
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.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: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)

2012-05-02 Thread Ryan Johnson

On 02/05/2012 9:55 AM, Ken Brown wrote:

On 4/30/2012 11:52 PM, Ryan Johnson wrote:

On 30/04/2012 10:08 PM, Ken Brown wrote:

On 4/30/2012 9:07 PM, Ryan Johnson wrote:

On 30/04/2012 8:48 PM, Ryan Johnson wrote:

On 30/04/2012 4:08 PM, Ken Brown wrote:

Test releases of the emacs, emacs-X11, and emacs-el packages
(24.0.96-1) are now available. This is a pretest for the upcoming
release of emacs-24.1.

Emacs users are encouraged to try it and report any problems to the
cygwin mailing list.

I'm experiencing regular seg faults, often while using gdb but not
always (switching between buffers is another big offender). I'm not
sure what other information I can provide, other than the 
EIP=610CF707

reported in the .stackdump file...

Caught one in gdb (no symbols, sadly):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8128.0x3d0]
0x010c in ?? ()
(gdb) bt
#0 0x010c in ?? ()
#1 0x0054b0ac in ?? ()
#2 0x004e4303 in ?? ()
#3 0x0054afbe in ?? ()
#4 0x004e4e96 in ?? ()
#5 0x004e5180 in ?? ()
#6 0x004dfbec in ?? ()
#7 0x610070d8 in _cygwin_exit_return () from /usr/bin/cygwin1.dll
#8 0x0003 in ?? ()
#9 0x610050dd in _cygtls::call2(unsigned long (*)(void*, void*), 
void*,

void*)
() from /usr/bin/cygwin1.dll
Backtrace stopped: Not enough registers or memory available to unwind
further

HTH... I'm reverting for now (I can re-install if you've got specific
ideas to try out)


Thanks for testing. I'll try to make debugging symbols available so
that you can get a better backtrace. It might be a few days before I
get to it.


I can still make debugging symbols available for the version I built 
if you'd like, but you'll get a more reliable backtrace from a build 
without optimization.  Would you like to build it yourself (with 
CFLAGS='-g -O0') and send a backtrace?  If so, you can get the source 
from


  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.96.tar.gz

I'm copying Eli Zaretskii, one of the Emacs developers, who might be 
able to help with debugging if you can get a useful backtrace.  Please 
keep him in the CC if you reply.


By the way, you can find some good hints about debugging emacs in 
etc/DEBUG in the emacs distribution.
I've downloaded the sources and will get back to you when I've had a 
chance to build and play with them.


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: ssh-agent sh -c ssh-add => Could not open a connection to your authentication agent

2012-05-02 Thread Christopher Faylor
On Tue, May 01, 2012 at 09:56:44PM -0400, Christopher Faylor wrote:
>On Tue, May 01, 2012 at 12:01:21PM -0600, John Hein wrote:
>>% ssh-agent sh -c ssh-add
>>Could not open a connection to your authentication agent
>
>Yep.  I broke it.  I'll fix it ASAP.

Should be fixed in the upcoming snapshot for today:

http://cygwin.com/snapshots/

It's always nice when it's just a one-line change.

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



Spital nou de pediatrie

2012-05-02 Thread cramer

http://www.youtube.com/watch?feature=player_embedded&v=phjGxHn3uKU
 To unsubscribe please send email to unsubscr...@cc.psd-prahova.ro

--
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: {emacs,emacs-X11,emacs-el}-24.0.96-1 (TEST)

2012-05-02 Thread Ken Brown

On 4/30/2012 11:52 PM, Ryan Johnson wrote:

On 30/04/2012 10:08 PM, Ken Brown wrote:

On 4/30/2012 9:07 PM, Ryan Johnson wrote:

On 30/04/2012 8:48 PM, Ryan Johnson wrote:

On 30/04/2012 4:08 PM, Ken Brown wrote:

Test releases of the emacs, emacs-X11, and emacs-el packages
(24.0.96-1) are now available. This is a pretest for the upcoming
release of emacs-24.1.

Emacs users are encouraged to try it and report any problems to the
cygwin mailing list.

I'm experiencing regular seg faults, often while using gdb but not
always (switching between buffers is another big offender). I'm not
sure what other information I can provide, other than the EIP=610CF707
reported in the .stackdump file...

Caught one in gdb (no symbols, sadly):

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8128.0x3d0]
0x010c in ?? ()
(gdb) bt
#0 0x010c in ?? ()
#1 0x0054b0ac in ?? ()
#2 0x004e4303 in ?? ()
#3 0x0054afbe in ?? ()
#4 0x004e4e96 in ?? ()
#5 0x004e5180 in ?? ()
#6 0x004dfbec in ?? ()
#7 0x610070d8 in _cygwin_exit_return () from /usr/bin/cygwin1.dll
#8 0x0003 in ?? ()
#9 0x610050dd in _cygtls::call2(unsigned long (*)(void*, void*), void*,
void*)
() from /usr/bin/cygwin1.dll
Backtrace stopped: Not enough registers or memory available to unwind
further

HTH... I'm reverting for now (I can re-install if you've got specific
ideas to try out)


Thanks for testing. I'll try to make debugging symbols available so
that you can get a better backtrace. It might be a few days before I
get to it.


I can still make debugging symbols available for the version I built if 
you'd like, but you'll get a more reliable backtrace from a build 
without optimization.  Would you like to build it yourself (with 
CFLAGS='-g -O0') and send a backtrace?  If so, you can get the source from


  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.96.tar.gz

I'm copying Eli Zaretskii, one of the Emacs developers, who might be 
able to help with debugging if you can get a useful backtrace.  Please 
keep him in the CC if you reply.


By the way, you can find some good hints about debugging emacs in 
etc/DEBUG in the emacs distribution.



Do you have a recipe that will reliably produce a segfault for you?
I've been using emacs-24 for months without any problems (as long as I
build without gsettings support, as I did for emacs-24.0.96-1). But I
haven't tested gdb-mi for a while.

You said you got segfaults even while not using gdb-mi. But did you
get segfaults in an emacs session in which you didn't use gdb-mi at
all in the entire session?

Good point. I probably had used gdb-mi at some point during every
session that crashed.


I just fooled around with M-x gdb a little and didn't get a crash 
(although I did see some minor annoyances involving I/O synchronization 
that I'll try to debug when I get a chance).  So be sure to let me know 
if you find a reproducible way of getting a crash, preferably starting 
with 'emacs -Q'.


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: Windows 8: commands in sh prompt are not working

2012-05-02 Thread Corinna Vinschen
On May  2 10:26, Bertrand Latinville wrote:
> Hi,
> 
> I'm using cygwin  1.7.11 on Windows 8 64 bit consumer preview
> 
> Using cygwin via the shortcut C:\cygwin\bin\mintty.exe works fine.
> 
> But I'm also using cygwin via Jenkins which call sh.exe directly.
> 
> When running sh.exe, we get the prompt but many commands are not working.
> They return immediately without echoing anything:

That's a problem in W8CP which I reported upstream and which has been
confirmed as a bug, so I assume this will work again in W8RP.

A temporary workaround is to remove the large-address awareness flag
from all Cygwin executables.


Corinna

-- 
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



Re: fesetround problem

2012-05-02 Thread Corinna Vinschen
On May  1 19:19, David Matthews wrote:
> fesetround seems to be broken in the current version of Cygwin.  It
> returns EINVAL for any argument other than FE_TONEAREST.  The
> following snippet works fine on Debian wheezy but shows a non-zero
> return in Cygwin.
> 
> #include 
> #include 
> 
> int main()
> {
> int r = fesetround(FE_TOWARDZERO);
> printf("fesetround returned %d.  Current rounding is %d\n",
>r, fegetround());
> return 0;
> }
> 
> Browsing the CVS source it looks as though the problem is the line
> in fesetround in fenv.c that says:
> 
>   if (round & ~(FE_CW_ROUND_MASK >> FE_CW_PREC_SHIFT))
> 
> I think FE_CW_PREC_SHIFT should be FE_CW_ROUND_SHIFT to match
> fegetround above.

Thanks for the report and the testcase.

Actually, the test for the input parameter should not shift it at all,
otherwise invalid input, for instance, 0xf000, would be treated as a
valid input of 0.  The fesetprec function had the same problem.  I fixed
that by explicitely only allowing the valid input range.


Thanks again,
Corinna

-- 
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



Re: look to secure cygwin email delivery

2012-05-02 Thread Gregory Machin
Lol not my idea to give users admin rites. I have 10 years worth of
bad admin to put rite, without slowing down the developers work :-(

On Wed, May 2, 2012 at 6:05 PM, Andrew DeFaria  wrote:
> On 05/01/2012 10:03 PM, Gregory Machin wrote:
>>
>> Thanks .
>> I have tests as you suggest , so long as the user does not have admin
>> privileges.
>>
>> The problem I have is most users have local admin rites on their
>> machines. Which make it difficult to secure .
>>
> Gee. I wonder where I've heard that before. Oh well.
>
> --
> Andrew DeFaria 
> Why do toasters always have a setting that burns the toast to a horrible
> crisp no one would eat?
>
>
>
> --
> 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