On 3/10/06, Kevin Aubuchon <firstname.lastname@example.org> wrote:
> My source code dir structure is like the following (I'm only showing a few
> sub dirs).
db4-win32 needs to be on the same level as the INSTALL file (which is
the same level as apr* in the default zip file). You don't need the
--with-apr* options to gen-make.py unless you've moved them out of
their default locations, although it shouldn't hurt anything.
> >>>What apr/apr-util/apr-iconv are you using?
> The source that came with the zip file.
> Neon version is 0.25
> Neon won't compile as a project in the solution, so I use it's .mak file.
I tried to replicate your environment (mostly -- I didn't use any
libintl options) and did hit the known issue with the 1.3.0 zip file
neon 0.25.x won't build due to a Win32-only bug in apr-util -- the
version macros for expat are not expanded correctly by the
apr-util/xml build process. You can use neon 0.24.7...or to fix it
for neon 0.25.x and the apr-util that comes with the zip file you can
change the version defines at the bottom of
#define XML_MAJOR_VERSION 1
#define XML_MINOR_VERSION 95
#define XML_MICRO_VERSION 2
Another issue specifically with VS2005 (fixed on trunk) is that neon
doesn't get automatically linked because MS changed how VS handles
makefile projects in VS2005 -- you'll need to add the full path to the
neon library to the linker input settings (ie, for a Release build add
full-path\neon\libneon.lib to Linker -> Input -> Additional
Dependencies). You need to do this for any client .exe's you are
building (such as svn and svnversion projects).
After these tweaks, all the main projects (__ALL__) built for me.
If you still can't build after making these changes (move db4-win32 up
a level if needed, tweak expat.h.in or use neon 0.24.7, and add neon
to linker inputs) then can you post a few of the errors you are
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Mar 11 14:30:30 2006