date:20120503


On 03/05/2012 11:38 PM, Fedin Pavel wrote:

On 03.05.2012 19:24, Christopher Faylor wrote:
Right.  I've noticed the incompleteness of elf.h from time to time 
too but
extending it would be tedious since you can't just cut/paste from a 
GPLv*

file.  Maybe one of the BSDs has something more complete these days?
 By the way, interesting question. It raises up from time to time here 
and there, but noone gives the answer...

 Is there any strict definition of "derived work"?
 The problem is: we have some #define in GPLed code. And i want to 
make some non-GPLed code interoperable. Consequently, i need the same 
#define. Exactly the our case. Of course i could copy-paste the code, 
and it would definitely be "derived work". But what if i don't 
copy-paste this code, but retype it by hands? Still a copy? Well, add 
some more cleanup. Take a piece of paper, write down all names and 
values. Drink lots of whiskey (wine, vodka) to erase own memory ;-) 
Next day take this paper and write own include. Is it still "derived 
work" ?
 But, after all, we still have only names and values, nothing more, 
and no matter how we made our version. Does "using the same name" 
automatically mean "derived work"? But in this case IMHO this as a 
nonsense. There's even an anecdote about Microsoft having to 
opensource all their stuff because their code uses GPLed "i++" 
fragment. Well, copyright infringement applies here as well, based on 
the reverse claim. :)
Well, according to the EU commission's very recent ruling, at least, you 
can't copyright APIs, which I would consider this elf stuff to be. 
IANAL, tho.


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

Licensing questions (was: [bug] elf.h incomplete)


On 03.05.2012 19:24, Christopher Faylor wrote:

Right.  I've noticed the incompleteness of elf.h from time to time too but
extending it would be tedious since you can't just cut/paste from a GPLv*
file.  Maybe one of the BSDs has something more complete these days?
 By the way, interesting question. It raises up from time to time here 
and there, but noone gives the answer...

 Is there any strict definition of "derived work"?
 The problem is: we have some #define in GPLed code. And i want to make 
some non-GPLed code interoperable. Consequently, i need the same 
#define. Exactly the our case. Of course i could copy-paste the code, 
and it would definitely be "derived work". But what if i don't 
copy-paste this code, but retype it by hands? Still a copy? Well, add 
some more cleanup. Take a piece of paper, write down all names and 
values. Drink lots of whiskey (wine, vodka) to erase own memory ;-) Next 
day take this paper and write own include. Is it still "derived work" ?
 But, after all, we still have only names and values, nothing more, and 
no matter how we made our version. Does "using the same name" 
automatically mean "derived work"? But in this case IMHO this as a 
nonsense. There's even an anecdote about Microsoft having to opensource 
all their stuff because their code uses GPLed "i++" fragment. Well, 
copyright infringement applies here as well, based on the reverse claim. :)
 So - where are limits of "derived work" ? And should this meaning be 
applied to public visible (like includes, APIs, etc) stuff at all ? 
Because if the answer is yes, this effectively forbids existence of 
alternate solutions to anything at all.

 After all, such reimplementations fall into "fair use" category.

 P.S. I would do it and submit a patch, but here at Samsung any code 
submitted upstream requires review and approval, in order to prevent 
classified information leak. This is of course possible, but this would 
be long way for such a trivial thing. You (Cygwin team) would fix it 
yourself faster.


--
 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] Test update: perl-5.14.2-1, please update your dependent packages

2012-05-03 Thread Achim Gratz

Reini Urban writes:
>> 2) If I install another module that uses LWP (HTTP::Status, for example), 
>> then I
>> also need to reinstall LWP.  Otherwise I'm getting errors like these:
>>
>> Attempt to reload LWP/Protocol/http.pm aborted.
>> Compilation failed in require at (eval 7) line 2.
>
> I could not repro this. I built HTTP::Status just fine. I'll think about it.

The build goes OK as well as the install.  It is when I then use it from
a very simple script (just perl -e 'require LWP qw( $ua request );'
is enough actually) that things fall apart.  Or trying to do the next
build with cpan(m) which fails unless you let it fall back to curl or
wget.  I first thought the reason for this was that some parts were in
site_per and the others in vendor_perl, but even when I symlinked the
two the issue was not going away.

>> Lastly, I'd much prefer if the vendor modules would be separate entities to
>> install, this would make it easier to keep proper dependencies among them.  I
>> will re-build all these modules plus some 150 more with cygport anyway 
>> (provided
>> I don't hit a roadblock), so once that works I could send you the 
>> perl-*.cygport
>> files.
>
> Sorry, too much manual work.

Tell me about it, that's why I've scripted it.  Give it a list of module
names and it gives you back the cygport files and initial setup.hint for
each, with dependencies for build and install.  For most modules that's
all that was needed, but a handful did need patches, either because they
needed extra configuration or tried to run manual tests.

> I rather prefer only one single dependency and update step than 150.

If all machines this installation is going to had internet access than
cpanm would do the job, but I'll have to be able to install onto
isolated machines.  Anyway, I can understand if you're not wanting to go
there, I can just not install perl_vendor and drop in a bundle package
that pulls in the individual modules (or rather distributions, since
cygport builds on them).

Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

--
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: Short gdb question.

2012-05-03 Thread eric_justin_al...@cfl.rr.com


Christopher Faylor wrote:

On Thu, May 03, 2012 at 10:21:07PM -0400, Reid Thompson wrote:

On 5/3/2012 7:47 PM, eric_justin_al...@cfl.rr.com wrote:

Is this the right place to suggest that gdb be upgraded for cygwin. If
not where could I suggest that? If this is an acceptable place then
can I add here that if you guys do upgrade gdb that I was hoping you
could make it a bit more detailed maybe make it to show a bit more
information about crashes. An example is that I m working with a
linked list and when the program crashes gdb prints out and only
prints out the words below this text. I am left clueless about the error.

Program received signal SIGABRT, Aborted.
0x7ffe0304 in ?? ()



Just...
download, configure, make, make install
http://ftp.gnu.org/gnu/gdb/

$ /opt/removethis/bin/gdb.exe --version
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
For bug reporting instructions, please see:
.

...and find out that the above behavior will not change in any way in the
new version of gdb.

Incidentally, I just resigned as the gdb maintainer for Windows.

Anyone else want to take on the mantle?

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


Alright if I download and compile it can I just mv gdb.exe into /bin and 
overwrite gdb.exe?


--
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: Short gdb question.

2012-05-03 Thread Christopher Faylor

On Thu, May 03, 2012 at 10:21:07PM -0400, Reid Thompson wrote:
>On 5/3/2012 7:47 PM, eric_justin_al...@cfl.rr.com wrote:
>> Is this the right place to suggest that gdb be upgraded for cygwin. If 
>> not where could I suggest that? If this is an acceptable place then 
>> can I add here that if you guys do upgrade gdb that I was hoping you 
>> could make it a bit more detailed maybe make it to show a bit more 
>> information about crashes. An example is that I m working with a 
>> linked list and when the program crashes gdb prints out and only 
>> prints out the words below this text. I am left clueless about the error.
>>
>> Program received signal SIGABRT, Aborted.
>> 0x7ffe0304 in ?? ()
>>
>>
>Just...
>download, configure, make, make install
>http://ftp.gnu.org/gnu/gdb/
>
>$ /opt/removethis/bin/gdb.exe --version
>GNU gdb (GDB) 7.4
>Copyright (C) 2012 Free Software Foundation, Inc.
>License GPLv3+: GNU GPL version 3 or later 
>
>This is free software: you are free to change and redistribute it.
>There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>and "show warranty" for details.
>This GDB was configured as "i686-pc-cygwin".
>For bug reporting instructions, please see:
>.

...and find out that the above behavior will not change in any way in the
new version of gdb.

Incidentally, I just resigned as the gdb maintainer for Windows.

Anyone else want to take on the mantle?

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: gdb problem

2012-05-03 Thread Christopher Faylor

On Thu, May 03, 2012 at 04:05:04PM -0400, Ken Brown wrote:
>On 10/23/2011 5:47 PM, Ken Brown wrote:
>> On 10/23/2011 3:04 PM, Christopher Faylor wrote:
>>> On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:
 The attached testcase illustrates a problem with `gdb -i=mi'. I've
 tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with
 several recent snapshots (including 2011-10-22).

 Under some circumstances, if gdb -i=mi is started and given several
 input lines at once, it only prints part of the output before stopping.
 I've been able to reproduce this once in a while while working
 interactively (by copying and pasting the whole bunch of input lines);
 in this case one can press Return to get the rest of the output. But
 the problem happens consistently with the attached test case, which runs
 gdb in a subprocess. One has to kill the gdb process before the main
 program exits.

 The STC runs as expected on Linux.
>>>
>>> Thanks for the STC. I had to tweak it to actually see how it was supposed
>>> to work on Linux since only a limited number of lines from the pty were
>>> being output. I've included the revised test case below.
>>>
>>> I made a simple change to Cygwin which will probably cause subtle
>>> problems somewhere down the line. At least for now it seems to make gdb
>>> operate as expected.
>>>
>>> I'm building a new snapshot now.
>>
>> Thanks, that fixes it (as well as the emacs problem that originally led
>> to this report). In case there are emacs users wondering what this is
>> about, I've been testing emacs-24, which uses gdb -i=mi instead of the
>> obsolete gdb --annotate=3 used by emacs-23.
>
>I'm replying to this old thread because the problem is back again in 
>cygwin-1.7.14-2.  I haven't checked to see exactly when it first 
>reappeared (but I'll do this if it would help.)  The same STC as before 
>exhibits the problem; I'm attaching it for convenience.

Thanks for the heads up.  This should be fixed in the next snapshot.

Incidentally, I've started putting longer explications of what I've
debugged and how I debugged it in a "DevNotes" file in the source:

http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/DevNotes?cvsroot=src

I hope to keep this up-to-date with extended rationales for why things
were done a certain way and with descriptions about the steps that I
used to track down a problem.

This file is not a substitute for comments (we've been trying to be more
diligent about commenting changes in the source) or a ChangeLog but I
hope that it will help me in the future when I have to figure out "Why
the heck did I make that 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

Re: Short gdb question.

2012-05-03 Thread Reid Thompson


On 5/3/2012 7:47 PM, eric_justin_al...@cfl.rr.com wrote:
Is this the right place to suggest that gdb be upgraded for cygwin. If 
not where could I suggest that? If this is an acceptable place then 
can I add here that if you guys do upgrade gdb that I was hoping you 
could make it a bit more detailed maybe make it to show a bit more 
information about crashes. An example is that I m working with a 
linked list and when the program crashes gdb prints out and only 
prints out the words below this text. I am left clueless about the error.


Program received signal SIGABRT, Aborted.
0x7ffe0304 in ?? ()



Just...
download, configure, make, make install
http://ftp.gnu.org/gnu/gdb/

$ /opt/removethis/bin/gdb.exe --version
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
For bug reporting instructions, please see:
.


--
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-03 Thread John Hein

Christopher Faylor wrote at 12:41 -0400 on May  2, 2012:
 > Should be fixed in the upcoming snapshot for today:

Confirmed.  Thanks.

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

Swallowed words in most section 3 man pages' SEE ALSO section

2012-05-03 Thread Jens Schweikhardt

hello, world\n

it appears that quite a number of functions in section 3 of the manual
have the following SEE ALSO section (# added where a word is missing).

$ man 3 strstr
[...]
SEE ALSO

   strstr is part of the # library.  The full documentation for # is
   maintained as a Texinfo manual.  If info and # are properly installed
   at your site, the command info will give you access to the complete manual.


This is due to missing arguments in /usr/share/man/man3/*.3.gz for
the bold face macro .B:

SH "SEE ALSO"
.B strstr
is part of the
.B
library.
The full documentation for
.B
is maintained as a Texinfo manual.  If
.B info
and
.B
are properly installed at your site, the command
.IP
.B info
.PP
will give you access to the complete manual.


For a list of man pages where this is the case (more than 400), just zgrep
for '^\.B $':
/usr/share/man/man3$ zgrep '^\.B $' *.gz|sort -u|wc
 410 4136752


Regards,

Jens
-- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

--
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: Short gdb question.


On 03/05/2012 7:47 PM, eric_justin_al...@cfl.rr.com wrote:
Is this the right place to suggest that gdb be upgraded for cygwin. If 
not where could I suggest that? If this is an acceptable place then 
can I add here that if you guys do upgrade gdb that I was hoping you 
could make it a bit more detailed maybe make it to show a bit more 
information about crashes. An example is that I m working with a 
linked list and when the program crashes gdb prints out and only 
prints out the words below this text. I am left clueless about the error.


Program received signal SIGABRT, Aborted.
0x7ffe0304 in ?? ()
This happens only with SIGABRT, AFAIK. You can work around it by setting 
a breakpoint on "_abort" which will catch the problem before the stack 
gets lost in windows-land.


For SIGSEGV (usually an unintentional error), gdb usually does the right 
thing and gives you the offending stack trace.


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

Short gdb question.

2012-05-03 Thread eric_justin_al...@cfl.rr.com

Is this the right place to suggest that gdb be upgraded for cygwin. If 
not where could I suggest that? If this is an acceptable place then can 
I add here that if you guys do upgrade gdb that I was hoping you could 
make it a bit more detailed maybe make it to show a bit more information 
about crashes. An example is that I m working with a linked list and 
when the program crashes gdb prints out and only prints out the words 
below this text. I am left clueless about the error.


Program received signal SIGABRT, Aborted.
0x7ffe0304 in ?? ()

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


On 03/05/2012 10:45 AM, Ken Brown wrote:

On 5/2/2012 5:02 PM, Ryan Johnson wrote:

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.


I find that I sometimes have to press RET before I see the prompt.  
I'll try to figure out why that's happening, but at least pressing RET 
provides a workaround in the meantime.

That worked at first, but after a while it stopped and never came back.



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


Again, pressing RET seems to avoid the endless initialization bug. 
(This was fixed once and was a Cygwin bug, so I think it won't be hard 
for me to resurrect my test case and get it fixed again.)
Not for me it doesn't. Maybe this fix you mention is patched into your 
version?





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.


I agree that there are some issues to be worked out, which may well be 
Cygwin specific.  But getting to the bottom of the crashes is a higher 
priority.



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.


What do you mean by "terminal mode"?  Do you mean you run emacs under 
mintty?  Or do you run it under xterm with the -nw switch?  And could 
you elaborate on the "obvious reasons"?  I don't see why you can't run 
emacs in a terminal under gdb; or attach to it from a different 
terminal if that's more convenient.
I usually run un

Re: gdb problem

2012-05-03 Thread Ken Brown


On 10/23/2011 5:47 PM, Ken Brown wrote:

On 10/23/2011 3:04 PM, Christopher Faylor wrote:

On Sat, Oct 22, 2011 at 04:37:55PM -0400, Ken Brown wrote:

The attached testcase illustrates a problem with `gdb -i=mi'. I've
tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with
several recent snapshots (including 2011-10-22).

Under some circumstances, if gdb -i=mi is started and given several
input lines at once, it only prints part of the output before stopping.
I've been able to reproduce this once in a while while working
interactively (by copying and pasting the whole bunch of input lines);
in this case one can press Return to get the rest of the output. But
the problem happens consistently with the attached test case, which runs
gdb in a subprocess. One has to kill the gdb process before the main
program exits.

The STC runs as expected on Linux.


Thanks for the STC. I had to tweak it to actually see how it was supposed
to work on Linux since only a limited number of lines from the pty were
being output. I've included the revised test case below.

I made a simple change to Cygwin which will probably cause subtle
problems somewhere down the line. At least for now it seems to make gdb
operate as expected.

I'm building a new snapshot now.


Thanks, that fixes it (as well as the emacs problem that originally led
to this report). In case there are emacs users wondering what this is
about, I've been testing emacs-24, which uses gdb -i=mi instead of the
obsolete gdb --annotate=3 used by emacs-23.


I'm replying to this old thread because the problem is back again in 
cygwin-1.7.14-2.  I haven't checked to see exactly when it first 
reappeared (but I'll do this if it would help.)  The same STC as before 
exhibits the problem; I'm attaching it for convenience.


Ken

#include 
#include 
#include 
#include 
#include 
#include 

void get_output (int fd);

int
main (int argc, const char **argv) 
{
  int master;
  pid_t pid;

  if ((pid = forkpty (&master, NULL, NULL, NULL)) < 0)
{
  perror ("forkpty");
  exit (1);
}
  /* child */
  if (pid == 0) 
{
  const char *av[100];
  // putenv ("HOME=/tmp");
  int i = 0;
#ifdef STRACE_GDB
  av[i++] = "strace";
  av[i++] = "-o";
  av[i++] = "/tmp/strace.out";
#ifdef __CYGWIN__
  av[i++] = "--mask=all+paranoid";
#endif
#endif
  av[i++] = argv[1] ?: "gdb";
  fprintf (stderr, "*** using %s\n", av[0]);
  av[i++] = "-i=mi";
  av[i] = NULL;
  execvp (av[0], (char * const *) av);
  /* shouldn't get here */
  exit (1);
}
  /* parent */
  const char *input[20];

  int i = 0;
  input[i++] = "1-inferior-tty-set /dev/pty3\n";
  input[i++] = "2-gdb-set height 0\n";
  input[i++] = "3-gdb-set non-stop 1\n";
  input[i++] = "4-file-list-exec-source-files\n";
  input[i++] = "5-file-list-exec-source-file\n";
  input[i++] = "6-gdb-show prompt\n";
  input[i++] = "7-stack-info-frame\n";
  input[i++] = "8-thread-info\n";
  input[i++] = "9-break-list\n";
  input[i++] = "q\n";
  input[i] = NULL;

  for (int i = 0; input[i]; ++i)
{
  write (master, input[i], strlen (input[i]));
  // sleep (1);
}
  get_output (master);
  wait (NULL);
}

void
get_output (int fd)
{
  char buf[4096];

  while (1)
{
  int nread = read (fd, buf, sizeof (buf));
  if (nread > 0)
write (STDOUT_FILENO, buf, nread);
  else
{
  printf ("No more output.  nread %d\n", nread);
  break;
}
}
}



--
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: parrot-4.3.0-1, rakudo and rakudo-star-201204-1 (perl6)

2012-05-03 Thread Reini Urban

I updated the Cygwin distributions of parrot-4.3.0-1,
rakudo-201204.1-1 (aka perl6) and rakudo-star-201204-1

These are stable, a so-called "supported" releases.

Canonical homepages:
http://www.parrot.org/
http://www.rakudo.org/

Canonical downloads:
http://www.parrot.org/release/current
http://github.com/rakudo/rakudo/downloads
http://github.com/rakudo/star/downloads

Packaging Details:
* blizkost (perl5 in perl6) is gone.
* winxed and nqp is new, parrot-nqp is an old version unfortunately
required to bootstrap.
maybe we'll add a new nqp package somewhen.
* you need at least 2GB free RAM and an initialized rebase database to rebuild

New in parrot
See http://parrot.org/news/2012/Parrot-4.3.0
- Core
+ Winxed snapshot updated to 1.7.0
+ Add type introspection to lexical variables.
+ New 'tools/release/parrot_github_release.pl' script to automate
updates to the 'parrot.github.com' and 'parrot-docsx' repositories.
+ Numerous casting and consting fixes thanks to GCC 4.8 .
- Documentation
+ Updated 'docs/projects/release_manager_guide.pod'
+ Updated 'docs/projects/release_parrot_github_guide.pod'
+ Improved function documentation.
- Tests
- Community
- Platforms
+ Fixed alignment issues on ia64, sparc and mipsel.
+ Fixed a platform-specific issue with dlclose().

rakudo release announcement:
http://rakudo.org/2012/04/26/announce-rakudo-star-2012-04-a-useful-usable-early-adopter-distribution-of-perl-6/

* much improved startup time
* much more robust module precompilation
* autovivification for arrays and hashes is implemented again
* many phasers like PRE, POST and REDO are now implemented
* improved support for calling C functions and modelling structs and arrays
via NativeCall.pm6
* now includes modules URI, LWP::Simple, jsonrpc and Bailador (a Perl 6 port
of Dancer)

This release also contains a range of bug fixes, improvements to error
reporting and better failure modes. Many more exceptions are thrown
as typed exceptions.

notable incompatible changes from the previous releases:
* the ‘lib’ directory is not included in the default module search path
anymore. You can manipulate the search path with the PERL6LIB environment
variable

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

[ANNOUNCEMENT] Updated: libedit-20120311-1

I just updated the libedit package to version 20120311-1.

This is the latest upstream version available as autoconf'ed package
as used in Debian or Fedora.

The Cygwin package required three minor patches.  This package now
uses the cygport packaging method.


To update your installation, click on the "Install Cygwin now" link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Then, run setup and answer all of the questions.

  *** 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-Leadercygwin 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: sed-4.2.1-1

I've just updated the version of sed to 4.2.1-2.

No changes, just an update to the cygport packaging method.


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** 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=3d3dyourdomain@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 Developercygwin AT cygwin DOT com
Red Hat, Inc.

--
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] Test update: perl-5.14.2-1, please update your dependent packages

2012-05-03 Thread Reini Urban

On Thu, May 3, 2012 at 9:24 AM, Achim Gratz  wrote:
> Reini Urban  x-ray.at> writes:
>> perl has been updated to 5.14.2-1 as test in the Experimental section.
>>
>> It looks pretty stable to me when I tested it in the last 2 weeks.
>
> I've hit two interesting snags (perl_vendor is installed):
>
> 1) Some modules, when built with cpanminus fail at test, but the same module
> built with cpan tests OK (File::Slurp being the most simple example I have 
> right
> now).

Interesting. I'll look into that. I regularly try out cpanm also.
I thought we only got problems with Module::Install and Module::Build cs. EUMM.

> 2) If I install another module that uses LWP (HTTP::Status, for example), 
> then I
> also need to reinstall LWP.  Otherwise I'm getting errors like these:
>
> Attempt to reload LWP/Protocol/http.pm aborted.
> Compilation failed in require at (eval 7) line 2.

I could not repro this. I built HTTP::Status just fine. I'll think about it.

> Lastly, I'd much prefer if the vendor modules would be separate entities to
> install, this would make it easier to keep proper dependencies among them.  I
> will re-build all these modules plus some 150 more with cygport anyway 
> (provided
> I don't hit a roadblock), so once that works I could send you the 
> perl-*.cygport
> files.

Sorry, too much manual work.
I rather prefer only one single dependency and update step than 150.

These are just the basics to get CPAN and CPAN::Reporter working,
the rest you can do by your own.
You''l only need such cygports deps (like Yaakov needs them) if you
build projects
requiring perl modules. There are not many.
-- 
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: [bug] elf.h incomplete

2012-05-03 Thread Christopher Faylor

On Thu, May 03, 2012 at 04:04:32PM +0200, marco atzeri wrote:
>On 5/3/2012 3:59 PM, Fedin Pavel wrote:
>> On 03.05.2012 17:34, Ryan Johnson wrote:
>>> I've also run in to this problem, though in my case I just fired up a
>>> VM to work around it... I needed the VM anyway to actually run the
>>> newly-built kernel. That said, it would be nice to be able to build on
>>> the host and just scp the new vmlinuz across...
>>
>> I found using VM too uncomfortable and limiting, this is why i switched
>> to Cygwin. I have real ARM HW here to actually run the built code. And
>> Cygwin NFS server helps a lot with this.
>>
>>> BTW, libelf.h has all the #defines, but it only #includes them if it
>>> doesn't find an elf.h, which Cygwin has.
>>
>> There's Cygwin package. But i checked it, it doesn't have reloc
>> definitions either. So:
>> a) Not an option anyway.
>> b) Completing system-wide elf.h would solve all problems at once, and
>> increase compatibility. Anyway Cygwin's aim is to be as close to UNIX
>> environment as possible, to make things working out of the box. Or am i
>> wrong here ?
>>
>
>as usual
>http://cygwin.com/acronyms/#PTC

Right.  I've noticed the incompleteness of elf.h from time to time too but
extending it would be tedious since you can't just cut/paste from a GPLv*
file.  Maybe one of the BSDs has something more complete these days?  We
could use one of those.

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

2012-05-03 Thread Ken Brown


On 5/2/2012 5:02 PM, Ryan Johnson wrote:

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.


I find that I sometimes have to press RET before I see the prompt.  I'll 
try to figure out why that's happening, but at least pressing RET 
provides a workaround in the meantime.



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


Again, pressing RET seems to avoid the endless initialization bug. 
(This was fixed once and was a Cygwin bug, so I think it won't be hard 
for me to resurrect my test case and get it fixed again.)



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.


I agree that there are some issues to be worked out, which may well be 
Cygwin specific.  But getting to the bottom of the crashes is a higher 
priority.



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.


What do you mean by "terminal mode"?  Do you mean you run emacs under 
mintty?  Or do you run it under xterm with the -nw switch?  And could 
you elaborate on the "obvious reasons"?  I don't see why you can't run 
emacs in a terminal under gdb; or attach to it from a different terminal 
if that's more convenient.


If you continue to find that my build crashes for you but your build 
doesn't, we should try to figure out what the differences are.  You 
could download the source for the Cygwin package and rebuild using my 
.cygport f

Re: [ANNOUNCEMENT] Test update: perl-5.14.2-1, please update your dependent packages

2012-05-03 Thread Achim Gratz

Reini Urban  x-ray.at> writes:
> perl has been updated to 5.14.2-1 as test in the Experimental section.
> 
> It looks pretty stable to me when I tested it in the last 2 weeks.

I've hit two interesting snags (perl_vendor is installed):

1) Some modules, when built with cpanminus fail at test, but the same module
built with cpan tests OK (File::Slurp being the most simple example I have right
now).

2) If I install another module that uses LWP (HTTP::Status, for example), then I
also need to reinstall LWP.  Otherwise I'm getting errors like these:

Attempt to reload LWP/Protocol/http.pm aborted.
Compilation failed in require at (eval 7) line 2.

Lastly, I'd much prefer if the vendor modules would be separate entities to
install, this would make it easier to keep proper dependencies among them.  I
will re-build all these modules plus some 150 more with cygport anyway (provided
I don't hit a roadblock), so once that works I could send you the perl-*.cygport
files.

Regards,
Achim.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [bug] elf.h incomplete

2012-05-03 Thread marco atzeri


On 5/3/2012 3:59 PM, Fedin Pavel wrote:

On 03.05.2012 17:34, Ryan Johnson wrote:

I've also run in to this problem, though in my case I just fired up a
VM to work around it... I needed the VM anyway to actually run the
newly-built kernel. That said, it would be nice to be able to build on
the host and just scp the new vmlinuz across...


I found using VM too uncomfortable and limiting, this is why i switched
to Cygwin. I have real ARM HW here to actually run the built code. And
Cygwin NFS server helps a lot with this.


BTW, libelf.h has all the #defines, but it only #includes them if it
doesn't find an elf.h, which Cygwin has.


There's Cygwin package. But i checked it, it doesn't have reloc
definitions either. So:
a) Not an option anyway.
b) Completing system-wide elf.h would solve all problems at once, and
increase compatibility. Anyway Cygwin's aim is to be as close to UNIX
environment as possible, to make things working out of the box. Or am i
wrong here ?



as usual
http://cygwin.com/acronyms/#PTC

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [bug] elf.h incomplete


On 03.05.2012 17:34, Ryan Johnson wrote:
I've also run in to this problem, though in my case I just fired up a 
VM to work around it... I needed the VM anyway to actually run the 
newly-built kernel. That said, it would be nice to be able to build on 
the host and just scp the new vmlinuz across...


 I found using VM too uncomfortable and limiting, this is why i 
switched to Cygwin. I have real ARM HW here to actually run the built 
code. And Cygwin NFS server helps a lot with this.


BTW, libelf.h has all the #defines, but it only #includes them if it 
doesn't find an elf.h, which Cygwin has.


 There's Cygwin package. But i checked it, it doesn't have reloc 
definitions either. So:

a) Not an option anyway.
b) Completing system-wide elf.h would solve all problems at once, and 
increase compatibility. Anyway Cygwin's aim is to be as close to UNIX 
environment as possible, to make things working out of the box. Or am i 
wrong here ?


--
 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: [bug] elf.h incomplete


On 03/05/2012 9:24 AM, Fedin Pavel wrote:

On 03.05.2012 17:08, Earnie Boyd wrote:

To build the Linux kernel
under Cygwin requires you have the proper libraries and headers for
Linux installed in the cross environment.  It should not be using the
libraries and headers provided by the Cygwin build environment.
 I know about this. My cross-compiler is OK. I cross-build many stuff 
with it.
 But Linux kernel build process needs some specific tools, like 
modpost. They are also built from sources, but they are built to run 
on the host, not on the target. And of course they use host's 
(Cygwin's in our case) gcc with its includes.
These tools operate on newly built ELF files, this is why they use 
these includes.
I've also run in to this problem, though in my case I just fired up a VM 
to work around it... I needed the VM anyway to actually run the 
newly-built kernel. That said, it would be nice to be able to build on 
the host and just scp the new vmlinuz across...


BTW, libelf.h has all the #defines, but it only #includes them if it 
doesn't find an elf.h, which Cygwin has.


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: [bug] elf.h incomplete


On 03.05.2012 17:08, Earnie Boyd wrote:

To build the Linux kernel
under Cygwin requires you have the proper libraries and headers for
Linux installed in the cross environment.  It should not be using the
libraries and headers provided by the Cygwin build environment.
 I know about this. My cross-compiler is OK. I cross-build many stuff 
with it.
 But Linux kernel build process needs some specific tools, like 
modpost. They are also built from sources, but they are built to run on 
the host, not on the target. And of course they use host's (Cygwin's in 
our case) gcc with its includes.
These tools operate on newly built ELF files, this is why they use these 
includes.


--
 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: [Bug] rebaseall

Hi Jason,

On May  3 08:46, Jason Tishler wrote:
> On Thu, May 03, 2012 at 09:51:19AM +0200, Corinna Vinschen wrote:
> > On May  3 06:59, Achim Gratz wrote:
> > > In addition, there should be a "picket fence" in front of those
> > > expression(s), too.  Otherwise they match other lines that are not
> > > supposed to be deleted (the DLL lines are probably safe, but could
> > > be changed defensively as well).
> > 
> > Sounds good to me.
> > 
> > Jason, I would suggest the following patch to apply to the next rebase
> > release, courtesy Achim:
> > 
> > [snip]
> 
> OK, but how about using sed's -r option instead of escaping the question
> marks?

Sure.  I just didn't, because the -r option and extended regex is
non-portable, but I guess we will never use anything other than GNU sed
anyway.


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: [bug] elf.h incomplete

2012-05-03 Thread Earnie Boyd

On Thu, May 3, 2012 at 9:02 AM, Fedin Pavel wrote:
>  Why is elf.h include incomplete in Cygwin?
>  I am cross-compiling Linux kernel under Cygwin, and i had to patch modpost
> utility, adding missing R_xxx definitions for some reloc types.
> Since kernel v3 i have to add some more definitions, as well as patch one
> more utility, recordmcount. So, amount of patching grows.
> Can Cygwin's elf.h simply include all missing definitions instead? I know
> that ELF is not a home format for Cygwin, but many things being cross-build
> seem to rely on this include.

If you are using any Cygwin header for the build of a system that is
to be hosted in some other OS then I suspect you do not know how to
properly do a cross build environment.  To build the Linux kernel
under Cygwin requires you have the proper libraries and headers for
Linux installed in the cross environment.  It should not be using the
libraries and headers provided by the Cygwin build environment.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[bug] elf.h incomplete


 Why is elf.h include incomplete in Cygwin?
 I am cross-compiling Linux kernel under Cygwin, and i had to patch 
modpost utility, adding missing R_xxx definitions for some reloc types.
Since kernel v3 i have to add some more definitions, as well as patch 
one more utility, recordmcount. So, amount of patching grows.
Can Cygwin's elf.h simply include all missing definitions instead? I 
know that ELF is not a home format for Cygwin, but many things being 
cross-build seem to rely on this include.


--
 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: [Bug] rebaseall

2012-05-03 Thread Jason Tishler

On Thu, May 03, 2012 at 09:51:19AM +0200, Corinna Vinschen wrote:
> On May  3 06:59, Achim Gratz wrote:
> > In addition, there should be a "picket fence" in front of those
> > expression(s), too.  Otherwise they match other lines that are not
> > supposed to be deleted (the DLL lines are probably safe, but could
> > be changed defensively as well).
> 
> Sounds good to me.
> 
> Jason, I would suggest the following patch to apply to the next rebase
> release, courtesy Achim:
> 
> [snip]

OK, but how about using sed's -r option instead of escaping the question
marks?

Thanks,
Jason

--
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: configure --prerfix=/

On May  3 11:59, Fedin Pavel wrote:
> On 03.05.2012 11:23, Corinna Vinschen wrote:
> >Yes, that's a bug in autoconf.  It doesn't fully respect POSIX pathname
> >rules.  What happens is that it simply attaches pathnames with a leading
> >slash to the prefix,
> 
>  Ah, yes, really, i simply forgot this.
>  In fact IMHO it's not a bug in autoconf. We supply prefix without a
> trailing slash, so concatenation is ok here. Root directory would be
> expressed by empty prefix, really. Just i forgot about UNC paths...
>  Should be noticed somewhere in easy-to-reach FAQ i think...

Actually it's noted in the first paragraph in
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
and UNC paths are discussed throughout the section.


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: configure --prerfix=/


On 03.05.2012 11:23, Corinna Vinschen wrote:

Yes, that's a bug in autoconf.  It doesn't fully respect POSIX pathname
rules.  What happens is that it simply attaches pathnames with a leading
slash to the prefix,


 Ah, yes, really, i simply forgot this.
 In fact IMHO it's not a bug in autoconf. We supply prefix without a 
trailing slash, so concatenation is ok here. Root directory would be 
expressed by empty prefix, really. Just i forgot about UNC paths...

 Should be noticed somewhere in easy-to-reach FAQ i think...

--
 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: [Bug] rebaseall

On May  3 06:59, Achim Gratz wrote:
> In addition, there should be a "picket fence" in front of those expression(s),
> too.  Otherwise they match other lines that are not supposed to be deleted 
> (the
> DLL lines are probably safe, but could be changed defensively as well).

Sounds good to me.

Jason, I would suggest the following patch to apply to the next rebase
release, courtesy Achim:

Index: rebaseall.in
===
RCS file: /sourceware/projects/cygwin-apps-home/cvsfiles/rebase/rebaseall.in,v
retrieving revision 1.8
diff -u -p -r1.8 rebaseall.in
--- rebaseall.in30 Apr 2012 13:37:15 -  1.8
+++ rebaseall.in3 May 2012 07:47:36 -
@@ -202,9 +202,9 @@ case $Platform in
   cygwin)
 find /etc/setup -name '*.lst.gz' | xargs gzip -d -c |
   grep -E "\.($Suffixes)\$" |
-  sed -e '/cygwin1\.dll$/d' -e '/cyglsa.*\.dll$/d' \
+  sed -e '/\/cygwin1\.dll$/d' -e '/\/cyglsa.*\.dll$/d' \
   -e '/sys-root\/mingw/d' -e 's/^/\//' \
-  -e '/d?ash\.exe$/d' -e '/rebase\.exe$/d' >"${TmpFile}"
+  -e '/\/d\?ash\.exe$/d' -e '/\/rebase\.exe$/d' >"${TmpFile}"
   # Unconditionally add the -n flag so rebased DLLs get the
   # dynamicbase flag removed.
   NoDyn='-n'
@@ -214,9 +214,9 @@ case $Platform in
 do
   find $f -type f |
 grep -E "\.($Suffixes)\$" |
-   sed -e '/msys-1\.0.*\.dll$/d' -e '/cygwin1\.dll$/d' \
-   -e '/cyglsa.*\.dll$/d' -e '/d?ash\.exe$/d' \
-   -e '/rebase\.exe$/d' >>"$TmpFile"
+   sed -e '/\/msys-1\.0.*\.dll$/d' -e '/\/cygwin1\.dll$/d' \
+   -e '/\/cyglsa.*\.dll$/d' -e '/\/d\?ash\.exe$/d' \
+   -e '/\/rebase\.exe$/d' >>"$TmpFile"
 done
 ;;
 esac


Thanks,
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: configure --prerfix=/