libketama/apr
Paul (pquerna), Did I see a commit flash past from you working on that a while ago ? Or is my memory way off ? As I am about to do some work here* - and am wondering if this should be done properly or as a one off hack. (libketama has some funny exit codes, etc - so it takes a bit of wrapping), Thanks, Dw *: mod_cache, a generic robust/consistent hash and ultimately some spread-like invalidation pub/sub mechanism.
Re: Newbie question: Compiling helloworld-APR.c under Windows
Hello William, thank you for your quick reply last week. Unfortunately I still cannot get helloworld-APR.c running under Windows. William A. Rowe, Jr. wrote: If you used a -win32-src.zip file, and run nmake against the makefile.win, you shouldn't be having problems. I'm not quite sure to understand what you mean by this. Yes, I have downloaded the win32-src.zip file and followed the instructions in the section Developer Studio Workspace/Microsoft Development Environment IDE Build on http://apr.apache.org/compiling_win32.html to build the libs. I have also successfully built and run the apr/test/aprtest.dsw project. If you import into VS2005/2008, there are dependency hassles, but you can usually work those out by reviewing the build target and it's dependencies. APR alone is pretty easy. Sorry, I do not understand what you say here. It might well be that I just know too little about Windows programming in general. (I come from a UNIX background.) Finally, apr.h defines those APR_DECLARE macros to be .dll imports if you do nothing. You do need to declare -D WIN32 of course. I have found out by myself that I have to declare this WIN32 macro by following the compiler's error messages into the apr.h file. You say of course: Is this something I should have known beforehand because it is customary in Windows development? If not so: I cannot read anything about this in the official documentation!? Anyway, now my helloworld compiles, but it does not link. I get the following error messages: -- Build started: Project: TestAPR, Configuration: Debug Win32 -- Linking... try-helloworld-APR.obj : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification apr-1.lib(start.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function [EMAIL PROTECTED] apr-1.lib(start.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function [EMAIL PROTECTED] apr-1.lib(apr_snprintf.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _conv_in_addr apr-1.lib(sockaddr.obj) : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr-1.lib(sockaddr.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _apr_sockaddr_vars_set apr-1.lib(sockaddr.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _get_local_addr apr-1.lib(sockaddr.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _get_local_addr [...] Can someone please help me? Thank you very much, Joachim
Re: Newbie question: Compiling helloworld-APR.c under Windows
Joachim Ziegler wrote: I'm not quite sure to understand what you mean by this. Yes, I have downloaded the win32-src.zip file and followed the instructions in the section Developer Studio Workspace/Microsoft Development Environment IDE Build on http://apr.apache.org/compiling_win32.html to build the libs. Sounds great - give me a day or two to freshen that document, and I'll post when it's good to follow. I'll be sure to add something about consuming libapr on win32 as well. Bill
Re: Newbie question: Compiling helloworld-APR.c under Windows
Sounds like the liker wants Winsock linked in (ws2_32.lib). Not sure why your application wants it, as it should have been linked into apr-1.dll already - maybe someone else can chime in. Issac Joachim Ziegler wrote: Hello William, thank you for your quick reply last week. Unfortunately I still cannot get helloworld-APR.c running under Windows. William A. Rowe, Jr. wrote: If you used a -win32-src.zip file, and run nmake against the makefile.win, you shouldn't be having problems. I'm not quite sure to understand what you mean by this. Yes, I have downloaded the win32-src.zip file and followed the instructions in the section Developer Studio Workspace/Microsoft Development Environment IDE Build on http://apr.apache.org/compiling_win32.html to build the libs. I have also successfully built and run the apr/test/aprtest.dsw project. If you import into VS2005/2008, there are dependency hassles, but you can usually work those out by reviewing the build target and it's dependencies. APR alone is pretty easy. Sorry, I do not understand what you say here. It might well be that I just know too little about Windows programming in general. (I come from a UNIX background.) Finally, apr.h defines those APR_DECLARE macros to be .dll imports if you do nothing. You do need to declare -D WIN32 of course. I have found out by myself that I have to declare this WIN32 macro by following the compiler's error messages into the apr.h file. You say of course: Is this something I should have known beforehand because it is customary in Windows development? If not so: I cannot read anything about this in the official documentation!? Anyway, now my helloworld compiles, but it does not link. I get the following error messages: -- Build started: Project: TestAPR, Configuration: Debug Win32 -- Linking... try-helloworld-APR.obj : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/OPT:ICF' specification apr-1.lib(start.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function [EMAIL PROTECTED] apr-1.lib(start.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function [EMAIL PROTECTED] apr-1.lib(apr_snprintf.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _conv_in_addr apr-1.lib(sockaddr.obj) : error LNK2001: unresolved external symbol [EMAIL PROTECTED] apr-1.lib(sockaddr.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _apr_sockaddr_vars_set apr-1.lib(sockaddr.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _get_local_addr apr-1.lib(sockaddr.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function _get_local_addr [...] Can someone please help me? Thank you very much, Joachim
Re: Newbie question: Compiling helloworld-APR.c under Windows
Issac Goldstand wrote: Sounds like the liker wants Winsock linked in (ws2_32.lib). Not sure why your application wants it, as it should have been linked into apr-1.dll already - maybe someone else can chime in. You must mean libapr-1.lib/libapr-1.dll, yes, it is. But no, it's not linked to apr-1.lib (static). I'm contemplating some trickery which would ensure that the user doesn't have to call out dependent libs, but not till apr 1.3.0
Re: Newbie question: Compiling helloworld-APR.c under Windows
William A. Rowe, Jr. wrote: Issac Goldstand wrote: Sounds like the liker wants Winsock linked in (ws2_32.lib). Not sure why your application wants it, as it should have been linked into apr-1.dll already - maybe someone else can chime in. You must mean libapr-1.lib/libapr-1.dll, yes, it is. But no, it's not linked to apr-1.lib (static). Good point - I missed that. Now the original email makes more sense.
Re: [patch] creating directories with long names
Anyone looked at this yet?
http://mail-archives.apache.org/mod_mbox/apr-dev/200801.mbox/[EMAIL PROTECTED]
Stefan
Stefan Küng wrote:
Hi,
While debugging problems with Subversion on Windows (checkouts failed if
some paths had longer names than around 250 chars), I found a bug in apr:
apr transparently converts long pathnames to the Windows specific format
for long names (it prepends '\\?\'). But that only works properly for
files, because only filenames can be up to MAX_PATH chars long before
the other format is needed. Directories can only be 248 chars long
before the long format is required (see MSDN docs for CreateDirectory:
http://msdn2.microsoft.com/en-us/library/aa363855(VS.85).aspx).
Since the function utf8_to_unicode_path() does the converting for both
file and dir paths, it has to use the long format for 248 length strings
on, not MAX_PATH. Otherwise, directory creation fails (at least for
paths between 248 chars and 260 chars in length).
The attached patch fixes this problem.
Stefan
Index: file_io/win32/open.c
===
--- file_io/win32/open.c(revision 613400)
+++ file_io/win32/open.c(working copy)
@@ -55,7 +55,7 @@
apr_status_t rv;
/* This is correct, we don't twist the filename if it is will
- * definately be shorter than MAX_PATH. It merits some
+ * definately be shorter than 248. It merits some
* performance testing to see if this has any effect, but there
* seem to be applications that get confused by the resulting
* Unicode \\?\ style file names, especially if they use argv[0]
@@ -65,7 +65,7 @@
* Note that a utf-8 name can never result in more wide chars
* than the original number of utf-8 narrow chars.
*/
-if (srcremains MAX_PATH) {
+if (srcremains 248) {
if (srcstr[1] == ':' (srcstr[2] == '/' || srcstr[2] == '\\')) {
wcscpy (retstr, L?\\);
retlen -= 4;
--
___
oo // \\ De Chelonian Mobile
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
signature.asc
Description: OpenPGP digital signature
Re: [patch] creating directories with long names
Stefan Küng wrote: Anyone looked at this yet? http://mail-archives.apache.org/mod_mbox/apr-dev/200801.mbox/[EMAIL PROTECTED] The patch/argument made perfect sense, although I'm leaning towards a switch to decide if it's a file or path name (if it is even possible for that to work). I'll review and commit.
