You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by SteveKing <st...@gmx.ch> on 2004/07/21 17:28:33 UTC
Problems building 1.1.x on win
Hi,
Yesterday I switched the Subversion source tree to the 1.1.x branch and
tried to build it. But every time I get a linker error in the libaprutil
project:
libaprutil error LNK2019: unresolved external symbol _db_create
referenced in function _vt_db_open
libaprutil error LNK2019: unresolved external symbol _db_strerror
referenced in function _set_error
libaprutil fatal error LNK1120: 2 unresolved externals
I followed the instructions in INSTALL. But whatever I do I can't get it
to compile.
My "configure" line to generate the project files looks like this:
python gen-make.py -t vcproj --with-openssl=..\Common\openssl
--with-zlib=..\Common\zlib --with-apr=apr --with-apr-util=apr-util
--with-apr-iconv=apr-iconv --enable-nls
First I thought that maybe the apr(-iconv/-util) folders were the
reason, so I got a fresh tarball of the 2.0.50 httpd. Didn't work either.
Next step was to recompile the berkeley db, but this didn't help either.
Any hints what could be (what I'm doing) wrong?
I'm using VS.NET2003 on XP.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Branko Čibej wrote:
> D.J. Heap wrote:
>
>> Any suggestions on what to do about vcproj files for apr?
>
>
> Sigh. Sorry, no. Well, APR 1.x has a generator, I believe (don't know if
> it's operational). For the 0.9.x series, we'll just have to keep our
> versions up-to-date. We might convert them to templates and parametrize
> the location of BDB, for example.
Ok, thanks -- the generator in 1.x is good to know. It doesn't seem
like an endless maintenance problem for Subversion with that knowledge.
I'll get to this as soon as I can, if no one beats me to it.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by Branko Čibej <br...@xbc.nu>.
D.J. Heap wrote:
> Any suggestions on what to do about vcproj files for apr?
Sigh. Sorry, no. Well, APR 1.x has a generator, I believe (don't know if
it's operational). For the 0.9.x series, we'll just have to keep our
versions up-to-date. We might convert them to templates and parametrize
the location of BDB, for example.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, July 22, 2004 6:59 PM -0600 "D.J. Heap" <dj...@shadyvale.net>
wrote:
> Any suggestions on what to do about vcproj files for apr?
Uh, aren't vcproj's generated for APR 1.0 now? Or, did we never get around to
porting the vcproj generating code from Subversion? *shrug* -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Branko Čibej wrote:
> D.J. Heap wrote:
[snip]
>>
>> I guess we could add a sub-option for '-t vcproj' that is the name of
>> the template to use or something and then just make a template for
>> each version of the IDE and leave the rest of the generator alone.
>> The vcproj files seem to be only slightly changed across IDE versions,
>> so templates may be able to account for the differences in IDE
>> versions without having to change generator code. That is certainly
>> true for 2002/2003, but I'm not sure about 2005 -- it is not
>> completely happy with our 2002 vcproj files, but I haven't looked
>> deeply into why.
>
>
> That's quite acceptable, I'd say. You use different templates when the
> format changes radically, but for the version number, you just use a
> parameter within the existing template. Shouldn't be that much of a
> problem.
Any suggestions on what to do about vcproj files for apr?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by Branko Čibej <br...@xbc.nu>.
D.J. Heap wrote:
> Steve Williams wrote:
> [snip]
>
>>
>> Agreed. It should build a valid vcproj file.
>>
>> Sly
>
>
> But which version? 2002, 2003, 2005, and on and on...I'd rather not
> have to go add a new option to the generator every time a new IDE
> comes out. And then when the generator is tweaked or changed, who is
> going to install 4 versions of the IDE and test the 4 versions of
> dsp/vcproj files it can generate? It's getting ridiculous because MS
> doesn't have a decent project file format.
>
> I guess we could add a sub-option for '-t vcproj' that is the name of
> the template to use or something and then just make a template for
> each version of the IDE and leave the rest of the generator alone.
> The vcproj files seem to be only slightly changed across IDE versions,
> so templates may be able to account for the differences in IDE
> versions without having to change generator code. That is certainly
> true for 2002/2003, but I'm not sure about 2005 -- it is not
> completely happy with our 2002 vcproj files, but I haven't looked
> deeply into why.
That's quite acceptable, I'd say. You use different templates when the
format changes radically, but for the version number, you just use a
parameter within the existing template. Shouldn't be that much of a problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by "D.J. Heap" <dj...@shadyvale.net>.
D.J. Heap wrote:
> Steve Williams wrote:
> [snip]
>
>>
>> Agreed. It should build a valid vcproj file.
>>
>> Sly
>
>
> But which version? 2002, 2003, 2005, and on and on...I'd rather not
> have to go add a new option to the generator every time a new IDE comes
> out. And then when the generator is tweaked or changed, who is going to
> install 4 versions of the IDE and test the 4 versions of dsp/vcproj
> files it can generate? It's getting ridiculous because MS doesn't have
> a decent project file format.
>
> I guess we could add a sub-option for '-t vcproj' that is the name of
> the template to use or something and then just make a template for each
> version of the IDE and leave the rest of the generator alone. The
> vcproj files seem to be only slightly changed across IDE versions, so
> templates may be able to account for the differences in IDE versions
> without having to change generator code. That is certainly true for
> 2002/2003, but I'm not sure about 2005 -- it is not completely happy
> with our 2002 vcproj files, but I haven't looked deeply into why.
>
> DJ
>
>
Even if we do this, though, we still have the Apache/apr problem -- they
don't ship vcproj files and so we'd have to supply pre-converted ones
for every IDE version and every Apache version (at least where they get
changed). Bleh.
Does anyone know what Apache plans to do here if anything? Supply
vcprojs or generate them or are they happy with dsp's?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by "D.J. Heap" <dj...@shadyvale.net>.
Steve Williams wrote:
[snip]
>
> Agreed. It should build a valid vcproj file.
>
> Sly
But which version? 2002, 2003, 2005, and on and on...I'd rather not
have to go add a new option to the generator every time a new IDE comes
out. And then when the generator is tweaked or changed, who is going to
install 4 versions of the IDE and test the 4 versions of dsp/vcproj
files it can generate? It's getting ridiculous because MS doesn't have
a decent project file format.
I guess we could add a sub-option for '-t vcproj' that is the name of
the template to use or something and then just make a template for each
version of the IDE and leave the rest of the generator alone. The
vcproj files seem to be only slightly changed across IDE versions, so
templates may be able to account for the differences in IDE versions
without having to change generator code. That is certainly true for
2002/2003, but I'm not sure about 2005 -- it is not completely happy
with our 2002 vcproj files, but I haven't looked deeply into why.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by Steve Williams <st...@kromestudios.com>.
> solution/project files first have to be converted. And converting from the
> command line is not possible (believe me: I searched all docs, googled for
> two days).
There is this batch file supplied in the Visual Studio help and on the MS
website...
// when running this at the command line,
// call it with CScript so you don't get UI.
// example: CScript convert.js e:\yourprojects\old.dsp
e:\yourprojects\new.vcproj
// NOTE: full path required to both input and output files
// or set default script engine to the command line doing this first
// example: CScript //H:CScript
// Once you set the environment, run the .js file like a .bat file
// To have a batch file loop through all the .dsp files
// in a directory, write a batch file that looked like this
// (Windows NT 4 or Windows 2000 only)
// CScript //H:CScript //Nologo
// for /R %%i in (*.dsp) do convert.js %%i >> .\Convert.log
var vcProj = new ActiveXObject("VisualStudio.VCProjectEngine.7.1");
var objFile = new ActiveXObject("Scripting.FileSystemObject");
var objArgs = WScript.Arguments;
// check the arguments to be sure it's right
if (objArgs.Count() < 2)
{
WScript.Echo("VC6 or 5 DSP Project File Conversion");
WScript.Echo("Opens specified .dsp and converts to VC7.1 Format.");
WScript.Echo("Will create project file with .vcproj extension");
WScript.Echo("\n\tusage: <full path\project.dsp> <full
path\project.vcproj>");
WScript.Quit(1);
}
WScript.Echo("\nConverting: "+ objArgs.Item(0));
// If there is a file name of the .vcproj extension, do not convert
var vcProject = vcProj.LoadProject(objArgs.Item(0));
if (!objFile.FileExists(vcProject.ProjectFile))
{
// specify name and location of new project file
vcProject.ProjectFile = objArgs.Item(1);
// call the project engine to save this off.
// when no name is shown, it will create one with the .vcproj name
vcProject.Save();
WScript.Echo("New Project Name: "+vcProject.ProjectFile+"\n");
}
else
{
WScript.Echo("ERROR!: "+vcProject.ProjectFile+" already exists!\n");
}
...but that's overkill for a problem that should be fixed in the first
place.
> > I think we may be better off redoing how our version resource
> > definitions are handled so that we can ditch the vcproj support entirely
> > and just let VS convert dsp's (even Whidbey converts dsps) -- the
> > resource definitions are the only reason VSNet screws up when it
> > converts Subversion dsp files.
>
> Oh no! Please don't. If you do that, then I can forget having a build
script
> for TSVN because I then _must_ build Subversion "manually" first, i.e. not
> from the command line.
Agreed. It should build a valid vcproj file.
Sly
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by "D.J. Heap" <dj...@shadyvale.net>.
SteveKing wrote:
>>The root of the problem is that Apache doesn't ship vcproj files, only
>>dsp's. So, we have some 'pre-converted' vcproj files that we just copy
>>over to the apr directories and tell the solution to use those. Icky.
>
>
> I know that. But this worked (still does) on the 1.0.x branch. There the
> library get's added to the projects link dependencies by the script.
I believe that is because Apache (aprutil) never tried to link in BDB
before, but I'm not sure until I take a closer look. Did you run the
w32locatedb.pl script that tweaks Apache to look for BDB?
>
>
>>I'm not sure exactly what is wrong (Apache seems to want BDB now when it
>>never did before), but if you build Apache first it should work since
>>the projects will be up to date and it won't bother building using our
>>project files.
>
>
> Building Apache first means using the *.dsp files and convert them first.
> That will work, yes. But so does the "-t dsp" part of the script.
>
The currently generated dsp's (Apache's work fine) actually will not get
converted correctly -- VSNet's converter doesn't handle the resource
compiler's quoting rules correctly and so the exe's with resources fail
to build. At least that is what happened the last time I tried them
which was a while ago.
>
>>I use VSNet2003 and I don't see this problem -- it converts the
>>VSNet2002 project and solutions fine. The problem with adding another
>
>
> It does this _only_ if you start the IDE and load the solution file.
> But if you try to do this:
> devenv subversion_vcnet.sln /useenv /build release /project "__ALL__"
> it doesn't work because it stops with an error message that the
> solution/project files first have to be converted. And converting from the
> command line is not possible (believe me: I searched all docs, googled for
> two days).
> But that's not a real problem. As I said I can work around that by tweaking
> that version number in the solution file myself.
Right, if you don't tweak the template manually you have to invoke the
IDE to convert it -- I agree it's annoying and makes automated scripts
for building more difficult.
>
>
>>I think we may be better off redoing how our version resource
>>definitions are handled so that we can ditch the vcproj support entirely
>>and just let VS convert dsp's (even Whidbey converts dsps) -- the
>>resource definitions are the only reason VSNet screws up when it
>>converts Subversion dsp files.
>
>
> Oh no! Please don't. If you do that, then I can forget having a build script
> for TSVN because I then _must_ build Subversion "manually" first, i.e. not
> from the command line.
>
>
> I found another "bug" in the "-t vcproj" build:
> if you do a /rebuild instead of just a /build, then the
> /build/win32/build_neon.bat file get's deleted before the actual build
> (seems the "temp" pattern specified includes *.bat). That means that a
> /rebuild is not possible at all. Only normal builds work.
>
>
Hmm, that is probably true of the dsp projects too, then.
If anyone has ideas on how to handle the various project/solution file
format problem gracefully, feel free to chime in...It just seems like an
eternal maintenance problem to try and keep up with every new format
that comes with every new version of the IDE -- the version number
changes are not the only differences, although just tweaking that does
seem to work.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by SteveKing <st...@gmx.ch>.
> The root of the problem is that Apache doesn't ship vcproj files, only
> dsp's. So, we have some 'pre-converted' vcproj files that we just copy
> over to the apr directories and tell the solution to use those. Icky.
I know that. But this worked (still does) on the 1.0.x branch. There the
library get's added to the projects link dependencies by the script.
> I'm not sure exactly what is wrong (Apache seems to want BDB now when it
> never did before), but if you build Apache first it should work since
> the projects will be up to date and it won't bother building using our
> project files.
Building Apache first means using the *.dsp files and convert them first.
That will work, yes. But so does the "-t dsp" part of the script.
> I use VSNet2003 and I don't see this problem -- it converts the
> VSNet2002 project and solutions fine. The problem with adding another
It does this _only_ if you start the IDE and load the solution file.
But if you try to do this:
devenv subversion_vcnet.sln /useenv /build release /project "__ALL__"
it doesn't work because it stops with an error message that the
solution/project files first have to be converted. And converting from the
command line is not possible (believe me: I searched all docs, googled for
two days).
But that's not a real problem. As I said I can work around that by tweaking
that version number in the solution file myself.
> I think we may be better off redoing how our version resource
> definitions are handled so that we can ditch the vcproj support entirely
> and just let VS convert dsp's (even Whidbey converts dsps) -- the
> resource definitions are the only reason VSNet screws up when it
> converts Subversion dsp files.
Oh no! Please don't. If you do that, then I can forget having a build script
for TSVN because I then _must_ build Subversion "manually" first, i.e. not
from the command line.
I found another "bug" in the "-t vcproj" build:
if you do a /rebuild instead of just a /build, then the
/build/win32/build_neon.bat file get's deleted before the actual build
(seems the "temp" pattern specified includes *.bat). That means that a
/rebuild is not possible at all. Only normal builds work.
Stefan
--
+++ GMX DSL-Tarife 3 Monate gratis* +++ Nur bis 25.7.2004 +++
Bis 24.000 MB oder 300 Freistunden inkl. http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by Russell Yanofsky <re...@columbia.edu>.
D.J. Heap wrote:
> I'm not sure exactly what is wrong (Apache seems to want BDB now when
> it never did before), but if you build Apache first it should work
> since the projects will be up to date and it won't bother building
> using our project files.
Apache wants bdb now because the w32locatedb.pl script modifies apr-util
headers to #define APU_USE_DB and APU_HAVE_DB and to #include db.h.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by Branko Čibej <br...@xbc.nu>.
D.J. Heap wrote:
> I think we may be better off redoing how our version resource
> definitions are handled so that we can ditch the vcproj support
> entirely and just let VS convert dsp's (even Whidbey converts dsps) --
> the resource definitions are the only reason VSNet screws up when it
> converts Subversion dsp files.
Don't.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by "D.J. Heap" <dj...@shadyvale.net>.
SteveKing wrote:
> Ben Collins-Sussman wrote:
>
> [snip]
>
>> Perhaps you should rebuild apache first?
>
>
> I usually don't build mod_dav_svn, so building apache is not necessary.
>
>> Is "-t vcproj" for VS.NET? I was using "-t dsp" for VC6. Maybe your
>> problem is unique to VS.NET.
>
>
> Yes. That's the problem. I tried the "-t dsp" switch and then converted
> the project files with VS.NET - there the library is added and I can
> compile.
>
> So the "-t vcproj" build is definitely broken!
> Can someone who knows perl please fix that? I really need to compile
> Subversion or I can't work on TSVN anymore :(
The root of the problem is that Apache doesn't ship vcproj files, only
dsp's. So, we have some 'pre-converted' vcproj files that we just copy
over to the apr directories and tell the solution to use those. Icky.
I think the idea was that eventually Apache would ship vcproj's or use a
generator or something, but that hasn't happened yet.
I'm not sure exactly what is wrong (Apache seems to want BDB now when it
never did before), but if you build Apache first it should work since
the projects will be up to date and it won't bother building using our
project files.
I'll look into it deeper when I can, but it is building for me as long
as I build Apache first.
>
> And if we're on the subject (the gen-make.py script):
> To compile Subversion with VS.NET2003 from the command line (or from
> within a build script) the .sln file doesn't work. The reason for that
> is that the generated .sln file contains the following line on top:
> Microsoft Visual Studio Solution File, Format Version 7.00
> but VS.NET2003 needs the line to be
> Microsoft Visual Studio Solution File, Format Version 8.00
>
> For the TSVN build script I "fixed" that by overwriting the file
> vcnet_sln.ezt in the Subversion build folder with a version which has
> the correct line in it. But it would be great if the gen-make.py script
> had another option "-t vcproj2003" which did that automatically.
I use VSNet2003 and I don't see this problem -- it converts the
VSNet2002 project and solutions fine. The problem with adding another
option for a new project file format is that it will never end. MS
already has 3 formats and VS.Next (Whidbey) introduces yet another. Yay.
I think we may be better off redoing how our version resource
definitions are handled so that we can ditch the vcproj support entirely
and just let VS convert dsp's (even Whidbey converts dsps) -- the
resource definitions are the only reason VSNet screws up when it
converts Subversion dsp files.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by SteveKing <st...@gmx.ch>.
Ben Collins-Sussman wrote:
[snip]
> Perhaps you should rebuild apache first?
I usually don't build mod_dav_svn, so building apache is not necessary.
> Is "-t vcproj" for VS.NET? I was using "-t dsp" for VC6. Maybe your
> problem is unique to VS.NET.
Yes. That's the problem. I tried the "-t dsp" switch and then converted
the project files with VS.NET - there the library is added and I can
compile.
So the "-t vcproj" build is definitely broken!
Can someone who knows perl please fix that? I really need to compile
Subversion or I can't work on TSVN anymore :(
And if we're on the subject (the gen-make.py script):
To compile Subversion with VS.NET2003 from the command line (or from
within a build script) the .sln file doesn't work. The reason for that
is that the generated .sln file contains the following line on top:
Microsoft Visual Studio Solution File, Format Version 7.00
but VS.NET2003 needs the line to be
Microsoft Visual Studio Solution File, Format Version 8.00
For the TSVN build script I "fixed" that by overwriting the file
vcnet_sln.ezt in the Subversion build folder with a version which has
the correct line in it. But it would be great if the gen-make.py script
had another option "-t vcproj2003" which did that automatically.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-07-21 at 12:28, SteveKing wrote:
> Hi,
>
> Yesterday I switched the Subversion source tree to the 1.1.x branch and
> tried to build it. But every time I get a linker error in the libaprutil
> project:
I've not tried the 1.1.x branch, but the 1.1rc1 tarball built on win32
for me without any problems. I built apache from the commandline, then
built svn after that.
>
> libaprutil error LNK2019: unresolved external symbol _db_create
> referenced in function _vt_db_open
> libaprutil error LNK2019: unresolved external symbol _db_strerror
> referenced in function _set_error
> libaprutil fatal error LNK1120: 2 unresolved externals
Perhaps you should rebuild apache first?
>
> I followed the instructions in INSTALL. But whatever I do I can't get it
> to compile.
>
> My "configure" line to generate the project files looks like this:
> python gen-make.py -t vcproj --with-openssl=..\Common\openssl
> --with-zlib=..\Common\zlib --with-apr=apr --with-apr-util=apr-util
> --with-apr-iconv=apr-iconv --enable-nls
Is "-t vcproj" for VS.NET? I was using "-t dsp" for VC6. Maybe your
problem is unique to VS.NET.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Problems building 1.1.x on win
Posted by Stefan <st...@tigris.org>.
SteveKing wrote:
> Yesterday I switched the Subversion source tree to the 1.1.x branch and
> tried to build it. But every time I get a linker error in the libaprutil
> project:
>
> libaprutil error LNK2019: unresolved external symbol _db_create
> referenced in function _vt_db_open
> libaprutil error LNK2019: unresolved external symbol _db_strerror
> referenced in function _set_error
> libaprutil fatal error LNK1120: 2 unresolved externals
Replying to myself:
If I manually add the library ..\db4-win32\lib\libdb42.lib to the
libaprutil project it works. But AFAIK the build script for the 1.0.x
branch did that automatically? I really don't want to add that line
manually every time I do a rebuild...
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org