Re: [Legal] copyright assignment - pain
On Mon, Jun 07, 2004 at 05:16:08AM +0200, Bas van Gompel wrote: >[multiple recipients: cygwin mailing-list + Rose Naftaly at RedHat] >Note: This is legal stuff, many of you may want to skip this mail... Good advice. >In http://cygwin.com/contrib.html> it says to ask questions on >the mailing-list, while in http://cygwin.com/assign.txt> it says >to send questions to R. Naftaly. Hence this (b)cc'd message. There is no reason to send legal questions here. This list will not resolve your grievances. Contacting the person in the contrib link is the correct way to do this. Lets not discuss this here any further. There is no reason to subject the cygwin mailing list to Red Hat specific legal questions. We don't need a bunch of IANAL's wasting bandwidth with their expert legal opinions. -- Christopher Faylor spammer? -> [EMAIL PROTECTED] Cygwin Co-Project Leader[EMAIL PROTECTED] TimeSys, Inc. -- 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/
[Legal] copyright assignment - pain
[multiple recipients: cygwin mailing-list + Rose Naftaly at RedHat] Hallo, Note: This is legal stuff, many of you may want to skip this mail... In http://cygwin.com/contrib.html> it says to ask questions on the mailing-list, while in http://cygwin.com/assign.txt> it says to send questions to R. Naftaly. Hence this (b)cc'd message. I have a few questions/remarks about the assignment-form. *) The term 'program' is used. I suggest using 'software' in its stead. I've seen (at least one) other Red Hat project(s) do this, and cygwin is -after all- a library, not a program. *) 'Upon thirty days' prior written notice, Red Hat agrees to grant me non-exclusive rights to use the Work...' (in the contract) and 'but promises that you retain the right to use your contributed changes as you see fit' (in the intro) do not read to me as meaning the same. The first says Red Hat has to grant me something after I write to them, the second says I retain that same something. I *much* prefer the latter (especially as this is about _my_ "Work"). I therefore suggest a wording like: 'Red Hat agrees I will retain non-exclusive rights...'. *) 'I hereby indemnify and hold harmless...'... Tell me again why I need to sign this? I'm trying to contribute something to a GPL project, not trying to get sued. I actually thought this whole thing was meant to enable Red Hat to fight the legal battles to keep open source open. How does me becoming a party in that help anybody? *) 'on account of a breach or alleged breach of the foregoing warranty.' _If_ you convince me I need to indemnify anybody, you'll definitely have to be less general about it. I can not do anything about anothers actions. I will sooner write 'on account of a breach by me or allegation by me of a breach of the foregoing warranty.' I hope somebody can help me get this settled. I really would like to be able to help cygwin become _even better_. L8r, Buzz. (IANALATEISMBSI) -- ) | | ---/ ---/ Yes, this | This message consists of true | I do not -- | | // really is | and false bits entirely.| mail for ) | | //a 72 by 4 +---+ any1 but -- \--| /--- /--- .sigfile. | |perl -pe "s.u(z)\1.as."| me. 4^re -- 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/
CygUtils website going dark
For six years, I've hosted a website for the cygwin free software community. It began life as http://cygutils.netpedia.net/ where it was the home of one of the first ports of perl to the cygwin platform, and of an update to B20 of Andy Piper's venerable usr-utilities-B19. Later, cygutils moved to http://www.neuro.gatech.edu/~cwilson/cygutils/ However, last year the neuro.gatech.edu site management was moved to a different department (it's now at http://users.ece.gatech.edu/~cwilson/cygutils/ ). The new site management has more restrictive policies for user accounts, and I can no longer keep multi-megabytes of open-source software there. Consequently, within the next week, cygutils will be going down, permanently. As most of the items that used to reside there are now official parts of the cygwin distribution and are hosted instead on the cygwin mirror system, this comes as no great hardship to the community, I think. However, there are a number of other items on the site that others may wish to archive (and/or salvage for hosting on their own sites) -- (but not everything! There's a lot of dross and out-of-date stuff there). Hence, the one-week delay. I've attached a list of the entire current contents of the cygutils website. Of note are the "ADOPT-ME" packages under testing, my cygwin ports of libgeotiff and proj which were ITP'ed but rejected for official inclusion, and a cygwin port of kerboros5. Note that cygipc and the "cygutils-package" are also both hosted by this site, even though they are now part of the official cygwin distribution. I will attempt to find new homes for those two items. Don't worry, I won't be disappearing from the cygwin community -- but the cygutils website has served its purpose, and it's time to let it go. Oh -- and a final plea: I don't want a ton of people to try to "save" the whole site and hammer ECE's server. A lot of the cygutils stuff deserves to die; it's old and obsolete and doesn't need saving. But if some of the items are worthy of preservation, don't everybody download 'em all at once -- be gentle with ECE's server; you've got a whole week. -- Chuck cygutils/OBSOLETE/B20/perl/modules/RPMS/.htaccess cygutils/OBSOLETE/B20/perl/modules/SRPMS/.htaccess cygutils/OBSOLETE/B20/perl/modules/.htaccess cygutils/OBSOLETE/B20/perl/packages/.htaccess cygutils/OBSOLETE/B20/perl/patches/.htaccess cygutils/OBSOLETE/B20/perl/source/.htaccess cygutils/OBSOLETE/B20/perl/.htaccess cygutils/OBSOLETE/B20/perl/README.cygwin32-v1.4.1 cygutils/OBSOLETE/B20/perl/README.cygwin32-v1.4.1.html cygutils/OBSOLETE/B20/rpm/.htaccess cygutils/OBSOLETE/B20/rpm/rpm-3.0.2-cygwinb20.README cygutils/OBSOLETE/B20/B20legacy.html cygutils/OBSOLETE/B20/.htaccess cygutils/OBSOLETE/B20/perl-5.005_03-dynamic.html cygutils/OBSOLETE/B20/consize-off.png cygutils/OBSOLETE/B20/consize-on.png cygutils/OBSOLETE/B20/consize.html cygutils/OBSOLETE/B20/cygutils-logo.png cygutils/OBSOLETE/B20/desc.html cygutils/OBSOLETE/B20/foot.html cygutils/OBSOLETE/B20/home-off.png cygutils/OBSOLETE/B20/home-on.png cygutils/OBSOLETE/B20/index.html cygutils/OBSOLETE/B20/infozip-off.png cygutils/OBSOLETE/B20/infozip-on.png cygutils/OBSOLETE/B20/infozip.html cygutils/OBSOLETE/B20/logo.html cygutils/OBSOLETE/B20/nav.html cygutils/OBSOLETE/B20/size-off.png cygutils/OBSOLETE/B20/perl-on.png cygutils/OBSOLETE/B20/perl-5.005_03-static.html cygutils/OBSOLETE/B20/perl-5.005_62.html cygutils/OBSOLETE/B20/perl-misc.html cygutils/OBSOLETE/B20/perl-off.png cygutils/OBSOLETE/B20/perl.html cygutils/OBSOLETE/B20/rpm-off.png cygutils/OBSOLETE/B20/rpm-on.png cygutils/OBSOLETE/B20/rpm.html cygutils/OBSOLETE/B20/run-off.png cygutils/OBSOLETE/B20/run-on.png cygutils/OBSOLETE/B20/run.html cygutils/OBSOLETE/B20/size-on.png cygutils/OBSOLETE/V1.1/autoconf-2.13/.htaccess cygutils/OBSOLETE/V1.1/autoconf-2.13/index.html cygutils/OBSOLETE/V1.1/autoconf-2.13/autoconf-2.13-cygwin-pre21.README cygutils/OBSOLETE/V1.1/automake-1.4/.htaccess cygutils/OBSOLETE/V1.1/automake-1.4/index.html cygutils/OBSOLETE/V1.1/automake-1.4/automake-1.4-cygwin-pre21.README cygutils/OBSOLETE/V1.1/bzip2-0.9.5d/.htaccess cygutils/OBSOLETE/V1.1/bzip2-0.9.5d/index.html cygutils/OBSOLETE/V1.1/bzip2-0.9.5d/bzip2-0.9.5d-cygwin-pre21.README cygutils/OBSOLETE/V1.1/cvs-1.10/.htaccess cygutils/OBSOLETE/V1.1/cvs-1.10/index.html cygutils/OBSOLETE/V1.1/cvs-1.10/cvs-1.10-1-cygwin1.1.README cygutils/OBSOLETE/V1.1/cvs-1.10/cvs-1.10-cygwin-pre21.README cygutils/OBSOLETE/V1.1/cygipc/.htaccess cygutils/OBSOLETE/V1.1/cygipc/index.html cygutils/OBSOLETE/V1.1/cygipc-1.05/.htaccess cygutils/OBSOLETE/V1.1/cygipc-1.05/index.html cygutils/OBSOLETE/V1.1/cygipc-1.05/cygipc-1.03-cygwin1.1.README cygutils/OBSOLETE/V1.1/cygipc-1.05/cygipc-1.04-cygwin1.1.README cygutils/OBSOLETE/V1.1/cygipc-1.05/cygipc-1.05-cygwin1.1.README cygutils/OBSOLETE/V1.1/db-2.7.7/.htaccess cygutils/OBSOLETE/V1.1/db-2.7.7/index.html cygutils/OBSOLETE/V1.1/db-2.7.7/db-2.7.7-cygwin-pre21.README cygutils/OBS
Re: 1.5.10-3 : strange crashes of gethostbyname() under gdb
At 10:00 AM 6/6/2004, you wrote:
>I'm not sure it's my setup, but since I upgraded to Cygwin 1.5.10-3 gdb
>crashes when executing trivial calls to gethostbyname:
>
>---
>$ gdb --args test/q
>GNU gdb 2003-09-20-cvs (cygwin-special)
>Copyright 2003 Free Software Foundation, Inc.
>GDB is free software, covered by the GNU General Public License, and you
>are
>welcome to change it and/or distribute copies of it under certain
>conditions.
>Type "show copying" to see the conditions.
>There is absolutely no warranty for GDB. Type "show warranty" for
>details.
>This GDB was configured as "i686-pc-cygwin"...(no debugging symbols
>found)...
>(gdb) r
>Starting program: /home/em/KadC/test/q.exe
>
>Program received signal SIGSEGV, Segmentation fault.
>0xbff7a606 in KERNEL32!Heap32ListNext ()
> from /cygdrive/c/WINDOWS/SYSTEM/KERNEL32.DLL
>(gdb)
>---
>
>The source code is very simple:
>
>---
>#include
>#include
>
>int main(int ac, char *av[]) {
> struct hostent *hp;
>
> hp = gethostbyname("emnb");
> return 0;
>}
>---
>
>After reinstalling 1.5.9-1 everything has gone back to normal.
>
>---
>$ gdb --args test/q
>GNU gdb 2003-09-20-cvs (cygwin-special)
>Copyright 2003 Free Software Foundation, Inc.
>GDB is free software, covered by the GNU General Public License, and you
>are
>welcome to change it and/or distribute copies of it under certain
>conditions.
>Type "show copying" to see the conditions.
>There is absolutely no warranty for GDB. Type "show warranty" for
>details.
>This GDB was configured as "i686-pc-cygwin"...(no debugging symbols
>found)...
>(gdb) r
>Starting program: /home/em/KadC/test/q.exe
>---Type to continue, or q to quit---
>
>Program exited normally.
>(gdb)
>---
>
>Strangely enough, no SIGSEGV seems to occur if I don't run gdb.
>
>For the record, my Windows is an ancient Win98SE. The version of gdb
>should be the latest; for some reason it identifies itself as
>2003-09-20-cvs, although according to setup.exe it should be slightly
>older, 20030919-1 (the other alternative offered is 20030303-1).
>
Sounded like to
me. So I tried it. I get the SEGV in KERNEL32!IsBadWritePtr (), so I
think the above thread applies. If you ran across that or other related
threads in your search, I can understand you overlooking it. But I think
you'll find it applies.
--
Larry Hall http://www.rfk.com
RFK Partners, Inc. (508) 893-9779 - RFK Office
838 Washington Street (508) 893-9889 - FAX
Holliston, MA 01746
--
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: 1.5.10-3 : strange crashes of gethostbyname() under gdb
On Sun, 6 Jun 2004, Enzo Michelangeli wrote: > I'm not sure it's my setup, but since I upgraded to Cygwin 1.5.10-3 gdb > crashes when executing trivial calls to gethostbyname: > [snip] > > Strangely enough, no SIGSEGV seems to occur if I don't run gdb. > > For the record, my Windows is an ancient Win98SE. The version of gdb > should be the latest; for some reason it identifies itself as > 2003-09-20-cvs, although according to setup.exe it should be slightly > older, 20030919-1 (the other alternative offered is 20030303-1). > > Enzo I don't know if it's related, but the newer versions of the Cygwin runtime use a function from Kernel32.dll (IsBadWritePtr) that produces (and later handles) an intentional SIGSEGV. Since the SIGSEGV is handled, it's not seen outside of gdb. Did you try continuing a few times? For me (on Win2k), 4 continues do the trick, and the program completes normally. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton -- 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/
dipo;lomas TODAY0dly
adokD-I-P-L-O-M-A-S T-O-D-A-Yaht PHONE t0day 4 Free AnD GeT A Frees C0nS0lTatIonm Fr0m 0ur DipL0mA AnD DeGreE lSpecIalIstS. GyeT YoUr DiPlOmA ToDaY ___m gpcH O W x Y O U C A N tS T A R T Y O U R N E W LIFExodv ___ wEDuCATioN ANd CerTiFicAtIOn Can Get YoU ThErE m - PHoNE ToDaY r urvfbu.1-206-350-7428jixqnih -- 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: Annoucement: GCC-3.4.0 binary release candidate
Hello Tim, At 2004-06-06 16:44 you wrote: > At 04:38 AM 6/6/2004, Gerrit P. Haase wrote: >>Hello Hans, >> >> > I'd like to give this one a test drive! Is it possible to use it under the >> > cygwin gcc frontend (i.e. gcc -mno-cygwin) ?? >> > Or do I need to wait for the cygwin folks to catch up (which may take an >> > eternity and a half :-)? >> >>Please try to build gcc-3.3.3 or gcc-3.4.0 (including ALL languages) >>and if it succeeds, send me your patches! >> >> >>Gerrit >>-- >>=^..^= > I've never seen instructions on where to get the special cygwin patches, > let alone mingw. The public releases up through the latest 3.3.4 build and > pass testsuite fine on cygwin. I suppose the few minor changes since the > supported versions aren't sufficient to motivate anyone to produce and > verify the cygwin patches. 3.4.0 is OK, except that there is no gnu way to > bootstrap ada, and the pch feature has not been ported to cygwin. Current > 3.4.1 exposes an internal error in g++ when I attempt to build libgcj. There was a branch for Cygwin/MinGW at version 3.3.1/3.3.2, (called cygming33x), it includes some MinGW exclusive fixes, some backported patches from HEAD and some MinGW/Cygwin specials to enable the Cygwin gcc version to use the Windows API and produce Cygwin independant binaries (-mno-cygwin and -mwin32 switches). This branch is also the version which the latest release of gcc for Cygwin (3.3.1-3) is based on. 3.4.0: the first build finished, but I got nearly 900 FAILS for the libjava testsuite, every following build of libjava even failed to finish with linking errors when building jv-convert.exe with a longer list of undefined references. As I tried to build from vanilla 3.4.0 sources because I thought, some of the MinGW/Cygwin exclusive extensions may have broken s.th. I saw the 900 FAILS which is about 10 times more FAIL than you reported. 3.3.3/3.3.4: I tried to build 3.3.3 instead of 3.4.0, now I got this error which was reported to be fixed somewhere in 2002: sh ./libtool --tag=GCJ --mode=link /gcc/gcc-3.3.3/gcc-3.3.3-1/.build/gcc/gcj -B/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/i686-pc-cygwin/libjava/ -B/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/gcc/ -L/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/i686-pc-cygwin/libjava -ffloat-store -g -O2 -s -Wl,--stack=0x0080 -o jv-convert.exe --main=gnu.gcj.convert.Convert -rpath /usr/lib/. -shared-libgcc -L/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/i686-pc-cygwin/libjava/.libs libgcj.la /gcc/gcc-3.3.3/gcc-3.3.3-1/.build/gcc/gcj -B/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/i686-pc-cygwin/libjava/ -B/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/gcc/ -ffloat-store -g -O2 -s -Wl,--stack=0x0080 -o jv-convert.exe --main=gnu.gcj.convert.Convert -shared-libgcc -L/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/i686-pc-cygwin/libjava -L/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/i686-pc-cygwin/libjava/.libs ./.libs/libgcj.a -L/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/i686-pc-cygwin/libstdc++-v3/src -L/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/i686-pc-cygwin/libstdc++-v3/src/.libs -lz -L/gcc/gcc-3.3.3/gcc-3.3.3-1/.build/gcc -L/usr/i686-pc-cygwin/bin -L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3 -L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../.. -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -Wl,--rpath -Wl,/usr/lib/. ./.libs/libgcj.a(String.o)(.text+0x650): In function `_ZN4java4lang6String6lengthEv': /gcc/gcc-3.3.3/gcc-3.3.3-1/libjava/java/lang/String.java:193: multiple definition of `java::lang::String::length()' ./.libs/libgcj.a(prims.o)(.text$_ZN4java4lang6String6lengthEv+0x0):prims.cc: first defined here ./.libs/libgcj.a(natThread.o)(.text$_ZN4java4lang11ThreadGroup7getNameEv+0x0):natThread.cc: multiple definition of `java::lang::ThreadGroup::getName()' ./.libs/libgcj.a(ThreadGroup.o)(.text+0x220):/gcc/gcc-3.3.3/gcc-3.3.3-1/libjava/java/lang/ThreadGroup.java:142: first defined here ./.libs/libgcj.a(natThread.o)(.text$_ZN4java4lang11ThreadGroup14getMaxPriorityEv+0x0):natThread.cc: multiple definition of `java::lang::ThreadGroup::getMaxPriority()' ./.libs/libgcj.a(ThreadGroup.o)(.text+0x260):/gcc/gcc-3.3.3/gcc-3.3.3-1/libjava/java/lang/ThreadGroup.java:167: first defined here ./.libs/libgcj.a(Thread.o)(.text+0xf0): In function `_ZN4java4lang6Thread7getNameEv': /gcc/gcc-3.3.3/gcc-3.3.3-1/libjava/java/lang/Thread.java:61: multiple definition of `java::lang::Thread::getName()' ./.libs/libgcj.a(natThread.o)(.text$_ZN4java4lang6Thread7getNameEv+0x0):natThread.cc: first defined here ./.libs/libgcj.a(Thread.o)(.text+0x100): In function `_ZN4java4lang6Thread11getPriorityEv': /gcc/gcc-3.3.3/gcc-3.3.3-1/libjava/java/lang/Thread.java:66: multiple definition of `java::lang::Thread::getPriority()' ./.libs/libgcj.a(posix-threads.o)(.text$_ZN4java4lang6Thread11getPriorityEv+0x0):posix-threads.cc: first defined here ./.libs/libgcj.a(Thread.o)(.text+0x110): In function `_ZN4java4lang6Thread14getThreadGroupEv': /gcc/gcc-3.3.3/gcc-3.3.3-1/libjava/java/lang/Thread.java:71: multiple definition of `java::lang::Thread::getThre
Re: rxvt, ssh and utf8 - partial success
On Sun, 06 Jun 2004 13:27:40 -0500, James Garrison wrote: > Looks like the simplest > solution is just to switch to en_US locale unless I really need > Unicode for something. This is, by the way, a generic rxvt problem unrelated to Cygwin. I have to export LANG=en_US when I use rxvt on RHEL too. -- 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: rxvt, ssh and utf8 - partial success
Baurjan Ismagulov wrote: Hello, James, On Sat, Jun 05, 2004 at 09:21:57PM -0500, James Garrison wrote: [snip] About ascii instead of Unicode... How do you conclude that the program (which one?) was sending Unicode sequences before using rxvt-cygwin (=> what is your locale?). The program is redhat-switch-mail-nox. With TERM=rxvt I get 3-byte sequences for box-drawing characters. I piped stdout to a file and then examined it with od, and was able to resolve the 3-byte sequences into valid UTF8 encodings. Looking in a unicode font with Windows Character Map showed that these unicode sequences were box-drawing characters. Switch to TERM=rxvt-cygwin (after putting a copy of the rxvt-cygwin terminfo file on the linux system) and voila, single-byte hyphens/bars/plus-signs instead. The locale is en_US.UTF-8. Here are some interesting results: With LANG=en_US.UTF-8 and TERM=rxvt-cygwin redhat-switch-mail-nox: corner="+", horizontal="-", vertical="|" man terminfo: UTF-8 quotes With LANG=en_US (no UTF-8) and TERM=rxvt-cygwin redhat-switch-mail-nox: corner=">", horizontal="^", vertical="|" man terminfo: ` and ' Clearly the locale and TERM settings are interacting, but I don't know enough about them to deduce any rules. Looks like the simplest solution is just to switch to en_US locale unless I really need Unicode for something. -- James GarrisonAthens Group, Inc. mailto:[EMAIL PROTECTED]5608 Parkcrest Dr http://www.athensgroup.comAustin, TX 78731 PGP: RSA=0x92E90A3B DH/DSS=0x498D331C (512) 345-0600 x150 -- 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: Annoucement: GCC-3.4.0 binary release candidate
At 04:38 AM 6/6/2004, Gerrit P. Haase wrote: Hello Hans, > I'd like to give this one a test drive! Is it possible to use it under the > cygwin gcc frontend (i.e. gcc -mno-cygwin) ?? > Or do I need to wait for the cygwin folks to catch up (which may take an > eternity and a half :-)? Please try to build gcc-3.3.3 or gcc-3.4.0 (including ALL languages) and if it succeeds, send me your patches! Gerrit -- =^..^= I've never seen instructions on where to get the special cygwin patches, let alone mingw. The public releases up through the latest 3.3.4 build and pass testsuite fine on cygwin. I suppose the few minor changes since the supported versions aren't sufficient to motivate anyone to produce and verify the cygwin patches. 3.4.0 is OK, except that there is no gnu way to bootstrap ada, and the pch feature has not been ported to cygwin. Current 3.4.1 exposes an internal error in g++ when I attempt to build libgcj. Tim Prince -- 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: Annoucement: GCC-3.4.0 binary release candidate
Hallole Gerrit, I was not trying to build gcc & kin, but rather just use it to build the suite of software I've been working on over the years. There was one hickup with g++ under heavy duty optimization, for which I filed a bug report (https://sourceforge.net/tracker/index.php?func=detail&aid=954656&group_id=2435&atid=102435). Danny Smith said he fixed the problem and send the patch back to the mainstream gcc folks. Performancewise I had mixed success (compared with executables compiled under gcc 3.3.1 cygwin -mno-cygwin). Some are significantly slower, some are significantly faster (+/- 50%) than under 3.3.1. There were many issues, though, I had to deal with in order to be able to compile the code under mingw in the first place (see the posts I made around 5th of may 2004). If you are interested in details of the workarounds, let me know! grusel, H. p.s. in my university days I knew a Frank Haase from Berlin; are you related to him? "Gerrit P. Haase" wrote in message news:[EMAIL PROTECTED] > Hello Hans, > >> I'd like to give this one a test drive! Is it possible to use it under >> the >> cygwin gcc frontend (i.e. gcc -mno-cygwin) ?? >> Or do I need to wait for the cygwin folks to catch up (which may take an >> eternity and a half :-)? > > Please try to build gcc-3.3.3 or gcc-3.4.0 (including ALL languages) > and if it succeeds, send me your patches! > > > Gerrit > -- > =^..^= > > > -- 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/
1.5.10-3 : strange crashes of gethostbyname() under gdb
I'm not sure it's my setup, but since I upgraded to Cygwin 1.5.10-3 gdb
crashes when executing trivial calls to gethostbyname:
---
$ gdb --args test/q
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols
found)...
(gdb) r
Starting program: /home/em/KadC/test/q.exe
Program received signal SIGSEGV, Segmentation fault.
0xbff7a606 in KERNEL32!Heap32ListNext ()
from /cygdrive/c/WINDOWS/SYSTEM/KERNEL32.DLL
(gdb)
---
The source code is very simple:
---
#include
#include
int main(int ac, char *av[]) {
struct hostent *hp;
hp = gethostbyname("emnb");
return 0;
}
---
After reinstalling 1.5.9-1 everything has gone back to normal.
---
$ gdb --args test/q
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pc-cygwin"...(no debugging symbols
found)...
(gdb) r
Starting program: /home/em/KadC/test/q.exe
---Type to continue, or q to quit---
Program exited normally.
(gdb)
---
Strangely enough, no SIGSEGV seems to occur if I don't run gdb.
For the record, my Windows is an ancient Win98SE. The version of gdb
should be the latest; for some reason it identifies itself as
2003-09-20-cvs, although according to setup.exe it should be slightly
older, 20030919-1 (the other alternative offered is 20030303-1).
Enzo
--
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: Annoucement: GCC-3.4.0 binary release candidate
Hello Hans, > I'd like to give this one a test drive! Is it possible to use it under the > cygwin gcc frontend (i.e. gcc -mno-cygwin) ?? > Or do I need to wait for the cygwin folks to catch up (which may take an > eternity and a half :-)? Please try to build gcc-3.3.3 or gcc-3.4.0 (including ALL languages) and if it succeeds, send me your patches! Gerrit -- =^..^= -- 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: rxvt, ssh and utf8 - partial success
Hello, James, On Sat, Jun 05, 2004 at 09:21:57PM -0500, James Garrison wrote: > >>Handling this in rxvt should solve your problem (I wonder if there are > >>any reasons not to do that). This was actually an answer to Brian, who wanted to have a single terminal type for one application (and I share his opinion). But it seems to apply to your question, too: from http://google.com/search?q=rxvt+unicode I conclude that rxvt doesn't handle Unicode. If you try rxvt-unicode I would like to know whether it works under Cygwin. I've tried it under Debian and couldn't see the expected symbols when I cat a file encoded in utf-8. Brian: FWIW, I can't reproduce the less behaviour you've described. Under Linux both entries work in the same way, which is expected, given that the terminfo entries are identical except acsc. Perhaps you are using an older version of terminfo, which has some other differences? I've tested terminfo 5.3-3. > I uploaded the rxvt-cygwin terminfo file from Cygwin onto the Linux > system (into ~/.terminfo/r/rxvt-cygwin). Setting TERM=rxvt-cygwin now > allows the curses-based program to draw boxes correctly, but > apparently some substitution is going on because it's using plain old > hyphens and vertical bars for lines and plus signs for corners. I'm not sure what you call partial success, but all this seems to be irrelevant to your original question. The byte stream from the input should be treated as Unicode by the application (=> try rxvt-unicode, or xterm in the Unicode mode, if it works under Cygwin). I don't think it's terminfo entry that makes the application output pluses and hyphens (and I can't reproduce this under Linux; mc printed the codes from acsc using the current font). > Terminfo doesn't seem to know anything about Unicode as far as I can > tell (or does it?). That leads to the question of how putting the > terminfo file on the Linux system caused the curses-based program to > output single ASCII characters where previously it was sending Unicode > sequences... something understood how to interpret the Unicode box- > drawing characters and replaced them with the nearest ASCII matches > "+", "|" and '-'. There are some attempts to produce a Unicode curses library, but I don't know whether terminfo is involved; it is enough for me if it works with byte streams. About ascii instead of Unicode... How do you conclude that the program (which one?) was sending Unicode sequences before using rxvt-cygwin (=> what is your locale?). > However, this IS NOT happening with Unicode quote characters. Here's > a snippet from the man page for terminfo itself, as displayed: > ... > Those "???" sequences turn out to be \xE2\x80\x99, which is the UTF8 > encoding of the Unicode character "Right Single Quotation Mark) > (U+2019). This is not happening with other characters as well, at least not due to terminfo. Man outputs Unicode -> rxvt displays it (albeit not in a way you'd like it to). I thinks that in your previous example it was the application that decided to output ascii instead of characters from acsc. With kind regards, Baurjan. -- 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/
