Re: WIN32: save MSVC files with CR+LF?
At 03:02 PM 8/28/2004, Cliff Woolley wrote: Normally Bill Rowe will come along behind and build a .zip of the distribution that was checked out using a Win32 version of CVS so that *all* of the files have DOS line endings. The .tar.gz and .tar.Z distributions always have unix line endings. Actually, apr/build/lineends.pl will do that nicely for anyone who has perl installed, even from the .tar.gz's :) To Klaus's comments; On Sat, 28 Aug 2004, Klaus Keppler wrote: Suggestion: the following MSVC files should be saved with CR+LF (if that's possible?), so you can open them out-of-the-box with Visual C++ 6.0. Actually you always have to convert these files right after unpacking the archive file. The .dsp / .dsw / .mak files you mention are only a handful of the TEXT FILES we distribute with the package. Unix filesystems have \n lineends. Win32 has \r\n endings. Anyone who wants to contend with a mishmash has my blessing on their system but not in our repository! Why do I shake violently at fools who commit such files as binary \r\n line endings? My reasons are really trivial, and result in massive wastes of time for me. I maintain dozens of patches across platforms which, checked out under unix, neatly patch the unix text files. These same patches also neatly apply when checked out with dos line endings, to dos files on windows. Now - if you work with native files on unix, and then attempt to cvs diff this garbage, you end up with 100% deltas of the files. The bigest offenders are tomcat and php, I frequently have two-line patches to the .dsp files to change library/include paths to my locally employed path envvars. There is no way for me to maintain such patches for both platforms without extra passes through lineends.pl, and then rerunning the files several times to get the cvs diff out of the picture. On top of this mess, I've frequently seen TEXT files in cvs with \r\n endings on unix, which check out under windows cvs as \r\r\n. E. If you are win32'er using cvs, why on earth would you use a port of cvs-like utilities which check out text as \n? If you are a cygwin'er, you use \n text exclusively, you aren't using silly MS tools to ever handle those files (right?) As far as tarballs, httpd and apr toss up a corresponding .zip files in the process, identical to the unix .tar.gz, with the exceptions 1) unix line endings, 2) win32 visual studio 5.0 makefiles (because that version couldn't do command line builds from .dsp files), and 3) some files generated from awk/sed/bison that the user might not be able to generate without extra utilities. If that's not possible, a small notice in the docs would certainly help other people ;-) Seeing as we offer the tool for the job (apr/build/lineends.pl) that sounds like a wonderful idea! Working on a compiling_win32.html fix right now. Bill
Re: WIN32: save MSVC files with CR+LF?
At 08:31 PM 8/28/2004, William A. Rowe, Jr. wrote: On Sat, 28 Aug 2004, Klaus Keppler wrote: If that's not possible, a small notice in the docs would certainly help other people ;-) Seeing as we offer the tool for the job (apr/build/lineends.pl) that sounds like a wonderful idea! Working on a compiling_win32.html fix right now. Updated http://apr.apache.org/compiling_win32.html please tell me what you think. Bill
RE: bug to fix in poll.c
It working
This bug is only in apr_pollset_poll , on apr_poll there is no refilling of the
array
will this fix will go into version 1.0.0 ?
Dror Shilo
Ericom LTD
-Original Message-
From: Joe Orton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 25, 2004 11:40 AM
To: Dror Shilo
Cc: dev@apr.apache.org
Subject: Re: bug to fix in poll.c
On Wed, Aug 25, 2004 at 08:20:49AM +0300, Dror Shilo wrote:
the num parameter have to return the length of descriptors
the select call returns the total number of socket handles that are ready and
contained in the fd_set structures
therefore if we have 2 socket that one have an FD_READ and the second have
FD_READ and FD_WRITE it will return 3 , but the lenght of descriptors is only
2 , this is a bug
there for the fix for this bug is to add this line at file poll.c
(*num) = j;
Thanks for looking into this. I don't have a platform using select() to
hand, but it looks like apr_poll() needs to be fixed too. Can you try
this patch against 0.9.4?
--- poll/unix/poll.c10 Apr 2004 21:29:52 - 1.38.2.2
+++ poll/unix/poll.c25 Aug 2004 08:37:16 -
@@ -244,14 +244,14 @@
}
#endif
-(*nsds) = rv;
-if ((*nsds) == 0) {
+if (rv == 0) {
return APR_TIMEUP;
}
-if ((*nsds) 0) {
+if (rv 0) {
return apr_get_netos_error();
}
-
+
+*nsds = 0;
for (i = 0; i num; i++) {
apr_os_sock_t fd;
@@ -268,14 +268,18 @@
else {
break;
}
-if (FD_ISSET(fd, readset)) {
-aprset[i].rtnevents |= APR_POLLIN;
-}
-if (FD_ISSET(fd, writeset)) {
-aprset[i].rtnevents |= APR_POLLOUT;
-}
-if (FD_ISSET(fd, exceptset)) {
-aprset[i].rtnevents |= APR_POLLERR;
+if (FD_ISSET(fd, readset) || FD_ISSET(fd, writeset) ||
+FD_ISSET(fd, exceptset)) {
+(*nsds)++;
+if (FD_ISSET(fd, readset)) {
+aprset[i].rtnevents |= APR_POLLIN;
+}
+if (FD_ISSET(fd, writeset)) {
+aprset[i].rtnevents |= APR_POLLOUT;
+}
+if (FD_ISSET(fd, exceptset)) {
+aprset[i].rtnevents |= APR_POLLERR;
+}
}
}
@@ -553,8 +557,6 @@
else
#endif
rv = select(pollset-maxfd + 1, readset, writeset, exceptset, tvptr);
-
-(*num) = rv;
if (rv 0) {
return apr_get_netos_error();
}
@@ -590,6 +592,8 @@
j++;
}
}
+
+(*num) = j;
*descriptors = pollset-result_set;
return APR_SUCCESS;
make install doesn't update the .so.0 symlink
It took me a while to figure out what was the problem with some 3rd party library using libapr. Eventually I've discovered that the libapr-0.so.0 symlink wasn't getting updated on 'make install', the old link to an older library was kept intact. Is it a bug? /home/stas/httpd/prefork/lib ls -l libapr-0.so.0 lrwxrwxrwx 1 stas stas 17 Aug 29 12:34 libapr-0.so.0 - libapr-0.so.0.9.5 /home/stas/httpd/prefork/lib cp libapr-0.so.0.9.5 libapr-0.so.0.9.5-old /home/stas/httpd/prefork/lib ln -sf libapr-0.so.0.9.5-old libapr-0.so.0 /home/stas/httpd/prefork/lib ls -l libapr-0.so.0 lrwxrwxrwx 1 stas stas 21 Aug 29 12:49 libapr-0.so.0 - libapr-0.so.0.9.5-old /home/stas/httpd/prefork/lib cd /home/stas/apache.org/httpd-2.0 /home/stas/apache.org/httpd-2.0 make install /home/stas/apache.org/httpd-2.0 cd /home/stas/httpd/prefork/lib /home/stas/httpd/prefork/lib ls -l libapr-0.so.0 lrwxrwxrwx 1 stas stas 21 Aug 29 12:49 libapr-0.so.0 - libapr-0.so.0.9.5-old shouldn't the link go back to libapr-0.so.0.9.5? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: make install doesn't update the .so.0 symlink
On Sun, Aug 29, 2004 at 12:52:30PM -0400, Stas Bekman wrote: It took me a while to figure out what was the problem with some 3rd party library using libapr. Eventually I've discovered that the libapr-0.so.0 symlink wasn't getting updated on 'make install', the old link to an older library was kept intact. Is it a bug? /home/stas/httpd/prefork/lib ls -l libapr-0.so.0 lrwxrwxrwx 1 stas stas 17 Aug 29 12:34 libapr-0.so.0 - libapr-0.so.0.9.5 /home/stas/httpd/prefork/lib cp libapr-0.so.0.9.5 libapr-0.so.0.9.5-old This is an artificial test case - what's the real failure? An upgrade from what to what is behaving like this? What's happening in the above case is that the libtool install mode runs ldconfig -n for that directory, and ldconfig updates the symlinks to point to the latest version available as appropriate, where it presumes that 0.9.5-old is a greater version than 0.9.5. joe
