You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Christie <dc...@sover.net> on 2004/11/12 09:02:26 UTC

Re: Win32 project building

I have had difficulties building APR 1.0.0 on Win32. I am trying to
build in the Visual Studio IDE rather than from the command line. (I have 
done this successfully before with previous releases of APR; I have 
installed awk.exe, etc.) But there seem to be some unresolved issues with 
the 1.0.0 build.

I have both Visual Studio 6.0 and Visual Studio .NET 2003 available, and 
have tried both, with similar results. Here is exactly what I got using 
Visual Studio 6.0.

I found that opening the apr-util-1.0.0/aprutil.dsw workspace and building 
as described in http://apr.apache.org/compiling_win32.html only works 
partially.

First, I had to rename the unzipped directories by removing the '-1.0.0' 
suffix before I could open the aprutil.dsw successfully.

Having done that, I tried building the static libraries, in Debug mode.

The following libraries built successfully in apr/LibD:

    apr-1.lib
    apr_app-1.lib
    apriconv-1.lib

but apr-util.lib did not; it encountered the following errors:

xlate.c
C:\ORG\apache\apr-util\xlate\xlate.c(181) : error C2198: 'apr_iconv_close' : 
too few actual parameters
C:\ORG\apache\apr-util\xlate\xlate.c(182) : error C2198: 'apr_iconv_open' : 
too few actual parameters
C:\ORG\apache\apr-util\xlate\xlate.c(182) : warning C4047: '=' : 'void *' 
differs in levels of indirection from 'int '
apr_xml.c
Generating Code...
Error executing cl.exe.

By excluding xlate.c from the build, and also the ldap_*.c files, I was able 
to get an apr-util.lib generated; there were lots of multiply defined 
warnings for symbols also defined in apr-1.lib.


Then I tried the dynamic libraries (project libaprutil). It failed 
immediately with:

--------------------Configuration: libapr - Win32 Debug-------------------
Creating apr.h from apr.hw
Creating Version Resource
Compiling resources...
C:\ORG\apache\apr\libapr.rc (3): error RC2127 : version WORDs separated by 
commas expected
C:\ORG\apache\apr\libapr.rc (3): error RC2167 : unrecognized VERSIONINFO 
field;  BEGIN or comma expected
Error executing rc.exe.

libaprutil-1.dll - 2 error(s), 0 warning(s)



Regards,

-David Christie


Re: Win32 project building

Posted by David Christie <dc...@sover.net>.
> "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> Which flavor of awk are you using?  We strongly recommend the
> one cited on the 'building_win32' page.  DJGPP and GNU awk were
> both flawed in 3.0.3-3.0.6.  You can try manually adjusting that
> file for valid version tags.
>
> Using some clever macros - we may eliminiate the dynamic creation
> of VERSIONINFO tags in the coming few weeks - It's already in the
> incubation/httpd/cli/trunk/mod_aspdotnet/ included version file
> to generate different flavors of the version token, since we need
> both comma and period delimited flavors.  I'll try backporting
> this change.  About your static build - it sounds somehow fatally
> flawed.  I will try to reproduce; note we use VC6 for our dev,
> test and release, usually.  I've used the VC6 built apr in 2003
> studio projects, but haven't tried building on 2003 studio in a while.

Thanks for your reply.

I am using the awk.exe from Brian Kernighan's site as recommended. It's the 
only awk.exe on my hard drive.

The results I showed were using MSVC++ 6.0, but I have also tried MSVC++ 
.NET 2003, and it produces the same errors: C compiler errors on "xlate.c" 
while building apr-util (in both static and dynamic libraries), and failure 
to generate the VERSIONINFO in the DLL builds.

Did I do the right thing in renaming the unzipped directories (removing the 
"-1.0.0" suffix)? That seemed necessary before the .dsw workspace would even 
open properly.

I haven't tried hacking the VERSIONINFO, because I'm happy with the static 
apr.lib for now; I don't need aprutil.lib or the DLLs quite yet.

I'm just trying to provide useful feedback to help you resolve problems with 
the distribution -- at present I'm not blocked.

Keep up the good work -- APR is very useful and is making my project a lot 
easier. I'm using it from C++, and have wrapped what I use inside my own C++ 
classes, but I appreciate APR's low-level C architecture -- in fact I chose 
it over many alternative portability layers because I think you guys got the 
design choices right. (At Netscape we used NSPR, which all in all I'm glad 
you didn't perpetuate.)

Currently I am trying to rewrite the std C++ operator new and operator 
delete to use APR memory pools -- with per-thread selection of the current 
pool -- so 'new' will "just work" with a pool per thread. The idea is to 
supply the pool argument as thread context somehow, rather than explicitly. 
It's kind of challenging to figure out how to do this efficiently enough, 
given the high frequency of 'new' and the costs of threadkey access. It's an 
interesting design problem and quite important for multithreaded C++ 
programs, although it doesn't matter if C is your language.

One other thing I miss is a bit more documentation on APR -- beyond the 
autogenerated API descriptions. Is anyone working on a book? Or just a few 
more HTML files? It's a bit hard to determine the semantics and usage of 
some of the APIs. To someone who wasn't part of the developer community that 
wrote APR, puzzling out exactly what each API is for, and how you use it, 
from such minimalist doc as a list of function calls and their parameters is 
challenging, even if you are familiar with the underlying platform-specific 
APIs they are obviously based on.

As a doc substitute, I find greping this mailing list doesn't seem to help 
as much as I hoped it would, e.g. when I can't tell what the difference is 
between apr_threadkey_data_get() and apr_threadkey_private_get() from the 
doxygen pages. I usually end up having the read the .c source, which is 
educational, I suppose, but it slows me down.

Compared to more mature libraries (Berkeley DB comes to mind, because I use 
that also) the APR doc is, well, still almost absent. Good or bad API doc is 
a large part of why libraries get used successfully or don't, IMHO.  I 
realize this is just a matter of time.

BTW I'd be happy to review / help edit any in-progress API documents that 
anyone might be working on.



Re: Win32 project building

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 02:02 AM 11/12/2004, David Christie wrote:
>Then I tried the dynamic libraries (project libaprutil). It failed immediately with:
>
>--------------------Configuration: libapr - Win32 Debug-------------------
>Creating apr.h from apr.hw
>Creating Version Resource
>Compiling resources...
>C:\ORG\apache\apr\libapr.rc (3): error RC2127 : version WORDs separated by commas expected
>C:\ORG\apache\apr\libapr.rc (3): error RC2167 : unrecognized VERSIONINFO field;  BEGIN or comma expected
>Error executing rc.exe.

Which flavor of awk are you using?  We strongly recommend the
one cited on the 'building_win32' page.  DJGPP and GNU awk were
both flawed in 3.0.3-3.0.6.  You can try manually adjusting that
file for valid version tags.

Using some clever macros - we may eliminiate the dynamic creation
of VERSIONINFO tags in the coming few weeks - It's already in the
incubation/httpd/cli/trunk/mod_aspdotnet/ included version file
to generate different flavors of the version token, since we need
both comma and period delimited flavors.  I'll try backporting
this change.  About your static build - it sounds somehow fatally
flawed.  I will try to reproduce; note we use VC6 for our dev,
test and release, usually.  I've used the VC6 built apr in 2003
studio projects, but haven't tried building on 2003 studio in a while.

Bill