Re: [ANN] update: apache-1.3.24-3
On Mon, Apr 29, 2002 at 08:04:42PM +0200, Stipe Tolj wrote: Hi there, please upload the latest binary build for 1.3.24-3 from http://apache.dev.wapme.net/support/cygwin-packages/apache/. Please provide the full paths to the archives, including the filename. It allows me conveniently just to copy/paste them into a command line. Other than that, I can't copy the files due to a permission problem on cygwin.com. We'll have to wait for Chris to wake up, today. I have added this time a flag -k for no-detach (keep attached) mode. Hence if httpd is invoked without any flags it detaches, which is the normal behaviour for other UNIX flavors and -k may be used to run it using cygrunsrv. This change in behaviour needs some and in the announcement. Hmm, forget it, people will ask clueless questions anyway... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
setup.exe exception handling guidelines
I've reviewed the use of threads, and I believe the following guidelines will provide safe exception handling without stomping across threads. Exception handling guidelines: For 100% message based windows, exceptions in code will get caught by the same thread that handles window messages - which means the propertysheet thread. The catch routine here can only catch exceptions within a message. for thread based windows (i.e. site, or the current chooser, or download), the thread reflector can catch() whatever it wants to... AS LONG AS the window message routine does not do any exception processing (ie , try catch or throw). What does this mean? Well things like the nio code can throw an authentication exception, to separate out the functional code and the UI. This will let Pavel Tsekov's URL class get added to setup in the near future, and will also allow some more cleanups leading up to a command line version and or more split out support libraries. Of course, if the gcc library (mingw or cygwin) was built with --with-threads, this would be simpler. Exceptions that can be thrown: I'm going to create a base Exception class, from which all thrown exceptions should derive. No char/string or String exceptions are allowed. This allows a generic catch-all Exception handler, and by subclassing, more specific handlers can sit in front of it. Cheers, Rob
Re: setup.exe exception handling guidelines
Hello Robert, Tuesday, April 30, 2002, 1:09:48 PM, you wrote: [snip] RC Exceptions that can be thrown: RC I'm going to create a base Exception class, from which all thrown RC exceptions should derive. No char/string or String exceptions are RC allowed. This allows a generic catch-all Exception handler, and by RC subclassing, more specific handlers can sit in front of it. What about the standard C++ library exception class ? In the recent threads regarding setup and libgetopt++ I red that we libstdc++ can be used now ?
time stamp printing for ssp
Hi,
for application debugging I had the need to see the elapsed time for any step in
ssp, so I've added time stamp printing.
$ cvs diff -p ssp.c
Index: ssp.c
===
RCS file: /cvs/src/src/winsup/utils/ssp.c,v
retrieving revision 1.3
diff -u -3 -p -B -p -r1.3 ssp.c
--- ssp.c 27 Feb 2002 16:10:17 - 1.3
+++ ssp.c 30 Apr 2002 15:30:23 -
@@ -20,6 +20,7 @@
#include time.h
#include ctype.h
#include windows.h
+#include sys/time.h
#ifdef __GNUC__
const char *help_text = \
@@ -326,6 +327,8 @@ run_program (char *cmdline)
int tix, i;
HANDLE hThread;
char *string;
+ long long int starttime,ctime;
+ struct timeval time;
memset (startup, 0, sizeof (startup));
startup.cb = sizeof (startup);
@@ -376,6 +379,13 @@ run_program (char *cmdline)
}
}
+ if (verbose)
+ {
+/* init timecounter */
+gettimeofday(time,NULL);
+starttime = time.tv_sec * 100 + time.tv_usec;
+ }
+
running = 1;
while (running)
{
@@ -407,10 +417,24 @@ run_program (char *cmdline)
printf (\n);
#endif
+if (verbose) {
+ /* print current time */
+ gettimeofday(time,NULL);
+ ctime = time.tv_sec * 100 + time.tv_usec - starttime;
+ {
+ int min = (int) (ctime /6000);
+ int sec = (int) (ctime /100);
+ int millisec = (int) ((ctime /1000) %1000);
+ printf(%02d:%02d.%03d ,min,sec,millisec);
+ }
+ }
+
switch (event.dwDebugEventCode)
{
case CREATE_PROCESS_DEBUG_EVENT:
+ if (verbose)
+ printf(create process at
%08x\n,event.u.CreateProcessInfo.lpStartAddress);
break;
case CREATE_THREAD_DEBUG_EVENT:
@@ -653,6 +677,10 @@ run_program (char *cmdline)
running = 0;
break;
+
+ default:
+ if (verbose)
+printf(unknown event\n);
}
set_steps ();
-
2002-04-30 Ralf Habacker [EMAIL PROTECTED]
* ssp.c (run_program): Added time stamp printing in verbose mode.
Regards
Ralf
Re: MD5 support
On Tue, Apr 30, 2002 at 12:40:43PM +1000, Robert Collins wrote: I've uploaded a snapshot (bin src) that detects corrupt files based on md5. It's backward compatible with the current .ini format. The code needs reorganising before I commit it, this is simply for folk to play and test with. There is -no- UI change at this point. The md5 corruption is silently detected (and that will have to change before committing too). I have upset ready to go for this. Will it actually break setup.exe if I check in my changes? I'm away from a Windows system right now so I can't check myself. cgf
Re: RFC: setup.ini change
On Mon, Apr 29, 2002 at 12:17:54PM -0400, Charles Wilson wrote: Oh yeah -- speaking of changes to setup.ini: Chris, can we get that external-src: other-pkg-name thing into upset? (or other-src or whatever) Reminder: It's pretty complicated to add. If you specify external-src it will potentially have to add test, prev, curr entries for the packages. However, IMO, it makes sense for this option to actually be passed into setup.ini so that setup.exe can understand that this is basically a symbolic link rather than a copy. So, if I just add this as a pass-through, it is a no-brainer. If I add it as a fill in the blanks in setup.ini, it's more complicated. It's not hellishly more complicated but I'd rather not do the work if it makes sense for the logic to live in setup.exe. I don't remember if Robert already indicated which method he'd prefer. Maybe he already has plans to do the right thing when multiple packages refer to the same source tar ball. I seem to recall that this came up before but I don't remember what the decision was. cgf
bad setup.exe
can you reprogram the cygwin installer (setup.exe)!!! I can see a some buttons or some labels There are a lot of bugs , for example , when I add a wrong url to add site, I can't fix it and can't find it in any place !!! plz tell me how to fix it
SCADA NEWS
If you are interested with IT in the Industry like HMI, SCADA or other MES software feel free to visit www.SCADANEWS.com This message will be send only one time it is not necessary to ask for remove. If you are not interested please accept our apologies, Thanks for your attention, SCADA NEWS WEBMASTER
RE: upset stumper [cgf, Robert Collins, please comment]
Robert, I forgot to reply last night that I had hand-fixed the setup.ini file and setup.exe ran fine after that. Thanks, Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Collins Sent: Tuesday, April 30, 2002 5:08 AM To: Harold Hunt; cygx Subject: RE: upset stumper [cgf, Robert Collins, please comment] -Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 4:10 PM install: release/XFree86/gtk+/gtk+-1.2.10-1.tar.bz2 2566794 source: release/XFree86/gtk+/gtk+-1.2.10-1-src.tar.bz2 2884874 Notice that the version is thought to be -1.2.10-1, rather than 1.2.10-1. Robert, can setup.exe handle a '+' in the package name? It should be able to. What do you see in the chooser if you point setup at your setup.ini file (after correcting the version entry). Rob
RE: upset stumper [cgf, Robert Collins, please comment]
Chris, Much better, thanks. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Christopher Faylor Sent: Tuesday, April 30, 2002 10:20 AM To: [EMAIL PROTECTED] Subject: Re: upset stumper [cgf, Robert Collins, please comment] On Tue, Apr 30, 2002 at 02:09:56AM -0400, Harold Hunt wrote: version: -1.2.10-1 install: release/XFree86/gtk+/gtk+-1.2.10-1.tar.bz2 2566794 source: release/XFree86/gtk+/gtk+-1.2.10-1-src.tar.bz2 2884874 Notice that the version is thought to be -1.2.10-1, rather than 1.2.10-1. Robert, can setup.exe handle a '+' in the package name? upset was confused by the fact that '+' is a regex meta character. I've checked in a fix so it should work better now. cgf
Re: newbie
/ arun [EMAIL PROTECTED] wrote: | hello, | | I have an x windows application compiled for linux.This application | extensively uses graphics Can I directly port it to windows using | Cygwin/xfree86 ?? If it is clean portable c/c++ code - yep. If you do a bunch os-specific stuff and so on, you have to put some work on it. /Andy -- The eye of the beholder rests on the beauty!
RE: Failed assertion bug using OpenOffice.org
Peter, Yes, we are aware of that bug. We're slowly getting around to working on it. Several other cases produce that same failed assertation message. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Peter Magnusson Sent: Wednesday, April 24, 2002 5:21 PM To: [EMAIL PROTECTED] Subject: Failed assertion bug using OpenOffice.org I have a setup with cygwin 1.3.9-1 and 4.2.0 of cygwin-xfree. I have a little problem when using openoffice.org (641c) both with and without a windowmanager. I use SuSE 7.3 Pro Linux distribution with KDE. I use Windows 2000 Pro, SP2 (english). When accessing any of the menuitems a Windows(ms) dialog box pops up saying ... - Faild assertion fds_on_hold !NULL at line 601 of /cygnus/netrel/src/cygwin-1.3.9-1/winsup/cygwin/dtable.cc - This seems to be a similar bug that has been reported when using KDE3 but I am not sertain. I get the same results using the T55 version of XWin.exe. I use openoffice.org a lot and it would be a lot simpler if I could use the same environment (XWindows) when using my Windows box as well. == Peter Magnusson mailto:[EMAIL PROTECTED] ==
Re: Best place for WindowMaker, Openbox, etc.?
Christopher Faylor wrote in [EMAIL PROTECTED] in gmane.os.cygwin.xfree on Tue, 30 Apr 2002 10:12:15 -0400: Other things that can use X such as rxvt and WindowMaker aren't part of XFree86 itself. In my opinion they should have their own directories and perhaps a new category such as Xapps. I think a category of Xmanagers for WindowMaker and Openbox etc. would be better. We are not talking about categories. The question was where to physically put the actual tar balls. The categories could be discussed as well. ;-) I'm not sure we need a distinction between window managers and other applications in terms of categories. They all just need an X server - pretty much any X server - although some do rely on certain parts of the XFree86 distribution on the machine where they're executing. (Where this is the case they should have dependencies in setup.hint/setup.ini of course.) -- Sam Edge
RE: mkdll.sh
Chuck, Could you give a few more notes on relibtoolize? A pointer to some good documentation would be helpful... Is the general idea here that I would just be working on the config files and makefiles, rather than having to make extensive internal changes to the way that libraries are loaded? Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Wilson Sent: Tuesday, April 30, 2002 2:48 AM To: [EMAIL PROTECTED] Cc: cygx Subject: Re: mkdll.sh You could probably do the following: get rid of mkdll.sh relibtoolize/autoconf using the -devel tools (e.g. make sure that configure.in has AC_PREREQ(2.52)) ./configure; make; It oughta work. /famous last words --chuck Harold Hunt wrote: Steve, I'm working on creating Cygwin setup.exe packages for Gnome... I know, it's buggy but I'd like to get a start. One problem I'm having with your patches is that they use mkdll.sh but they don't cause configure to copy the file to a build directory. For example: tar xzf glib-1.2.10.tar.gz cd glib-1.2.10 patch -p1 ../glib-1.2.10-cygwin.patch mkdir build cd build ../configure [yada yada yada] make [yada yada yada] mkdir .libs ar cru .libs/libglib.a garray.o gcache.o gcompletion.o gdataset.o gdate.o gerro r.o ghash.o ghook.o giochannel.o giounix.o glist.o gmain.o gmem.o gmessages.o gm utex.o gnode.o gprimes.o grel.o gscanner.o gslist.o gstrfuncs.o gstring.o gtimer .o gtree.o gutils.o ranlib .libs/libglib.a creating libglib.la (cd .libs rm -f libglib.la ln -s ../libglib.la libglib.la) cd .libs PREFIX=/usr sh ../mkdll.sh libglib.la ../mkdll.sh: Can't open ../mkdll.sh: No such file or directory make[2]: *** [libglib.la] Error 2 make[2]: Leaving directory `/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2. 10/.build' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/Administrator/x-devel/gnome/glib/tmp/glib-1.2. 10/.build' make: *** [all-recursive-am] Error 2 Eventually I always reach a point where mkdll.sh can't be found because configure didn't copy it to the out-of-the-tree build directory. Got any ideas on how to fix this? Harold
[ANNOUNCEMENT] New Cygwin setup.exe package: lesstif
Lesstif, http://www.lesstif.org/, is now available via setup.exe. Enjoy, Harold
Re: By the way...
Harold Hunt wrote: ... I added a link to your Cygwin Gnome page to Cygwin/XFree86's Ported Software page: http://xfree86.cygwin.com/ported-software.html I'm very impressed with your work to compile Gnome with DLLs. Keep it up! A couple of things: 1) pkgconfig. I'm the cygwin pkgconfig maintainer, and I'd like to insure that you can use the official version in your port. You are using a patched version of 0.8.0; cygwin distributes 0.10.0; but 0.12.0 is now available. Could you try 0.12.0 (unpatched and/or patched) and see if that works for you? If you must use a patched version of 0.12.0, then I'd consider incorporating that patch into the official cygwin dist; also, in that case, we could submit your patch upstream for incorporation into the real 0.13.0... 2) libiconv/gettext: If someone 'adopts' my setup-compatible package for libiconv -- see thes3 messages: http://cygwin.com/ml/cygwin/2002-04/msg01558.html http://cygwin.com/ml/cygwin/2002-02/msg00467.html and it is included in the official cygwin dist, then I would rebuild the official gettext package to use it. (Yes, I'm also the cygwin gettext maintainer). 3) cygextras: why not submit these as patches to the cygwin DLL? If it is because the code is from gnu libc, then you could in partnership with someone else, reimplement them and submit the result: your partner would actually write the code to the specifications you develop; you would verify that the result operates the same as the current version. (Chinese Firewall). Then, assign copyright on the reimplementations to Red Hat/Cygwin, and submit! 4) berkeley db: folks have been asking for this for a long time. Would you consider packaging it up and submitting it as an official package? (Don't worry about the tcl thing; you needn't be able to run the test suite on an official ports only system). side note: any idea why Gnome doesn't use the GNU database instead? gdbm? 5) libungif: just like libiconv, I have a setup-compatible package for this. If someone wants to adopt it and submit it for official inclusion, contact me offline. --Chuck
Re: Best place for WindowMaker, Openbox, etc.?
On Tue, Apr 30, 2002 at 03:39:40PM +0100, Sam Edge wrote: Christopher Faylor wrote in [EMAIL PROTECTED] in gmane.os.cygwin.xfree on Tue, 30 Apr 2002 10:12:15 -0400: Other things that can use X such as rxvt and WindowMaker aren't part of XFree86 itself. In my opinion they should have their own directories and perhaps a new category such as Xapps. I think a category of Xmanagers for WindowMaker and Openbox etc. would be better. We are not talking about categories. The question was where to physically put the actual tar balls. The categories could be discussed as well. ;-) So start another thread rather than confuse the issue by responding as if you are actually answering a question that was never asked. cgf
problems with kde 1.1.2 kcontrol solved
Hi, some month ago I've encountered a problem with kde 1.1.2 kcontol. The problem was, that a once called kcontrol page was hidden for further calls. Currently I have checked this with the xfree 4.2.0 release and recognizes that it this problem is gone away. Thanks for this good work. Ralf Habacker
Re: mkdll.sh
Harold Hunt wrote:
Chuck,
Could you give a few more notes on relibtoolize? A pointer to some
good
documentation would be helpful...
Well, there's the goat book http://sources.redhat.com/autobook/ but it's
a bit out of date, now...
Here's the procedure I used to relibtoolize libiconv. Libiconv is a
worst-case example: they distribute their own fork of autoconf itself,
they redistribute system m4 macros, ... they're just plain evil. But,
if you can understand *this*, then relibtoolizing anything else should
be a piece of cake...
Short version: remove autogenerated files. Replace standard files
with the newest versions (install-sh, mkinstalldirs, config.guess,
config.sub) -- you can also just remove these and let the autotools copy
in what they need (use the --force --c -a switches, or their analog: not
every tool has exactly the same syntax). Rerun the the autotools in the
proper order (more later).
#1) libiconv actually ships its OWN VERSION of autoconf. This is dumb.
rm autoconf/acgeneral.m4
rm autoconf/acspecific.m4
rm autoconf/aclocal.m4
rm autoconf/autoconf
rm autoconf/autoconf.m4
rm autoconf/mbstate_t.m4
#2) remove the normal distribution files that are created by autoconf.
rm autoconf/install-sh
rm autoconf/config.guess
rm autoconf/config.sub
rm configure
#3) remove the obsolete libtool files (libtool no longer uses ltmain.sh)
rm autoconf/ltmain.sh
#4) I don't like hiding the autofiles, so I removed the subdir and will
change configure.in appropriately, but you don't have to do that.
rmdir autoconf
#5) libiconv doesn't use automake, but it does distribute some scripts
from automake. Replace them with the current versions. (Actually,
libiconv only distributed install-sh; it used the mkinstalldirs from the
libcharset subdirectory, proper auto* usage requires that each
separately configure project have its own copy...and of course, I put
install-sh in the top directory, libiconv had it in the autoconf subdir)
cp /usr/autotool/devel/share/automake/mkinstalldirs .
cp /usr/autotool/devel/share/automake/install-sh .
#6) repeat steps 1-4 for the libcharset subdirectory. Normally, this is
unnecessary, but libiconv actually treats libcharset as a separate
project, with it's own configure script and suchlike...
rm libcharset/autoconf/aclocal.m4
rm libcharset/autoconf/mkinstalldirs
rm libcharset/autoconf/install-sh
rm libcharset/autoconf/config.guess
rm libcharset/autoconf/config.sub
rm libcharset/autoconf/ltmain.sh
rm libcharset/configure
rmdir libcharset/autoconf
#7) libcharset also includes its own copies of some .m4 scripts that are
part of gettext. Use the system ones.
rm libcharset/m4/codeset.m4
rm libcharset/m4/glibc21.m4
#8) AND we're going to use the system libtool...and cleanup.
rm libcharset/m4/libtool.m4
rm libcharset/m4/ChangeLog
rmdir libcharset/m4
#9) Similar to step #5, replace the automake files with the latest
version (even though libcharset doesn't use automake...). Both
mkinstalldirs and install-sh WERE in the autoconf subdir of libcharset;
I put them in the top level (of libcharset). Each separately configured
project needs its own copy...
cp /usr/autotool/devel/share/automake/mkinstalldirs libcharset/
cp /usr/autotool/devel/share/automake/install-sh libcharset/
#10) As promised, I need to change a few items in configure.in (e.g.
don't use the autoconf subdir (or libcharset/autoconf or
libcharset/m4). Also, since the special versions of the autoconf
files that libiconv distributes were slightly modified -- okay, they
were distributing a fork -- I parsed out the differences they had, and
put those macros into acinclude.m4...
The patch is attached.
The patch also AC_PREREQ's 2.52 instead of 2.13 (I want to use the
-devel tree), but that required a few other changes due to
incompatibilities (AC_OUTPUT_SUBDIRS --- AC_CONFIG_SUBDIRS, etc)
Normally, you'd also re-run autoheader at some point, but that didn't
work (thanks to the fact that libiconv uses a forked autoconf dist...)
So I patched libcharset/config.h.in by hand...
#11) Okay, here's the meat: First, we relibtoolize libcharset:
cd libcharset
aclocal
libtoolize -c -f
aclocal # (again)
autoconf
cd topsrc
aclocal
libtoolize -c -f
aclocal # (again)
autoconf
Why the second aclocal step? Because libtoolize adds additional stuff
in configure.in, which require additional macros to be pulled into
aclocal.m4. Why not run libtoolize first, and then aclocal? Because
libtoolize needs a pre-existing aclocal.m4...
Normally, you'd run automake -a -c between the second aclocal and
autoconf, but libiconv doesn't use automake. Also, you'd normally run
autoheader after the second aclocal -- but we can't because libiconv sucks.
Finally, you should be able to configure and make as normal:
conf() {
(cd ${objdir} \
${srcdir}/configure --build=${host} --target=${target} \
--srcdir=${srcdir} --prefix=${prefix} \
--exec-prefix=${prefix}
Re: mkdll.sh
On Tue, 30 Apr 2002 02:48:20 -0400 Charles Wilson [EMAIL PROTECTED] wrote: You could probably do the following: get rid of mkdll.sh relibtoolize/autoconf using the -devel tools (e.g. make sure that configure.in has AC_PREREQ(2.52)) ./configure; make; It oughta work. /famous last words --chuck Harold Hunt wrote: Steve, I'm working on creating Cygwin setup.exe packages for Gnome... I know, it's buggy but I'd like to get a start. One problem I'm having with your patches is that they use mkdll.sh but they don't cause configure to copy the file to a build directory. Eventually I always reach a point where mkdll.sh can't be found because configure didn't copy it to the out-of-the-tree build directory. Got any ideas on how to fix this? Harold This port is really an experiment. It was started before the cygwin libtool was available, and before the auto-import function of ld was available, and it's showing that age. Chuck is right, mkdll is not at all suitable for a general distribution. There are in fact several different incarnations of the mkdll script in the various gnome patches. glib was one of the first packages I played with, so it was done with the least knowledge and experience, and hence is one of the most inflexible. You could try making the path to mkdll relative to the source tree rather than the current working directory, for example by using $(top_srcdir)/mkdll.sh instead of ../mkdll.sh in Makefile.in Actually the next phase of my plan was to understand the use of autotools, and apply them to the gnome 2 packages. It should be easier there because gnome 2 has standardised on autoconf 2.5.x, whereas the gnome 1.4 packages use various old autoconf/automake versions. I have not been in any hurry though because gnome 2 is still changing much too quickly for me to have a hope of keeping up. Steven
Re: By the way...
On Tue, 30 Apr 2002 10:57:46 -0400 Charles Wilson [EMAIL PROTECTED] wrote: Harold Hunt wrote: ... I added a link to your Cygwin Gnome page to Cygwin/XFree86's Ported Software page: http://xfree86.cygwin.com/ported-software.html I'm very impressed with your work to compile Gnome with DLLs. Keep it up! A couple of things: 1) pkgconfig. I'm the cygwin pkgconfig maintainer, and I'd like to insure that you can use the official version in your port. You are using a patched version of 0.8.0; cygwin distributes 0.10.0; but 0.12.0 is now available. Could you try 0.12.0 (unpatched and/or patched) and see if that works for you? I'll add that to the list of jobs ... When I started work on gnome-vfs pkg-config was not in the official cygwin distribution and 0.8.0 was the latest version. I patched it to remove the included glib, so that it uses my glib port. When pkgconfig was added to cygwin I tried it, but gnome-vfs would not build, so I just ignored it. My focus was, and still is, on gnome so doing more work on pkgconfig was of no interest. But I'll certainly try the new one. If you must use a patched version of 0.12.0, then I'd consider incorporating that patch into the official cygwin dist; also, in that case, we could submit your patch upstream for incorporation into the real 0.13.0... As the patch just removes the embedded glib, I think its of no use to the real pkgconfig. 3) cygextras: why not submit these as patches to the cygwin DLL? If it is because the code is from gnu libc, then you could in partnership with someone else, reimplement them and submit the result: your partner would actually write the code to the specifications you develop; you would verify that the result operates the same as the current version. (Chinese Firewall). Then, assign copyright on the reimplementations to Red Hat/Cygwin, and submit! cygextras contains strptime and getdelim. I understand the strptime is coming soon to cygwin anyway, so I'll just drop mine then. getdelim came from the gnu C library. Again its just a distraction from working on gnome, and I'll leave it to others to add it to cygwin. 4) berkeley db: folks have been asking for this for a long time. Would you consider packaging it up and submitting it as an official package? (Don't worry about the tcl thing; you needn't be able to run the test suite on an official ports only system). side note: any idea why Gnome doesn't use the GNU database instead? gdbm? No. I don't have any free time to support cygwin packages, although I do have great respect for those, such as yourself, who do. I think that gnome no longer requires version 2.7.7, but has moved on to version 3.x.x. This patched version did actually pass its test suite when I first did it, but I no longer have access to the cygwin tcl port I used, so I cannot reproduce the result. Steven
Display CDE through ssh?
Hello there! I am totaly new to this project. Installed cygwin/XFree86 like told in the documentation. Also managed to connect to my university through ssh and started some x-applications like mozill etc. by following the documentation. Beautifull! The machines at the university run HPUX with CDE. Is it possible to get the CDE-userinterface shown remoteley (like realy sitting infront of one). Greetings, Nils
Re: By the way...
Steven O'Brien wrote: 1) pkgconfig. I'm the cygwin pkgconfig maintainer, and I'd like I'll add that to the list of jobs ... When I started work on gnome-vfs pkg-config was not in the official cygwin distribution and 0.8.0 was the latest version. I patched it to remove the included glib, so that it uses my glib port. When pkgconfig was added to cygwin I tried it, but gnome-vfs would not build, so I just ignored it. My focus was, and still is, on gnome so doing more work on pkgconfig was of no interest. But I'll certainly try the new one. What was the rationale for removing the included glib? It was put into pkgconfig in order to break the recursive dependence: glib requires pkgconfig which requires glib which ... Granted, the version of glib included in pkgconfig is old (but it's capable enough for what pkgconfig needs) and has a one-line bug when compiling on cygwin; I just patch that and move on... Anyway, if your version of pkgconfig (0.8.0 + local glib) compiled gnome-vfs (on a particular date), yet the official cygwin version of pkgconfig (0.10.0) failed to do so: I would think the problem is either: something broke in the real pkgconfig sources between 0.8.0 and 0.10.0 or gnome-vfs (on the particular date) was either exploiting a bug in pkgconfig-0.8.0, or was otherwise broken. I don't think the answer is to use (and recommend) that cygwinners who want gnome use a old version of pkgconfig with a circular dependency... Thanks for offering to try with real pkgconfig-0.12.0. You'll probably need to apply this patch (if you keep the included static glib): --- pkgconfig-0.10.0-orig/glib-1.2.8/gstrfuncs.cMon Apr 17 11:05:16 2000 +++ pkgconfig-0.10.0/glib-1.2.8/gstrfuncs.c Sat Feb 23 01:38:15 2002 -671,7 +671,7 char *msg; #ifdef HAVE_STRSIGNAL - extern char *strsignal (int sig); + extern const char *strsignal (int sig); return strsignal (signum); #elif NO_SYS_SIGLIST switch (signum) I look forward to seeing the results of your experiment. If you must use a patched version of 0.12.0, then I'd consider incorporating that patch into the official cygwin dist; also, in that case, we could submit your patch upstream for incorporation into the real 0.13.0... As the patch just removes the embedded glib, I think its of no use to the real pkgconfig. Yep, you're right. 3) cygextras: why not submit these as patches to the cygwin DLL? cygextras contains strptime and getdelim. I understand the strptime is coming soon to cygwin anyway, so I'll just drop mine then. getdelim came from the gnu C library. Again its just a distraction from working on gnome, and I'll leave it to others to add it to cygwin. Understood. 4) berkeley db: folks have been asking for this for a long time. No. I don't have any free time to support cygwin packages, although I do have great respect for those, such as yourself, who do. I think that gnome no longer requires version 2.7.7, but has moved on to version 3.x.x. This patched version did actually pass its test suite when I first did it, but I no longer have access to the cygwin tcl port I used, so I cannot reproduce the result. 'Kay. Looks like there's a volunteer on the case... --Chuck
RE: mkdll.sh
Chuck, Excellent. You know that your write-up won't be a wasted effort on me. :) I'll be looking at this next week. Harold -Original Message- From: Charles Wilson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 11:48 AM To: Harold Hunt Cc: cygx Subject: Re: mkdll.sh Harold Hunt wrote: Chuck, Could you give a few more notes on relibtoolize? A pointer to some good documentation would be helpful... Well, there's the goat book http://sources.redhat.com/autobook/ but it's a bit out of date, now... Here's the procedure I used to relibtoolize libiconv. Libiconv is a worst-case example: they distribute their own fork of autoconf itself, they redistribute system m4 macros, ... they're just plain evil. But, if you can understand *this*, then relibtoolizing anything else should be a piece of cake... Short version: remove autogenerated files. Replace standard files with the newest versions (install-sh, mkinstalldirs, config.guess, config.sub) -- you can also just remove these and let the autotools copy in what they need (use the --force --c -a switches, or their analog: not every tool has exactly the same syntax). Rerun the the autotools in the proper order (more later). #1) libiconv actually ships its OWN VERSION of autoconf. This is dumb. rm autoconf/acgeneral.m4 rm autoconf/acspecific.m4 rm autoconf/aclocal.m4 rm autoconf/autoconf rm autoconf/autoconf.m4 rm autoconf/mbstate_t.m4 #2) remove the normal distribution files that are created by autoconf. rm autoconf/install-sh rm autoconf/config.guess rm autoconf/config.sub rm configure #3) remove the obsolete libtool files (libtool no longer uses ltmain.sh) rm autoconf/ltmain.sh #4) I don't like hiding the autofiles, so I removed the subdir and will change configure.in appropriately, but you don't have to do that. rmdir autoconf #5) libiconv doesn't use automake, but it does distribute some scripts from automake. Replace them with the current versions. (Actually, libiconv only distributed install-sh; it used the mkinstalldirs from the libcharset subdirectory, proper auto* usage requires that each separately configure project have its own copy...and of course, I put install-sh in the top directory, libiconv had it in the autoconf subdir) cp /usr/autotool/devel/share/automake/mkinstalldirs . cp /usr/autotool/devel/share/automake/install-sh . #6) repeat steps 1-4 for the libcharset subdirectory. Normally, this is unnecessary, but libiconv actually treats libcharset as a separate project, with it's own configure script and suchlike... rm libcharset/autoconf/aclocal.m4 rm libcharset/autoconf/mkinstalldirs rm libcharset/autoconf/install-sh rm libcharset/autoconf/config.guess rm libcharset/autoconf/config.sub rm libcharset/autoconf/ltmain.sh rm libcharset/configure rmdir libcharset/autoconf #7) libcharset also includes its own copies of some .m4 scripts that are part of gettext. Use the system ones. rm libcharset/m4/codeset.m4 rm libcharset/m4/glibc21.m4 #8) AND we're going to use the system libtool...and cleanup. rm libcharset/m4/libtool.m4 rm libcharset/m4/ChangeLog rmdir libcharset/m4 #9) Similar to step #5, replace the automake files with the latest version (even though libcharset doesn't use automake...). Both mkinstalldirs and install-sh WERE in the autoconf subdir of libcharset; I put them in the top level (of libcharset). Each separately configured project needs its own copy... cp /usr/autotool/devel/share/automake/mkinstalldirs libcharset/ cp /usr/autotool/devel/share/automake/install-sh libcharset/ #10) As promised, I need to change a few items in configure.in (e.g. don't use the autoconf subdir (or libcharset/autoconf or libcharset/m4). Also, since the special versions of the autoconf files that libiconv distributes were slightly modified -- okay, they were distributing a fork -- I parsed out the differences they had, and put those macros into acinclude.m4... The patch is attached. The patch also AC_PREREQ's 2.52 instead of 2.13 (I want to use the -devel tree), but that required a few other changes due to incompatibilities (AC_OUTPUT_SUBDIRS --- AC_CONFIG_SUBDIRS, etc) Normally, you'd also re-run autoheader at some point, but that didn't work (thanks to the fact that libiconv uses a forked autoconf dist...) So I patched libcharset/config.h.in by hand... #11) Okay, here's the meat: First, we relibtoolize libcharset: cd libcharset aclocal libtoolize -c -f aclocal # (again) autoconf cd topsrc aclocal libtoolize -c -f aclocal # (again) autoconf Why the second aclocal step? Because libtoolize adds additional stuff in configure.in, which require additional macros to be pulled into aclocal.m4. Why not run libtoolize first, and then aclocal? Because libtoolize needs a pre-existing aclocal.m4... Normally, you'd run automake -a -c between the second aclocal and autoconf, but libiconv
Short-term personal status
Final exams are this week and I graduate from Michigan State University on Saturday with my Computational Mathematics B.S. Actually, I receive my degree at the end of the summer because I am taking one more summer class, but that's just so I get charged the undergraduate rate instead of the graduate rate. In the fall I start my Computer Science Master's program at MSU. My fiancé keeps putting me in trouble when she catches me working on Cygwin/XFree86 instead of studying for my exams that are on Wednesday and Thursday. Thus, I must take a couple days off of replying to emails and working on the project. I'll be back on Sunday or Monday. Note: my huntharo-4.user.msu.edu machine will be going offline Thursday afternoon. That shouldn't make a difference to anyone, except that archives of links to that machine will be dead. (This is because I am moving out of the dorm... I'll go from 10BaseT to a cable modem.) That's all for now, Harold
RE: upset stumper [cgf, Robert Collins, please comment]
-Original Message- From: Harold Hunt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 12:25 AM To: Robert Collins; cygx Subject: RE: upset stumper [cgf, Robert Collins, please comment] Robert, I forgot to reply last night that I had hand-fixed the setup.ini file and setup.exe ran fine after that. Cool. Rob
problem with telnet and ftp server on win 2K
I've discovered that I cannot successfully telnet into my Win 2K box using the cygwin inetd, there is also a problem with the ftp service. I've installed inetd as per instructions, and installed it as a service. When I use telnet to attempt to log in, everything goes OK until the point where a shell should be started, at that point I get a pop-up box appearing on my Win 2K screen with the title bash.exe - Application Error and the text The application failed to initialize properly (0xc022). Click on OK to terminate the application. When I click on OK my telnet session ends with the message Connection closed by foreign host. When I use ftp to connect to the Win 2K box, the connection succeeds, and I can transfer files in both directions, but when I use the DIR command, I get a pop-up box appearing on the Win 2K screen exactly as for telnet described above, except that the first word of the title is ls.exe instead of bash.exe. If you have any information, or if you can confirm that this is a bug, please let me know. Thanks. _ Join the worldÂ’s largest e-mail service with MSN Hotmail. http://www.hotmail.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
problem with telnet and ftp server on win 2K
On Tuesday 30 Apr 02, John Vincent writes: I've discovered that I cannot successfully telnet into my Win 2K box using the cygwin inetd, there is also a problem with the ftp service. I've installed inetd as per instructions, and installed it as a service. When I use telnet to attempt to log in, everything goes OK until the point where a shell should be started, at that point I get a pop-up box appearing on my Win 2K screen with the title bash.exe - Application Error and the text The application failed to initialize properly (0xc022). Click on OK to terminate the application. When I click on OK my telnet session ends with the message Connection closed by foreign host. This has been discussed on the mailing list before, search the archives. I noticed it with cygwin-1.3.10 on NT4, and found that enabling ntsec solved the problem for me. But there are lots of things to check, like the correctness of your /etc/passwd and /etc/group files, rights given to the inetd service account, execute permissions on the applications and cygwin1.dll, ... It's a mystery, to me, why it fails without ntsec but works with ntsec, all other things being the same. But I've stopped worrying about it, now that I use ntsec. Good luck. Report back if you have something new to add. Regards, David -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with texi2dvi
I've found a bug in the texi2dvi script when it is run under Cygwin. As can be seen from the folowing lines the path separator is set to ';' when run under Cygwin. /usr/bin/texi2dvi lines 99-105 # Systems which define $COMSPEC or $ComSpec use semicolons to separate # directories in TEXINPUTS. if test -n $COMSPEC$ComSpec; then path_sep=; else path_sep=: fi Gary _ Get your FREE E-mail Gibweb.net. Visit www.GibWeb.net for Gibraltar weather,news,lottery results,search and much more. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Setup.exe problem?
Hi folks, Not sure if this is correct mailing list. Tried using latest version of setup.exe on Win9x. Turned out it didn't work when I used Direct Connection option (cable is direct connection to internet). Using ie6 connection options worked though. Anyway, just wanted to let folks know. Paul G. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: problem with telnet and ftp server on win 2K
Hi David, Thanks for the info. I created a system-wide environment variable using the control panel called CYGWIN with a value of ntsec and rebooted, and now telnet and ftp are working fine! Thanks for your help. /John From: David Starks-Browning [EMAIL PROTECTED] To: John Vincent [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: problem with telnet and ftp server on win 2K Date: Tue, 30 Apr 2002 11:41:50 +0100 On Tuesday 30 Apr 02, John Vincent writes: I've discovered that I cannot successfully telnet into my Win 2K box using the cygwin inetd, there is also a problem with the ftp service. I've installed inetd as per instructions, and installed it as a service. When I use telnet to attempt to log in, everything goes OK until the point where a shell should be started, at that point I get a pop-up box appearing on my Win 2K screen with the title bash.exe - Application Error and the text The application failed to initialize properly (0xc022). Click on OK to terminate the application. When I click on OK my telnet session ends with the message Connection closed by foreign host. This has been discussed on the mailing list before, search the archives. I noticed it with cygwin-1.3.10 on NT4, and found that enabling ntsec solved the problem for me. But there are lots of things to check, like the correctness of your /etc/passwd and /etc/group files, rights given to the inetd service account, execute permissions on the applications and cygwin1.dll, ... It's a mystery, to me, why it fails without ntsec but works with ntsec, all other things being the same. But I've stopped worrying about it, now that I use ntsec. Good luck. Report back if you have something new to add. Regards, David _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Using a real mirroring tool...
Charles Wilson wrote in [EMAIL PROTECTED] in gmane.os.cygwin on Mon, 29 Apr 2002 16:04:14 -0400: P.S. you might want to add --exclude *-src.tar.* to the option string, if you don't want the -src tarballs. As I understand it you can also exclude the setup.hint and md5.sum files if you're just populating a local package directory. They're very small but every little helps and it reduces the clutter and can save a few sectors on the local disc. Or am I missing something? (Again do I hear from the chorus? Kindly leave the auditorium, sir!) ;-) -- Sam Edge -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
advise on using fetchmail
On Tuesday 30 Apr 02, Mark Cooke writes: Ive created a /etc/hosts and inserted the correct info, but I still get the error, It doesn't go in /etc/hosts. On NT, it goes in C:\WINNT\System32\drivers\etc\HOSTS (or equivalent for your NT installation). Sorry, I know this belongs in the FAQ. Regards, David (Cygwin FAQ maintainer) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
using Windows links
I know this has been discussed quite a bit from various angles, but after hours of searching through the mail archive, I can't seem to find the angle that's important to me. I can create fine shortcuts with ln -s which are accessible by Windows, but I can't seem to be able to use Windows Shortcuts with Cygwin. I might have resignedly accepted this as a consequence of having a great interface on a crummy os, except that I *could* follow Window's shortcuts before I just upgraded to 1.3.10. For example, there are all kinds of shortcuts scattered around my filesystem which have been installed by my company's tools which I used to be able to call from bash and put in the background. Then I could Alt-tab to that window and use the keyboard. Or, do an ls -l on them and see where they point to. Since 1.3.10, that doesn't work anymore: now I've always got to go reaching for the mouse. An interesting side effect: I have a shortcut (Desktop.lnk) on my $HOME that was originally created by Windows. I can't cd there anymore. I tried to create a second link for Cygwin (Desktop), but ln tells me it already exists! $ ln -s $nt/Desktop Desktop /bin/ln: creating symbolic link `Desktop' to `/cygdrive/c/WINNT/Profiles/mt099378/Desktop': File exists Thus, even though Desktop.lnk isn't recognized as anything special, it is anyway! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using Windows links
At 09:50 AM 4/30/2002, Mellman Thomas wrote: I know this has been discussed quite a bit from various angles, but after hours of searching through the mail archive, I can't seem to find the angle that's important to me. I can create fine shortcuts with ln -s which are accessible by Windows, but I can't seem to be able to use Windows Shortcuts with Cygwin. I might have resignedly accepted this as a consequence of having a great interface on a crummy os, except that I *could* follow Window's shortcuts before I just upgraded to 1.3.10. For example, there are all kinds of shortcuts scattered around my filesystem which have been installed by my company's tools which I used to be able to call from bash and put in the background. Then I could Alt-tab to that window and use the keyboard. Or, do an ls -l on them and see where they point to. Since 1.3.10, that doesn't work anymore: now I've always got to go reaching for the mouse. An interesting side effect: I have a shortcut (Desktop.lnk) on my $HOME that was originally created by Windows. I can't cd there anymore. I tried to create a second link for Cygwin (Desktop), but ln tells me it already exists! $ ln -s $nt/Desktop Desktop /bin/ln: creating symbolic link `Desktop' to `/cygdrive/c/WINNT/Profiles/mt099378/Desktop': File exists Thus, even though Desktop.lnk isn't recognized as anything special, it is anyway! Just because it isn't recognized as a Cygwin symbolic link doesn't mean it doesn't exist as a file as far as Cygwin is concerned. I guess you missed the discussion in the email archives (was it at cygwin-developers?) about the problems of following shortcuts made by Windows as symbolic links. I won't review them here but suffice it to say that treating Windows created shortcuts as symbolic links is a whole lot of trouble. Initial implementation of Cygwin symlinks as shortcuts ignored this issue (because it wasn't known to be a problem). The current implementation only follows Cygwin-created (via ln -s) shortcuts as a result. You probably had a previous version of Cygwin which implemented shortcuts as symlinks before these problems were noticed. Sorry but this is the new state of things. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
inetd / ftpd file permissions
hello cygwinners, i have a little problem again (bad week). i started using cygwin's ftp server instead of NT's. its working fine but the default permissions for the files are different and they are causing problems with some of my scripts. i searched the web and found the exact answer for this problem: a wrapper script (but not specifically for cygwin). i then 1) installed the wrapper under /usr/sbin/in.ftpd-wrapper.sh and chmoded it to 755. contents: #!/bin/sh umask 666 exec /usr/sbin/in.ftpd 2) changed my /etc/inetd.conf to ftp stream tcp nowait root/usr/sbin/in.ftpd-wrapper.sh in.ftpd-wrapper.sh 3) stopped and started the service. unfortunately, i still get my files transferred with 022 permissions. i couldn't find anything in cygwin's mailing list about this. is this the right way to do it for cygwin? thanks for your time. marco -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Lowest section message
In conjunction with a terrible bug I'm working on, each time I start my application in gdb I get the following error message from gdb: Lowest section in /cygdrive/c/WINDOWS/System32/WMI.dll is text at 76d31000 Anyone know what the significance of this is? Thanks. -- Michael -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: advise on using fetchmail
On Tue, 30 Apr 2002, David Starks-Browning wrote: On Tuesday 30 Apr 02, Mark Cooke writes: Ive created a /etc/hosts and inserted the correct info, but I still get the error, It doesn't go in /etc/hosts. On NT, it goes in C:\WINNT\System32\drivers\etc\HOSTS (or equivalent for your NT installation). Sorry, I know this belongs in the FAQ. Cheers.. but has anyone seen the error msg that I get when I run fetchmail? Mark - --- Mark Cooke Internet Operations Technician MM Group Ltd Tel: 8141 (Internal) Tel: (0117) 9168141 (External) Email: [EMAIL PROTECTED] http://www.mmgroup.co.uk -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: advise on using fetchmail
On Tue, Apr 30, 2002 at 02:09:44PM +0100, Mark Cooke wrote: fetchmail -u mark results in this error all the time: fetchmail: SMTP connect to localhost failed fetchmail: can't raise the listener; falling back to /usr/local/bin/procmail -d %T I have never seen the above error message. I have been successful using the the following .fetchmailrc file: set logfile /var/log/fetchmail.log set invisible # suppress Received: line fetchmail adds set no bouncemail poll my.server.net# *** change as appropriate *** protocol pop3 username MyUserName # *** change as appropriate *** password MyPassword # *** change as appropriate *** fetchall nokeep # delete successfully received messages mda /usr/local/bin/procmail -d %T # pass message to the local MDA Is your .fetchmailrc file similar to the above? Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Using a real mirroring tool...
Hi!
Charles Wilson wrote:
A few notes:
...
rsync can't merge.
Yes, but Michael A. Chases clean_setup.pl can! I allowed myself to add a
new option to clean_setup.pl, it exports the list of missing files to a
file. Then you can use wget to get all the missing files.
I attached the modified clean_setup.pl plus a shell scrip to get the
missing files from a mirror. You have to modify the getmissing.sh to
choose your mirror and your target download directory. The directory and
both files must exist the same directory as your setup.exe. Just a quick
hack, I guarantee nothing!
Use the attached getmissing.sh instead, some options for wget were not
correct, they left directory listing files.
Bye
Volker
#!/bin/bash
# Mirror script for cygwin
# Uses Michael A. Chase cleanup_setup.pl
# in a modified version (V1.0303)
# and wget
# getmissing.sh and cleanup_setup.pl must reside in the same directory
# as setup.exe
# Files to download
filelist=missing.lst
# Choose your mirror with directory of setup.ini
#mirror=ftp://ftp.inf.tu-dresden.de/software/windows/cygwin32/;
# Cut directories 12 3
mirror=ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/;
# Cut directories 1 2 3
cutdir=3
# Name your download directory
mirrordir=_mymirror
wget -r -N --no-host-directories --cut-dirs=$cutdir --passive-ftp -P $mirrordir
${mirror}setup.ini
./clean_setup.pl -writelist
wget -r -N --no-host-directories --cut-dirs=$cutdir --passive-ftp -P $mirrordir -i
$filelist -B $mirror
./clean_setup.pl -Arch -Setup
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Bug in stat()?
I am running into weird behavior with stat(). I am getting the same
st_ino number for two distinct directories. When using the jikes
compiler on the GNU Classpath project (the upstream source of libjava in
gcc), jikes is keying off of the inode number to determine where to
write .class files. Because the inode number is a duplicate, jikes is
making the wrong choice, and then failing to compile.
I've simplified the demonstration of the problem as follows:
$ cd /tmp
$ cat blah.cpp
#include sys/stat.h
#include stdio.h
int main(int argc, char** argv)
{
struct stat status;
int result;
result = stat(./java/net, status);
printf(net (%d): %d, %d\n, result, status.st_dev, status.st_ino);
result = stat(./java/nio, status);
printf(nio (%d): %d, %d\n, result, status.st_dev, status.st_ino);
return 0;
}
$ g++ blah.cpp -o blah
$ cd ~/cp/lib
$ rm -Rf java
$ mkdir java java/net
$ /tmp/blah
net (0): 4096, 547532427
nio (-1): 0, 0
$ mkdir java/nio
$ /tmp/blah
net (0): 4096, 547532427
nio (0): 4096, 547532427
$ cd /tmp
$ rm -Rf java
$ mkdir java java/net java/nio
$ /tmp/blah
net (0): 4096, 314387057
nio (0): 4096, 311437853
Notice that in the /tmp directory, stat() correctly gave different
st_ino values for the two newly created directories. However, in
~/cp/lib, BOTH directories are given the inode of 547532427, even though
they are distinct objects.
Is there a bug in the implementation of sys/stat.h? I am running the
latest version of cygwin (1.3.10-1) and gcc (2.95.3-5) unmodified, with
the root directory located at d:\cygwin on a Win98 box.
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.3.10: Permission Denied error (EACCES 13) on Win98SE
I've compiled and ran the test case on a Linux 2.4 kernel system without error (Mandrake 8.0) and on Cygwin 1.3.10 hosted on Win2k, also without error. I need to determine if this failure can be replicated on any other Win98 hosted Cygwin 1.3.10 install or if the failure is unique to my setup. There may be a compatibility implication on running Cygwin on a Win98 host. I need some feedback from anyone on the list who has hosted Cygwin 1.3.10 on a Win98 machine and would be willing to compile and run the test case that I submitted in my original post. There does appear to be a difference in the response that Cygwin 1.3.10 elicits from the host operating system in the attempt to open a directory Read Only. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin installation.
On Tue, 30 Apr 2002 16:54:58 -0400 dave [EMAIL PROTECTED] wrote: I've been trying to install cygwin for the past two days and i'm not getting very far. I'm selecting admin, archive, base, database, doc, devel, interpreters, libs, math, net, shells, text, utils, and web, however it only appears to download minimal components. On the menu of packages i ensure that the above mentioned packages have the word install selected. Please try one more time and note down the options selected in each screen. Any popup windows that appear would also be interesting. -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.html Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: RES: cygwin installation.
Hi, Any ideas as to what's wrong? I've installed cygwin this way before and this is the first time i've had this problem. Some unrelated information, it might help, sometimes when i go to download packages the setup immediately says download complete and it has done nothing. Dave. - Original Message - From: Christopher Faylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 30, 2002 5:26 PM Subject: Re: RES: cygwin installation. On Tue, Apr 30, 2002 at 06:23:26PM -0300, Eduardo Rocha Costa wrote: Click on the plus sign on each of this components then select individual packages... then you will be able to download all the softwares that you want.. This shouldn't be necessary if you're selecting things as the message below describes. If selecting the category isn't working then something is wrong. cgf I've been trying to install cygwin for the past two days and i'm not getting very far. I'm selecting admin, archive, base, database, doc, devel, interpreters, libs, math, net, shells, text, utils, and web, however it only appears to download minimal components. On the menu of packages i ensure that the above mentioned packages have the word install selected. Any suggestions? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Patch: Re: Bug in stat()?
Eric Blake wrote:
I am running into weird behavior with stat(). I am getting the same
st_ino number for two distinct directories. When using the jikes
compiler on the GNU Classpath project (the upstream source of libjava in
gcc), jikes is keying off of the inode number to determine where to
write .class files. Because the inode number is a duplicate, jikes is
making the wrong choice, and then failing to compile.
After some poking around, I see that stat() fills in st_ino using a hash
function on the absolute file name (since Windows does not understand the
concept of inodes). I confirmed that there is a bug in the hashing function
- it is not a strong enough hash. The culprit is in winsup/cygwin/path.cc,
in hash_path_name().
My updated demonstration follows. Notice that it is sensitive to the
directory you run it in; while there are certainly other directories that
would show this problem, the bug does not surface in all directories.
$ cygpath -aw `pwd`
d:\cygwin\home\eblake\cp\lib
$ cat blah.java
#include sys/stat.h
#include stdio.h
int main(int argc, char** argv)
{
/* Print results obtained from cygwin */
struct stat status;
int result;
result = stat(./java, status);
printf(./java (%d): %x, %x\n, result, status.st_dev, status.st_ino);
result = stat(./java/net, status);
printf(net (%d): %x, %x\n, result, status.st_dev, status.st_ino);
result = stat(./java/nio, status);
printf(nio (%d): %x, %x\n, result, status.st_dev, status.st_ino);
/* morph from ./java to ./java/net */
unsigned int hash = 0x210fd907;
printf(%x\n, hash);
int ch = '\\';
hash += ch + (ch 17);
hash ^= hash 2;
printf(%x\n, hash);
ch = 'n';
hash += ch + (ch 17);
hash ^= hash 2;
printf(%x\n, hash);
ch = 'e';
hash += ch + (ch 17);
hash ^= hash 2;
printf(%x\n, hash);
ch = 't';
hash += ch + (ch 17);
hash ^= hash 2;
printf(%x\n\n, hash);
/* morph from ./java to ./java/nio */
hash = 0x210fd907;
printf(%x\n, hash);
ch = '\\';
hash += ch + (ch 17);
hash ^= hash 2;
printf(%x\n, hash);
ch = 'n';
hash += ch + (ch 17);
hash ^= hash 2;
printf(%x\n, hash);
ch = 'i';
hash += ch + (ch 17);
hash ^= hash 2;
printf(%x\n, hash);
ch = 'o';
hash += ch + (ch 17);
hash ^= hash 2;
printf(%x\n, hash);
return 0;
}
$ ./blah.exe
./java (0): 1000, 210fd907
net (0): 1000, 20a2ae8b
nio (0): 1000, 20a2ae8b
210fd907
29b62f3b
2036a443
29408d82
20a2ae8b
210fd907
29b62f3b
2036a443
294a8d87
20a2ae8b
Notice that from the inode hash of ./java, with cwd of
d:\cygwin\home\eblake\cp\lib, I was able to match the inode hash of both
./java/net and ./java/nio using the two lines
hash += ch + (ch 17);
hash ^= hash 2;
from path.cc. The two hashes are different after \\ne and \\ni, but
converge again when appending 't' and 'o' respectively.
I'm not a hashing expert, but I suggest that you try the hashing algorithm
used in the Java programming language for java.lang.String.hashCode(), as
shown in my patch below. I think it is a stronger hash, and I know that it
would solve my problem, with less computation per character.
2002-04-30 Eric Blake [EMAIL PROTECTED]
* path.cc (hash_path_name): Improve hash function strength.
$ diff -u path.cc.bak path.cc
--- path.cc.bak Tue Apr 30 16:32:52 2002
+++ path.cc Tue Apr 30 16:40:14 2002
@@ -3136,7 +3136,7 @@
hash = cygheap-cwd.get_hash ();
if (name[0] == '.' name[1] == '\0')
return hash;
- hash += hash_path_name (hash, \\);
+ hash = (hash 5) - hash + '\\';
}
}
@@ -3146,8 +3146,7 @@
do
{
int ch = cyg_tolower(*name);
- hash += ch + (ch 17);
- hash ^= hash 2;
+ hash = (hash 5) - hash + ch;
}
while (*++name != '\0'
!(*name == '\\' (!name[1] || (name[1] == '.' !name[2];
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
support for multicast socket
Hi,
I'm porting a network protocol (about 50K lines of code) developed in
UNIX into cygwin, and I ran into problems when I want to open a
multicast socket.
When I bind() a network socket to a multicast address/port, I got an
error EADDRNOTAVAIL. Below is a distilled sample code, sample output,
and my cygwin configuration.
Has anyone been successful in using multicast in cygwin? If multicast
socket is not currently implemented in cygwin, are there plans to
implement it in the near future? Any pointer is much appreciated.
Thanks. Yang-hua
--
Sample code to open a multicast socket
#include stdlib.h
#include string.h
#include errno.h
#include strings.h
#include unistd.h
#include stdio.h
#include netdb.h
#include sys/socket.h
#include netinet/in.h /* sockaddr_in{} and other Internet defns */
int main(int argc, char *argv[]) {
char *name = 235.1.2.3;
int port = 5000;
// resolve the IP address
struct hostent *host;
if ((host = gethostbyname(name)) == NULL) {
printf(\nhostname %s not found, name);
return -1;
}
int ip = htonl(*(int *)host-h_addr);
int fd = socket(AF_INET, SOCK_DGRAM, 0);
struct sockaddr_in sock;
bzero((char *)(sock), sizeof(sock));
sock.sin_family = AF_INET;
sock.sin_addr.s_addr = htonl(ip);
sock.sin_port = htons(port);
if (bind(fd, (struct sockaddr *)sock, sizeof(sock)) 0) {
perror(bind);
} else {
printf(bind to multicast address OK\n);
}
close(fd);
}
Sample output
[yhchu]/cygdrive/c/:{555}:$ ./a.exe
bind: errno EADDRNOTAVAIL triggered
-
Other relevant information about my cygwin
Cygwin Win95/NT Configuration Diagnostics
Current System Time: Tue Apr 30 18:55:29 2002
Windows NT Ver 4.0 Build 1381 Service Pack 5
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
c:\Perl\bin\
c:\WINNT\system32
c:\WINNT
c:\PROGRA~1\CMU\KCLIENT\bin32
c:\PROGRA~1\Transarc\AFS\AFSCLI~1\PROGRAM
c:\WINNT\System32\WBEM
C:\cygwin\bin
c:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT
c:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
c:\Program Files\Microsoft Visual Studio\Common\Tools
c:\Program Files\Microsoft Visual Studio\VC98\bin
SysDir: C:\WINNT\System32
WinDir: C:\WINNT
CYGWIN = `ntsec tty'
HOME = `c:\'
MAKE_MODE = `unix'
PWD = `/cygdrive/h/cmcl-yhchu/yhchu/Code'
USER = `yhchu'
751k 2002/02/25 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
cygwin1.dll v0.0 ts=2002/2/25 11:14
Cygwin DLL version info:
DLL version: 1.3.10
DLL epoch: 19
DLL bad signal mask: 19005
DLL old termios: 5
DLL malloc env: 28
API major: 0
API minor: 51
Shared data: 3
DLL identifier: cygwin1
Mount registry: 2
Cygnus registry name: Cygnus Solutions
Cygwin registry name: Cygwin
Program options name: Program Options
Cygwin mount registry name: mounts v2
Cygdrive flags: cygdrive flags
Cygdrive prefix: cygdrive prefix
Cygdrive default prefix:
Build date: Mon Feb 25 11:14:34 EST 2002
Shared id: cygwin1S3
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Using a real mirroring tool...
You might want to check out http://mirrors.rcn.net/pub/mirror/index.html for a mirroring tool that uses perl for ftp/http access. Earnie. ---BeginMessage--- Charles Wilson wrote: So, if someone cares enough to do the work, there is still a need for the additional tool that uses the setup.exe codebase to do cygwin-specific distributed mirroring. See my earlier rant. Oh, I left out the most obvious reason why rsync won't solve all of our problems: we have lots of ftp and http mirrors, but very few (ONE?) rsync mirrors. That really kills the distributed nature of the mirror system; that poor guy in Thailand with the slow connection would be rsync'ing across the Pacific from Indiana...that can't be good. A tool that leverages the setup.exe codebase would inherit the ability to use the existing ftp and http mirror sites. --Chuck /stating the obvious P.S. you might want to add --exclude *-src.tar.* to the option string, if you don't want the -src tarballs. ---End Message--- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Work From Home
LAVORO DA CASA - i miei bambini vengono all'ufficio ogni giorno! GUADAGNI $500 - $1500 P/T O i $2000 - $4000 F/T SUPPLEMENTARI AL MESE ore flessibili , nessun'esperienza necessaria Forniamo l'addestramento ed il supporto completi. Siete pronti a cambiare la vostra vita? VISITA: http://www.jobblow.com WORK FROM HOME - My Children Come to the Office Every Day! EARN AN EXTRA $500 - $1500 P/T OR $2000 - $4000 F/T per month Flexible hours, no experience necessary. We provide full training and support. Are you ready to change your life? VISIT: http://www.jobblow.com NO SPAM !! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Man Pages for posix/pthread
I am new to cygwin, and couldn't find any help about this. I installed with man , gcc etc but there is no man page for pthread Have I installed something wrong or need to edit man.conf or something like that? I couldn't find any pthread pages by doing a find either. Is it included with the cygwin distribution? If they aren't can I download/install them from somewhere? man works fine for other functions e.g. printf etc. Thanks Peter Conklin ** - NOTICE - This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. Dimension Data Australia Pty Limited was formerly known as Com Tech Communications Pty Ltd ** -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
trouble again downloading.
Hi, Ok i spoke to soon. I've got the base, i've got shells, but i'm unable to get net, admin, archive, devel, doc, and database. Here are my logs if that helps anyone. Thanks. Dave. setup.log.full Description: Binary data setup.log Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
