[ping] SWIG maintainer
A friendly ping to the SWIG package maintainer... The current package is based on SWIG 1.3.29 from 03/06, and the latest is 1.3.31 from 11/06. There were a number of updates in 1.3.30 that may justify rolling an updated package (in my case, I needed some new Lua functionality). Thanks, Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [ANNOUNCEMENT] Updated: boost-1.33.1-3
I can confirm that this new package fixes the filesystem issue reported earlier. Thanks very-much. -Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
boost 1.33.1-2 filesystem issue (was RE: Fatal Error w/ cygwin 1-5-23-*)
Hi all,
I posted about this filesystem library issue to the boost list and another user
confirmed the problem.
The current thinking is that the boost package needs to be rebuilt with the
newer gcc/g++ 3.4.4-3 release for cygwin. I'm not sure how to identify the
current maintainer of the boost package about this, so hopefully posting to
this list is sufficient.
Thanks,
Brian
-Original Message-
From: [EMAIL PROTECTED] on behalf of Brian Hassink
Sent: Sat 12/30/2006 9:55 AM
To: cygwin@cygwin.com
Subject: RE: Fatal Error w/ cygwin 1-5-23-*
I've been able to create a simple test case...
#include
int main(int argc, char** argv)
{
boost::filesystem::path path1("/etc"); // ok
boost::filesystem::path path2("/tmp"); // boom!
}
...and it appears to be a problem with creating more than one path object.
I've checked that I'm linking with the correct version of the filesystem
library. I'll post this to the boost user group as well, but would still
appreciate any thoughts from this group.
Thanks,
Brian
-Original Message-----
From: [EMAIL PROTECTED] on behalf of Brian Hassink
Sent: Fri 12/29/2006 7:01 PM
To: cygwin@cygwin.com
Subject: RE: Fatal Error w/ cygwin 1-5-23-*
Hello all,
I found a mirror site that still had 1-5-22-1 and did a full install, but was
surprised to find that the fatal error problem I've been having still
persisted. On another machine running 1-5-22-1 this was not the case, and so I
(incorrectly) thought the problem may be 1-5-23-2 specific.
What I'm seeing is that within a call to the boost file system library to
instantiate a path object, things are blowing up after a free() call in the
cygwin dll. I've attached a gdb trace and cygcheck output for review. Note
that I'm running boost 1.33.1-1, but the problem occurs under 1.33.1-2 as well.
I would appreciate any assistance towards further isolating the problem.
Thanks,
Brian
-Original Message-
From: [EMAIL PROTECTED] on behalf of Brian Hassink
Sent: Tue 12/26/2006 9:10 AM
To: cygwin@cygwin.com
Subject: Fatal Error w/ cygwin 1-5-23-*
Hello all,
I have an app that runs fine under 1-5-22-1, but has a fatal error (see
below) when run under 1-5-23-1 or 1-5-23-2.
I've done a complete reinstallation of 1-5-23-2 (and had tried a newer
snapshot as well), but this has not resolved the problem. At this
point, I'm not sure what to look for to help isolate the problem.
Any advice?
Thanks,
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Fatal Error w/ cygwin 1-5-23-*
I've been able to create a simple test case...
#include
int main(int argc, char** argv)
{
boost::filesystem::path path1("/etc"); // ok
boost::filesystem::path path2("/tmp"); // boom!
}
...and it appears to be a problem with creating more than one path object.
I've checked that I'm linking with the correct version of the filesystem
library. I'll post this to the boost user group as well, but would still
appreciate any thoughts from this group.
Thanks,
Brian
-Original Message-----
From: [EMAIL PROTECTED] on behalf of Brian Hassink
Sent: Fri 12/29/2006 7:01 PM
To: cygwin@cygwin.com
Subject: RE: Fatal Error w/ cygwin 1-5-23-*
Hello all,
I found a mirror site that still had 1-5-22-1 and did a full install, but was
surprised to find that the fatal error problem I've been having still
persisted. On another machine running 1-5-22-1 this was not the case, and so I
(incorrectly) thought the problem may be 1-5-23-2 specific.
What I'm seeing is that within a call to the boost file system library to
instantiate a path object, things are blowing up after a free() call in the
cygwin dll. I've attached a gdb trace and cygcheck output for review. Note
that I'm running boost 1.33.1-1, but the problem occurs under 1.33.1-2 as well.
I would appreciate any assistance towards further isolating the problem.
Thanks,
Brian
-Original Message-
From: [EMAIL PROTECTED] on behalf of Brian Hassink
Sent: Tue 12/26/2006 9:10 AM
To: cygwin@cygwin.com
Subject: Fatal Error w/ cygwin 1-5-23-*
Hello all,
I have an app that runs fine under 1-5-22-1, but has a fatal error (see
below) when run under 1-5-23-1 or 1-5-23-2.
I've done a complete reinstallation of 1-5-23-2 (and had tried a newer
snapshot as well), but this has not resolved the problem. At this
point, I'm not sure what to look for to help isolate the problem.
Any advice?
Thanks,
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Fatal Error w/ cygwin 1-5-23-*
Hello all, I found a mirror site that still had 1-5-22-1 and did a full install, but was surprised to find that the fatal error problem I've been having still persisted. On another machine running 1-5-22-1 this was not the case, and so I (incorrectly) thought the problem may be 1-5-23-2 specific. What I'm seeing is that within a call to the boost file system library to instantiate a path object, things are blowing up after a free() call in the cygwin dll. I've attached a gdb trace and cygcheck output for review. Note that I'm running boost 1.33.1-1, but the problem occurs under 1.33.1-2 as well. I would appreciate any assistance towards further isolating the problem. Thanks, Brian -Original Message- From: [EMAIL PROTECTED] on behalf of Brian Hassink Sent: Tue 12/26/2006 9:10 AM To: cygwin@cygwin.com Subject: Fatal Error w/ cygwin 1-5-23-* Hello all, I have an app that runs fine under 1-5-22-1, but has a fatal error (see below) when run under 1-5-23-1 or 1-5-23-2. I've done a complete reinstallation of 1-5-23-2 (and had tried a newer snapshot as well), but this has not resolved the problem. At this point, I'm not sure what to look for to help isolate the problem. Any advice? Thanks, Brian gdb.txt Description: gdb.txt cygcheck.txt Description: cygcheck.txt -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Fatal Error w/ cygwin 1-5-23-*
Hello all, I have an app that runs fine under 1-5-22-1, but has a fatal error (see below) when run under 1-5-23-1 or 1-5-23-2. I've done a complete reinstallation of 1-5-23-2 (and had tried a newer snapshot as well), but this has not resolved the problem. At this point, I'm not sure what to look for to help isolate the problem. Any advice? Thanks, Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Hassink Sent: Sunday, December 24, 2006 8:54 AM To: cygwin@cygwin.com Subject: Similar problem (was RE: Need some help on a thread issue - is it application problem or cygthread or my installation) Hmmm, I've just run into the exact same problem with an app I'm working on... 5 [sig] mud 3264 C:\cygwin\home\admin\smudge-0.1.0\bin\smudge.exe: *** fatal error - called with threadlist_ix -1 ./go: line 2: 3264 Hangup ./bin/smudge.exe ...but in my case, things were working fine up until I did clean build. I then rolled back my changes, but the problem persists. I've since tried newer and older cygwin snapshots, still with no luck. I wasn't able to get a backtrace via gdb, but resorting to logs revealed the problem occurring when calling into to the boost file system library (specifcally, making a path iterator). In searches on this list and google, this thread problem, when seen, seems to be somehow related to directories. Is anyone else seeing this with the cygwin 1-5-23-2? Thanks, Brian -Original Message- From: [EMAIL PROTECTED] on behalf of Brian Keener Sent: Fri 12/22/2006 12:21 PM To: cygwin@cygwin.com Subject: Re: Need some help on a thread issue - is it application problem or cygthread or my installation Brian Keener wrote: > Loaded symbols for /cygdrive/c/WINDOWS/system32/dciman32.dll > Loaded symbols for /usr/local/bin/cygOpenThreads.dll > 4 [sig] osgversion 300 open_stackdumpfile: Dumping stack trace to > osgversi > on.exe.stackdump > 989547 [sig] osgversion 300 C:\cygwin\usr\local\bin\osgversion.exe: *** fatal > e > rror - called with threadlist_ix -1 > > Program exited with code 0400. > (gdb) My apologies to the list for this. After finally resolving this issue (accidentally I might add through some attempts to debug) I realize now that with the information I gave and the potential areas where there could have been a problem this list could not have helped. As it turned out the application did not like being installed in directories other than its default even though it was supposed to support it. Onve installed in the default location apps worked correctly. I just wanted to post this in case some neophyte like myself goes searching the archives for threadlist_ix -1 and finds my post and thinks there is some unresolved problem. I still don't understand why the directory affected the thread but thats for another day and another group. Again my apologies bk -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Similar problem (was RE: Need some help on a thread issue - is it application problem or cygthread or my installation)
Hmmm, I've just run into the exact same problem with an app I'm working on... 5 [sig] mud 3264 C:\cygwin\home\admin\smudge-0.1.0\bin\smudge.exe: *** fatal error - called with threadlist_ix -1 ./go: line 2: 3264 Hangup ./bin/smudge.exe ...but in my case, things were working fine up until I did clean build. I then rolled back my changes, but the problem persists. I've since tried newer and older cygwin snapshots, still with no luck. I wasn't able to get a backtrace via gdb, but resorting to logs revealed the problem occurring when calling into to the boost file system library (specifcally, making a path iterator). In searches on this list and google, this thread problem, when seen, seems to be somehow related to directories. Is anyone else seeing this with the cygwin 1-5-23-2? Thanks, Brian -Original Message- From: [EMAIL PROTECTED] on behalf of Brian Keener Sent: Fri 12/22/2006 12:21 PM To: cygwin@cygwin.com Subject: Re: Need some help on a thread issue - is it application problem or cygthread or my installation Brian Keener wrote: > Loaded symbols for /cygdrive/c/WINDOWS/system32/dciman32.dll > Loaded symbols for /usr/local/bin/cygOpenThreads.dll > 4 [sig] osgversion 300 open_stackdumpfile: Dumping stack trace to > osgversi > on.exe.stackdump > 989547 [sig] osgversion 300 C:\cygwin\usr\local\bin\osgversion.exe: *** > fatal > e > rror - called with threadlist_ix -1 > > Program exited with code 0400. > (gdb) My apologies to the list for this. After finally resolving this issue (accidentally I might add through some attempts to debug) I realize now that with the information I gave and the potential areas where there could have been a problem this list could not have helped. As it turned out the application did not like being installed in directories other than its default even though it was supposed to support it. Onve installed in the default location apps worked correctly. I just wanted to post this in case some neophyte like myself goes searching the archives for threadlist_ix -1 and finds my post and thinks there is some unresolved problem. I still don't understand why the directory affected the thread but thats for another day and another group. Again my apologies bk -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
test - please ignore
We've had some email server changes and I haven't seen a recent post I made, so this is a test... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: change in behavior of make from 3.80 to 3.81
Respectfully, Doesn't this just push the maintenance effort elsewhere? Suppose the upstream maintainer has "no fun" either? There are obviously a lot of users in the cygwin community using this feature of cygwin make and would like to see it continue to be supported. Why can't a new maintainer step forward to do so? If the interests of the current maintainer diverge from those of the larger community, then perhaps it's time for the maintainer to consider stepping aside? Again, I'm saying/asking this respectfully. -Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Corinna Vinschen Sent: Wednesday, August 16, 2006 10:41 AM To: cygwin@cygwin.com Subject: Re: change in behavior of make from 3.80 to 3.81 > - have the patch made part of the upstream gnu make That's the best solutiion of all. The whole "problem" is that the current Cygwin make maintainer has no fun to work on this issue. Everybody else is free to put a bit of time and sweat into this and get this for free firther on. I'm still wondering why people don't go this way instead of discussing this problem, which is none, IMHO, to death. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Colon in dependencies
The original poster, to which my post was a reply, claimed to have searched for the answer in the newsgroups and not found anything. Silly me for taking him at his word. Regardless, it doesn't give you the excuse to jump on me so just back off. Cheers, Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Korn Sent: Wednesday, August 09, 2006 12:19 PM To: cygwin@cygwin.com Subject: RE: Colon in dependencies On 09 August 2006 15:45, Brian Hassink wrote: > Thank-you. This reply was far more helpful than the previous. That reply was a fish. The previous reply was teaching you to fish. If you had bothered to do your elementary background research, you would already have seen all those scripts, and read the announcements. Similarly, if after being told that it was all over the archives, you had bothered to go and search and browse those archives, you would have found those scripts. If your immediate reaction to any problem is to sit there helplessly until someone spoon-feeds you the answer, you have only yourself to blame for your total lack of action. Nobody else can move your own muscles for you. It is, of course, entirely up to you, whether you want to be a helpless victim of circumstance, or take some degree of responsibility for your life and what happens in it. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Colon in dependencies
Thank-you. This reply was far more helpful than the previous. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Faylor Sent: Wednesday, August 09, 2006 10:17 AM To: cygwin@cygwin.com Subject: Re: Colon in dependencies On Wed, Aug 09, 2006 at 02:10:15PM +0100, Dave Korn wrote: >On 09 August 2006 13:23, Brian Hassink wrote: >> From: Rene Nitzsche >> Sent: Wednesday, August 09, 2006 8:08 AM > >>>how can I use a colon in dependencies for make? If a dependency >>>contains a colon, I get the error *** target pattern contains no `%'. >>>Stop. I use GNU Make 3.81 for i686-pc-cygwin, GNU bash, version >>>3.1.17(6)-release (i686-pc-cygwin). I had search for a solution in >>>many newsgroups, but I can not found a solution. > >>I've run into the same problem after upgrading to 3.81-1 with >>dependencies that contain a drive letter (e.g., x:\foo\bar.c). >> >>For now I've downgraded back to 3.80-1, but would obviously be >>interested in a better solution. > >Before reporting a problem to the mailing list, it's a good idea to a) >read the release announcement, in case what you think is a problem is >in fact a by-design feature, and b) search the list archives, in case >we've been discussing nothing else for the past fortnight and everyone >is heartily sick of going over the same old ground again. Yes, what he said. Also, FYI, I posted two scripts for converting a makefile from c:\foo to cygwin path format here: http://cygwin.com/ml/cygwin/2006-07/msg00830.html cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Colon in dependencies
I've run into the same problem after upgrading to 3.81-1 with dependencies that contain a drive letter (e.g., x:\foo\bar.c). For now I've downgraded back to 3.80-1, but would obviously be interested in a better solution. -Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rene Nitzsche Sent: Wednesday, August 09, 2006 8:08 AM To: cygwin@cygwin.com Subject: Colon in dependencies Hello, how can I use a colon in dependencies for make? If a dependency contains a colon, I get the error *** target pattern contains no `%'. Stop. I use GNU Make 3.81 for i686-pc-cygwin, GNU bash, version 3.1.17(6)-release (i686-pc-cygwin). I had search for a solution in many newsgroups, but I can not found a solution. Can you help me with this? Many thanks and Sincerely yours René Nitzsche -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gcc 4.x?
Just curious what the issues are that are holding up the release of a gcc 4.x package? Thanks, Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Xerces-C package
The latest Xerces is v2.7.0 (released September 2005), while Cygwin setup is only up to v2.5.0-1 (released February 2004). Am wondering if there's somebody actively maintaining the packaging of Xerces for Cygwin, and if so when v2.7.0 might be available? Thanks, Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
