Re: hassles with cygport

[Thomas Wolff]

> > >cygport ... prep
> > >⇒ likely, the patch fails, of course, because sources have changed,
> > >so why is there not a step "unpack" after which I would check the 
patch?

> > >
> > >trying to adapt patch
> > >⇒ searching for patched files first, somewhere among a bunch of
> > >directories;
> > >"origsrc" good guess, but tried "src" first anyway
> > >⇒ bothersome
> > >
> > >...
>
> I really don't understand your problem here.  If a patch doesn't apply
> to the original package, in how far is that cygport's fault?
The patch problem is not cygport's fault. My point was that cygport "prep"
combines the unpacking and the patching which is then bound to fail the
first time without a chance to check first. An optional split into
"unpack" and "patch" might be useful.
> ...
> The package's build problems are expected to be already solved.
Sure, but applying cygwin-specific patches are not the upstream build.


> > >trying to take up cygport sequence:
> > >cygport ... install
> > >getting message
> > >make: *** Keine Regel, um »install« zu erstellen. Schluss.
> > >*** ERROR: make install DESTDIR failed
> > >⇒ what is this? should I provide a DESTDIR? the manual says:
> > >install into a DESTDIR, and run post-installation steps
> > >this is quite unclear, what is "a DESTDIR"? something I need to 
provide

> > >or cygport would pick?
>
> DESTDIR is the default variable used in many projects to define
> an installation directory.  This is pretty common, really. E.g.
>
>   configure --prefix=/usr; make; make install DESTDIR=/tmp
>
> will configure the project to install into /usr, but the final
> `make install DESTDIR=...' will install the files under /tmp/usr
> for packaging.
Yes, I know this. I wasn't sure though whether cygport would expect a 
certain

directory to be used for packaging, or whether I should choose one
and how cygport "package" would be instructed to package from the same
(the manual does not mention DESTDIR or $D under Packaging).

Actually, I had pondered this because the upstream package (algol68g) 
installs
into /usr/local by default, and DESTDIR did not seem to work manually 
with it.

Later, after giving it a try just dropping all DESTDIR attempts, I
was surprised that cygport was miraculously able to fix the installation
target automagically. Convenient but mysterious...


> Cygport's default installation routine is called cyginstall. That's
> what is called by default if you don't specify your own src_install()
> function.  The default behaviour of cyginstall is to call the pretty
> common
>
>   make install DESTDIR=[your-project-dir/inst]
This reads a little bit more cryptic in the cyport manual...
Proposal:
Maybe a pattern cygport file would be useful that includes all these
src_ etc functions and their contents such that it produces exactly the
default behaviour without the functions. That might give a better clue on
where to start for individual adaptations.


> Did you look into the cygport files of other projects?
> That may be a good help.
Yes, a few, and they looked all so different that I didn't find it very
helpful; maybe I chose the wrong ones to start with.
> There are many hundreds of them in all kinds of
> complexities from dead easy to almost too much to handle.
I think my problem was that I had no idea whether my upstream project
is one of the "dead easy" kind for cygport - from the "hassles" I was
facing I had first assumed the other end of the scale.


About the error message "which: no autopoint in ($PATH)"
(which I had reported before, 
http://cygwin.com/ml/cygwin-apps/2012-04/msg00030.html)

"cygcheck -p autopoint" reveals "gettext",
so is a gettext dependency missing in cygport's setup.hint?


(Some further questions, related to actual packages, will go to 
cygwin-apps.)

--
Thomas

--
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 Cygwin installation is missing /usr/bin/lockfile

[Corinna Vinschen]

On Aug 14 16:04, Corinna Vinschen wrote:
> On Aug 14 09:43, Steve Rowley wrote:
> > > On 8/13/2013 6:49 PM, Christopher Faylor wrote:
> > >> On Tue, Aug 13, 2013 at 05:29:46PM -0400, Larry Hall (Cygwin) wrote:
> > >>> On 8/13/2013 5:01 PM, Steve Rowley wrote:
> > >>> I just installed 64-bit Cygwin on Win7, and noticed that
> > >>> /usr/bin/lockfile is missing in my installation.
> > >>>
> > >> As always, you can find what package something is in by searching for it
> > >> here: 
> > >>
> > >> In the case of lockfile, you can see the results here:
> > >> 
> > >>
> > >> However note that, currently, this only searches the 32-bit version of
> > >> Cygwin.  Some packages are still missing from the 64-bit version.
> > >
> > > The fact that some packages don't exist yet for 64-bit is something
> > > that does deserve highlighting.  Of course, whether or not the package
> > > actually exists for 64-bit, the package search will tell you if it
> > > exists in the 32-bit world, so at least one knows what to look for.
> > > In this particular case, I did go looking to see if 'procmail' was
> > > already available for 64-bit.  As it turns out, it is.
> > 
> > Thank you for for the pointer to how to find the Cygwin package
> > containing a file; that is indeed a useful thing to know.  Since
> > procmail is the home of /usr/bin/lockfile, I reinstalled procmail.
> > 
> > However, /usr/bin/lockfile is still missing.  Unpacking the procmail
> > 3.22-12 tarball reveals that it contains only the
> > /usr/share/doc/procmail/ directory, and 4 small documentation files.
> > The rest of procmail is missing.
> > 
> > If this is something that will take a while, then perhaps I should go
> > back to the 32-bit installation so my scripts will work while waiting
> > for a fix.  But as uninstalling and reinstalling a rather large Cygwin
> > installation is painful, I'd rather not do this if lockfile will be
> > available in a week or so.
> > 
> > Does anyone have advice as to whether it's worth waiting vs going back
> > to 32 bit?
> 
> It's just a packaging bug.  Somehow I tripped over the order of variable
> evaluation.  I'm looking into it and provide a new 64 bit procmail later
> today.

I just uploaded procmail-3.22-13.  Please give it a try.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpvphyDaaPzo.pgp
Description: PGP signature

Re: 64-bit emacs crashes a lot

[Ryan Johnson]

On 14/08/2013 10:04 AM, Ryan Johnson wrote:
After a rash of crashes where I either forgot to attach gdb or forgot 
to set appropriate breakpoints, I finally managed to catch the stack 
trace below. It occurred during M-x compile, while emacs parsed the 
compilation's rather copious output, which is by far the most common 
type of crash I've been getting lately. I have no idea how to 
interpret the backtrace, though.
False alarm... that backtrace was triggered by me attempting to 
terminate the compile with C-c C-k, which emacs handled fine once gdb 
let it continue.


Ryan


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

Re: 64-bit emacs crashes a lot

[Ryan Johnson]

On 10/08/2013 2:01 PM, Ken Brown wrote:

On 8/10/2013 11:24 AM, Ryan Johnson wrote:

On 10/08/2013 9:59 AM, Ken Brown wrote:

On 8/9/2013 11:28 PM, Ryan Johnson wrote:

On 08/08/2013 2:00 PM, Ryan Johnson wrote:

On 08/08/2013 1:42 PM, Ken Brown wrote:

On 8/5/2013 11:29 AM, Ryan Johnson wrote:

On 05/08/2013 11:00 AM, Ken Brown wrote:

On 8/3/2013 3:05 PM, Ryan Johnson wrote:

On 02/08/2013 8:07 AM, Ryan Johnson wrote:

On 02/08/2013 7:04 AM, Ken Brown wrote:

On 8/2/2013 4:02 AM, Corinna Vinschen wrote:

On Aug  1 22:46, Ryan Johnson wrote:

Here's a new one... I started a compilation, but before it
actually
invoked the command it started pegging the CPU. After
^G^G^G, it
crashed with the following:

Auto-save? (y or n) y
  0 [main] emacs 5076 C:\cygwin64\bin\emacs-nox.exe: ***
fatal
error - Internal error: TP_NUM_W_BUFS too small 2268032 
>= 10.


That looks like a memory overwrite.  2268032 is 0x229b80, 
which

looks
suspiciously like a stack address.  And the overwritten 
value is

on the
stack, too, well within the cygwin TLS area.  If *this* value
gets
overwritten, the TLS is probbaly totally hosed at this point.
There's
just no way to infer the culprit from this limited info.


Could this be BLODA?  Ryan, I noticed that you wrote in a
different
thread, "I recently migrated to 64-bit cygwin...and so far
have not
had to disable Windows Defender; the latter was a recurring
source of
trouble for my previous 32-bit cygwin install on Win7/64."
This would be a whole new level of nasty from a BLODA... I 
thought

they only interfered with fork()?

However, this *is* Windows Defender we're talking about... 
service

disabled and all cygwin processes restarted. I'll let you know
in a
day or so if the crashes go away.

Rats. I just had another crash, the "Fatal error 6" variety.
Windows
Defender has not turned itself back on (it's been known to do
that), and
a scan of the BLODA list didn't match anything else on my system.

So I don't think it's BLODA...

Ideas?


Not really, other than the obvious: (a) Find a reproducible way of
making emacs-nox crash.  (b) Catch the crash in gdb by setting a
suitable break point.
Got one! Looks like a stack overflow somewhere in the garbage 
collector:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 5316.0x1af4]
0x0001004df44a in mark_object (arg=)
 at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
5903if (CONS_MARKED_P (ptr))
(gdb) bt
#0  0x0001004df44a in mark_object (arg=)
 at /usr/src/debug/emacs-24.3-4/src/alloc.c:5903
#1  0x0001004df66e in mark_object (arg=)
 at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
#2  0x0001004df593 in mark_object (arg=)
 at /usr/src/debug/emacs-24.3-4/src/alloc.c:5809
#3  0x0001004df66e in mark_object (arg=)
 at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
#4  0x0001004df66e in mark_object (arg=)
 at /usr/src/debug/emacs-24.3-4/src/alloc.c:5914
#5  0x0001004df585 in mark_object (arg=)
 at /usr/src/debug/emacs-24.3-4/src/alloc.c:5808
#6  0x0001004dfa4e in mark_vectorlike (
 ptr=0x100f66f28 )
 at /usr/src/debug/emacs-24.3-4/src/alloc.c:5501
... snip ...
#2606 0x0001004dfaf4 in mark_buffer (buffer=)
 at /usr/src/debug/emacs-24.3-4/src/alloc.c:5552
#2607 0x0001004dff2c in Fgarbage_collect ()
 at /usr/src/debug/emacs-24.3-4/src/alloc.c:5181
#2608 0x in ?? ()


I don't know whether 2608 stack frames is unusual or not.  Is this
enough to cause a stack overflow?

I don't know the answer to that for emacs, but in general that's an
exceedingly deep stack that would normally indicate some sort of
infinite recursion. Would you actually expect an object tree in emacs to
be 2000+ pointers deep? No plausible non-bug scenarios leap to mind
right off...


I'd be very surprised if there were a bug in the garbage collection 
routine that's causing this.  If there were, I'd expect to see lots of 
people reporting this.  Could there be some memory corruption that 
creeps in when you suspend/resume emacs?  You did say that the crashes 
are less frequent since you deactivated Windows Defender, so I'm not 
sure you can rule out BLODA.


By the way, are your crashes always related to suspending and resuming 
emacs?  I don't recall that you said that before, but you keep 
mentioning ^Z.  Do you still get crashes if you never suspend emacs? 
You could also try one of the GUI versions of emacs to see if you get 
crashes.  "Suspending" in that case simply iconifies the frame.





I have the full backtrace saved to file, let me know if that would be
useful (there wasn't anything obvious that I could see, just more 
of the

same). Meanwhile, I verified that none of the addresses printed is
repeated, so it doesn't seem to be due to an obvious cycle in the 
object

graph.


From what you've shown, it appears that most of the addresses have
been optimized out.  I think you would need an unoptimized build in
order to check that, would

Re: 64-bit Cygwin installation is missing /usr/bin/lockfile

[Corinna Vinschen]

On Aug 14 09:43, Steve Rowley wrote:
> > On 8/13/2013 6:49 PM, Christopher Faylor wrote:
> >> On Tue, Aug 13, 2013 at 05:29:46PM -0400, Larry Hall (Cygwin) wrote:
> >>> On 8/13/2013 5:01 PM, Steve Rowley wrote:
> >>> I just installed 64-bit Cygwin on Win7, and noticed that
> >>> /usr/bin/lockfile is missing in my installation.
> >>>
> >> As always, you can find what package something is in by searching for it
> >> here: 
> >>
> >> In the case of lockfile, you can see the results here:
> >> 
> >>
> >> However note that, currently, this only searches the 32-bit version of
> >> Cygwin.  Some packages are still missing from the 64-bit version.
> >
> > The fact that some packages don't exist yet for 64-bit is something
> > that does deserve highlighting.  Of course, whether or not the package
> > actually exists for 64-bit, the package search will tell you if it
> > exists in the 32-bit world, so at least one knows what to look for.
> > In this particular case, I did go looking to see if 'procmail' was
> > already available for 64-bit.  As it turns out, it is.
> 
> Thank you for for the pointer to how to find the Cygwin package
> containing a file; that is indeed a useful thing to know.  Since
> procmail is the home of /usr/bin/lockfile, I reinstalled procmail.
> 
> However, /usr/bin/lockfile is still missing.  Unpacking the procmail
> 3.22-12 tarball reveals that it contains only the
> /usr/share/doc/procmail/ directory, and 4 small documentation files.
> The rest of procmail is missing.
> 
> If this is something that will take a while, then perhaps I should go
> back to the 32-bit installation so my scripts will work while waiting
> for a fix.  But as uninstalling and reinstalling a rather large Cygwin
> installation is painful, I'd rather not do this if lockfile will be
> available in a week or so.
> 
> Does anyone have advice as to whether it's worth waiting vs going back
> to 32 bit?

It's just a packaging bug.  Somehow I tripped over the order of variable
evaluation.  I'm looking into it and provide a new 64 bit procmail later
today.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpYHJIp1f67A.pgp
Description: PGP signature

64-bit Cygwin installation is missing /usr/bin/lockfile

[Steve Rowley]

> On 8/13/2013 6:49 PM, Christopher Faylor wrote:
>> On Tue, Aug 13, 2013 at 05:29:46PM -0400, Larry Hall (Cygwin) wrote:
>>> On 8/13/2013 5:01 PM, Steve Rowley wrote:
>>> I just installed 64-bit Cygwin on Win7, and noticed that
>>> /usr/bin/lockfile is missing in my installation.
>>>
>> As always, you can find what package something is in by searching for it
>> here: 
>>
>> In the case of lockfile, you can see the results here:
>> 
>>
>> However note that, currently, this only searches the 32-bit version of
>> Cygwin.  Some packages are still missing from the 64-bit version.
>
> The fact that some packages don't exist yet for 64-bit is something
> that does deserve highlighting.  Of course, whether or not the package
> actually exists for 64-bit, the package search will tell you if it
> exists in the 32-bit world, so at least one knows what to look for.
> In this particular case, I did go looking to see if 'procmail' was
> already available for 64-bit.  As it turns out, it is.

Thank you for for the pointer to how to find the Cygwin package
containing a file; that is indeed a useful thing to know.  Since
procmail is the home of /usr/bin/lockfile, I reinstalled procmail.

However, /usr/bin/lockfile is still missing.  Unpacking the procmail
3.22-12 tarball reveals that it contains only the
/usr/share/doc/procmail/ directory, and 4 small documentation files.
The rest of procmail is missing.

If this is something that will take a while, then perhaps I should go
back to the 32-bit installation so my scripts will work while waiting
for a fix.  But as uninstalling and reinstalling a rather large Cygwin
installation is painful, I'd rather not do this if lockfile will be
available in a week or so.

Does anyone have advice as to whether it's worth waiting vs going back
to 32 bit?

Tnx.
___
Steve Rowley  http://alum.mit.edu/www/sgr/ Skype: sgr000
It is very dark & after 2000.  If you continue, you are likely to be
eaten by a bleen.

--
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] egrep core dumps when it opens binary files

[Corinna Vinschen]

On Aug 13 20:01, Jim Burwell wrote:
> > On 8/12/2013 7:41 PM, Corinna Vinschen wrote:
> > >
> > > I added UTF-16 surrogate handling to the -i option and uploaded a
> > > grep-2.14-2 package to the 64 bit release.  Please give it a tests.
> > > If it works for you, I'll send the patch upstream.
> > >
> >
> > Hi,
> >
> > I can confirm it fixes the crash for me. I used this testcase:
> >
> > echo -n -e '\xf4\x85\x84' > test
> > grep -i foo test
> >
> > Which crashed with grep-2.14-1 but not any more with grep-2.14-2.
> >
> > Sylvain
> I can confirm the problem is fixed.  The same test no longer crashes.

Thanks, guys.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


pgpWKUiqsSYuL.pgp
Description: PGP signature