You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Lieven Govaerts <lg...@mobsol.be> on 2006/12/31 09:35:35 UTC
Re: svn trunk r22841: FAIL (win32-xp VS2005)
It looks like the new DLL code doesn't pass the Windows buildslave. Any
idea what goes wrong? Seems to be JavaHL related.
Lieven
buildbot@mobsol.be wrote:
> Full details are available at:
> http://www.mobsol.be/buildbot/win32-xp%2520VS2005/builds/912
>
> Author list: brane
>
> Build Slave: djh-xp-vse2005
>
>
> Subversion Buildbot
> http://www.mobsol.be/buildbot/
>
>
> Last 100 lines of the build log (step: Build ):
>
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_fs_base_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_fs_base_vcnet.tmp_Release_Win32.vcproj".
> Target libsvn_fs_fs:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_fs_fs_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_fs_fs_vcnet.tmp_Release_Win32.vcproj".
> Target svn_fs:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_fs_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_fs_vcnet.tmp_Release_Win32.vcproj".
> Target libsvn_fs:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_fs_dll_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_fs_dll_vcnet.tmp_Release_Win32.vcproj".
> Target libsvn_ra_dav:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_ra_dav_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_ra_dav_vcnet.tmp_Release_Win32.vcproj".
> Target libsvn_ra_local:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_ra_local_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_ra_local_vcnet.tmp_Release_Win32.vcproj".
> Target libsvn_ra_svn:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_ra_svn_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_ra_svn_vcnet.tmp_Release_Win32.vcproj".
> Target svn_repos:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_repos_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_repos_vcnet.tmp_Release_Win32.vcproj".
> Target libsvn_repos:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_repos_dll_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_repos_dll_vcnet.tmp_Release_Win32.vcproj".
> Target neon:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\..\neon\neon.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\..\neon\neon.tmp_Release_Win32.vcproj".
> Target svn_ra:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_ra_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_ra_vcnet.tmp_Release_Win32.vcproj".
> Target libsvn_ra:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_ra_dll_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_ra_dll_vcnet.tmp_Release_Win32.vcproj".
> Target svn_wc:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_wc_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_wc_vcnet.tmp_Release_Win32.vcproj".
> Target libsvn_wc:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_wc_dll_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_wc_dll_vcnet.tmp_Release_Win32.vcproj".
> Target svn_client:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_client_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_client_vcnet.tmp_Release_Win32.vcproj".
> Target libsvn_client:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_client_dll_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> Deleting file "C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvn_client_dll_vcnet.tmp_Release_Win32.vcproj".
> Target libsvnjavahl:
> C:\VCX2005\Common7\IDE\..\..\vc\vcpackages\vcbuild.exe C:\svn-builder\djh-xp-vse2005\build\build\win32\vcnet-vcproj\libsvnjavahl_vcnet.tmp_Release_Win32.vcproj "Release|Win32"
> ..\..\..\subversion\bindings\java\javahl\native\org_tigris_subversion_javahl_SVNClient.cpp(347): warning C4244: 'argument' : conversion from 'jlong' to 'long', possible loss of data
> ..\..\..\subversion\bindings\java\javahl\native\org_tigris_subversion_javahl_SVNClient.cpp(1455): warning C4800: 'jboolean' : forcing value to bool 'true' or 'false' (performance warning)
> ..\..\..\subversion\bindings\java\javahl\native\org_tigris_subversion_javahl_SVNClient.cpp(1456): warning C4800: 'jboolean' : forcing value to bool 'true' or 'false' (performance warning)
> ..\..\..\subversion\bindings\java\javahl\native\org_tigris_subversion_javahl_SVNClient.cpp(1489): warning C4800: 'jboolean' : forcing value to bool 'true' or 'false' (performance warning)
> ..\..\..\subversion\bindings\java\javahl\native\org_tigris_subversion_javahl_SVNClient.cpp(1489): warning C4800: 'jboolean' : forcing value to bool 'true' or 'false' (performance warning)
> ..\..\..\subversion\bindings\java\javahl\native\SVNClient.cpp(2497): warning C4244: '=' : conversion from 'apr_off_t' to 'size_t', possible loss of data
> ..\..\..\subversion\bindings\java\javahl\native\Revision.cpp(103): warning C4244: '=' : conversion from 'jlong' to 'svn_revnum_t', possible loss of data
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_deltify_revision referenced in function "public: void __thiscall SVNAdmin::deltify(char const *,class Revision &,class Revision &)" (?deltify@SVNAdmin@@QAEXPBDAAVRevision@@1@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_youngest_rev referenced in function "public: void __thiscall SVNAdmin::deltify(char const *,class Revision &,class Revision &)" (?deltify@SVNAdmin@@QAEXPBDAAVRevision@@1@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_list_transactions referenced in function "public: void __thiscall SVNAdmin::lstxns(char const *,class MessageReceiver &)" (?lstxns@SVNAdmin@@QAEXPBDAAVMessageReceiver@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_purge_txn referenced in function "public: void __thiscall SVNAdmin::rmtxns(char const *,class Targets &)" (?rmtxns@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_abort_txn referenced in function "public: void __thiscall SVNAdmin::rmtxns(char const *,class Targets &)" (?rmtxns@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_open_txn referenced in function "public: void __thiscall SVNAdmin::rmtxns(char const *,class Targets &)" (?rmtxns@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_change_rev_prop referenced in function "public: void __thiscall SVNAdmin::setRevProp(char const *,class Revision &,char const *,char const *,bool,bool)" (?setRevProp@SVNAdmin@@QAEXPBDAAVRevision@@00_N2@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_unlock referenced in function "public: void __thiscall SVNAdmin::rmlocks(char const *,class Targets &)" (?rmlocks@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_get_lock referenced in function "public: void __thiscall SVNAdmin::rmlocks(char const *,class Targets &)" (?rmlocks@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_set_access referenced in function "public: void __thiscall SVNAdmin::rmlocks(char const *,class Targets &)" (?rmlocks@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_create_access referenced in function "public: void __thiscall SVNAdmin::rmlocks(char const *,class Targets &)" (?rmlocks@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> ..\..\..\Release\subversion\bindings\java\javahl\native\libsvnjavahl-1.dll : fatal error LNK1120: 11 unresolved externals
> Done building target "libsvnjavahl" in project "subversion_vcnet.sln" -- FAILED.
>
> Done building project "subversion_vcnet.sln" -- FAILED.
>
> Build FAILED.
> .\..\..\subversion\bindings\java\javahl\native\org_tigris_subversion_javahl_SVNClient.cpp(347): warning C4244: 'argument' : conversion from 'jlong' to 'long', possible loss of data
> .\..\..\subversion\bindings\java\javahl\native\org_tigris_subversion_javahl_SVNClient.cpp(1455): warning C4800: 'jboolean' : forcing value to bool 'true' or 'false' (performance warning)
> .\..\..\subversion\bindings\java\javahl\native\org_tigris_subversion_javahl_SVNClient.cpp(1456): warning C4800: 'jboolean' : forcing value to bool 'true' or 'false' (performance warning)
> .\..\..\subversion\bindings\java\javahl\native\org_tigris_subversion_javahl_SVNClient.cpp(1489): warning C4800: 'jboolean' : forcing value to bool 'true' or 'false' (performance warning)
> .\..\..\subversion\bindings\java\javahl\native\org_tigris_subversion_javahl_SVNClient.cpp(1489): warning C4800: 'jboolean' : forcing value to bool 'true' or 'false' (performance warning)
> .\..\..\subversion\bindings\java\javahl\native\SVNClient.cpp(2497): warning C4244: '=' : conversion from 'apr_off_t' to 'size_t', possible loss of data
> .\..\..\subversion\bindings\java\javahl\native\Revision.cpp(103): warning C4244: '=' : conversion from 'jlong' to 'svn_revnum_t', possible loss of data
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_deltify_revision referenced in function "public: void __thiscall SVNAdmin::deltify(char const *,class Revision &,class Revision &)" (?deltify@SVNAdmin@@QAEXPBDAAVRevision@@1@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_youngest_rev referenced in function "public: void __thiscall SVNAdmin::deltify(char const *,class Revision &,class Revision &)" (?deltify@SVNAdmin@@QAEXPBDAAVRevision@@1@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_list_transactions referenced in function "public: void __thiscall SVNAdmin::lstxns(char const *,class MessageReceiver &)" (?lstxns@SVNAdmin@@QAEXPBDAAVMessageReceiver@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_purge_txn referenced in function "public: void __thiscall SVNAdmin::rmtxns(char const *,class Targets &)" (?rmtxns@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_abort_txn referenced in function "public: void __thiscall SVNAdmin::rmtxns(char const *,class Targets &)" (?rmtxns@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_open_txn referenced in function "public: void __thiscall SVNAdmin::rmtxns(char const *,class Targets &)" (?rmtxns@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_change_rev_prop referenced in function "public: void __thiscall SVNAdmin::setRevProp(char const *,class Revision &,char const *,char const *,bool,bool)" (?setRevProp@SVNAdmin@@QAEXPBDAAVRevision@@00_N2@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_unlock referenced in function "public: void __thiscall SVNAdmin::rmlocks(char const *,class Targets &)" (?rmlocks@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_get_lock referenced in function "public: void __thiscall SVNAdmin::rmlocks(char const *,class Targets &)" (?rmlocks@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_set_access referenced in function "public: void __thiscall SVNAdmin::rmlocks(char const *,class Targets &)" (?rmlocks@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> SVNAdmin.obj : error LNK2019: unresolved external symbol _svn_fs_create_access referenced in function "public: void __thiscall SVNAdmin::rmlocks(char const *,class Targets &)" (?rmlocks@SVNAdmin@@QAEXPBDAAVTargets@@@Z)
> .\..\..\Release\subversion\bindings\java\javahl\native\libsvnjavahl-1.dll : fatal error LNK1120: 11 unresolved externals
> 7 Warning(s)
> 12 Error(s)
>
> Time Elapsed 00:01:13.57
>
> *** Whoops, something choked.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: svn-breakage-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: svn-breakage-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by "D.J. Heap" <dj...@gmail.com>.
On 1/5/07, Vlad Georgescu <vg...@gmail.com> wrote:
[snip]
>
> It looks like we're copying the modules to abs_objdir (the build tree)
> but trying to load them from abs_builddir (the test tree, not very
> intuitively named). In your case they're different. So, should we:
Yes, I run the tests on a ram drive.
>
> a) tell Apache to load its modules from abs_objdir
> b) copy the dlls and modules to abs_builddir
>
> ?
Either one would work, I think, and I don't have a strong opinion
either way. So whichever is easiest to implement, I'd say, unless
someone else sees an advantage to one or the other.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Ivan Zhakov <ch...@gmail.com>.
On 1/6/07, Vlad Georgescu <vg...@gmail.com> wrote:
> On 1/6/07, Ivan Zhakov <ch...@gmail.com> wrote:
> > > It looks like we're copying the modules to abs_objdir (the build tree)
> > > but trying to load them from abs_builddir (the test tree, not very
> > > intuitively named). In your case they're different. So, should we:
> > >
> > > a) tell Apache to load its modules from abs_objdir
> > > b) copy the dlls and modules to abs_builddir
> > >
> > I think copying dlls is better approach because I can run tests in
> > background and continue developing and compiling.
>
> I don't understand. We always copy dlls, it was just a question of
> where to copy them to (the root of the build tree or the root of the
> test tree). Either way, I don't think it can interfere with building
> or compiling.
>
Oh, sorry. I was confused by name "abs_buildir" and was thinking that
building directory.
--
Ivan Zhakov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Vlad Georgescu <vg...@gmail.com>.
On 1/6/07, Ivan Zhakov <ch...@gmail.com> wrote:
> > It looks like we're copying the modules to abs_objdir (the build tree)
> > but trying to load them from abs_builddir (the test tree, not very
> > intuitively named). In your case they're different. So, should we:
> >
> > a) tell Apache to load its modules from abs_objdir
> > b) copy the dlls and modules to abs_builddir
> >
> I think copying dlls is better approach because I can run tests in
> background and continue developing and compiling.
I don't understand. We always copy dlls, it was just a question of
where to copy them to (the root of the build tree or the root of the
test tree). Either way, I don't think it can interfere with building
or compiling.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Ivan Zhakov <ch...@gmail.com>.
On 1/5/07, Vlad Georgescu <vg...@gmail.com> wrote:
> On 1/5/07, D.J. Heap <dj...@gmail.com> wrote:
> > On 1/5/07, Vlad Georgescu <vg...@gmail.com> wrote:
> > [snip]
> > > Yeah, copying all the DLLs and modules to the same directory is the
> > > only solution that works. Copying them to the root of the build tree
> > > makes sense because our own binaries will be able to use them, and we
> > > don't have to extend PATH any more. I went ahead and implemented this
> > > in r22913, so ra_dav tests should be working now.
> >
> >
> > Great, thanks! It's not quite working, though -- when trying to start
> > the Apache service I get:
> >
> > Syntax error on line 11 of
> > M:/svn-auto-test/fsfs/subversion/tests/cmdline/httpd/httpd.conf:
> > Cannot load M:/svn-auto-test/fsfs/mod_dav_svn.so into server: The
> > specified module could not be found.
>
> It looks like we're copying the modules to abs_objdir (the build tree)
> but trying to load them from abs_builddir (the test tree, not very
> intuitively named). In your case they're different. So, should we:
>
> a) tell Apache to load its modules from abs_objdir
> b) copy the dlls and modules to abs_builddir
>
I think copying dlls is better approach because I can run tests in
background and continue developing and compiling.
--
Ivan Zhakov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Vlad Georgescu <vg...@gmail.com>.
On 1/5/07, D.J. Heap <dj...@gmail.com> wrote:
> On 1/5/07, Vlad Georgescu <vg...@gmail.com> wrote:
> [snip]
> > Yeah, copying all the DLLs and modules to the same directory is the
> > only solution that works. Copying them to the root of the build tree
> > makes sense because our own binaries will be able to use them, and we
> > don't have to extend PATH any more. I went ahead and implemented this
> > in r22913, so ra_dav tests should be working now.
>
>
> Great, thanks! It's not quite working, though -- when trying to start
> the Apache service I get:
>
> Syntax error on line 11 of
> M:/svn-auto-test/fsfs/subversion/tests/cmdline/httpd/httpd.conf:
> Cannot load M:/svn-auto-test/fsfs/mod_dav_svn.so into server: The
> specified module could not be found.
It looks like we're copying the modules to abs_objdir (the build tree)
but trying to load them from abs_builddir (the test tree, not very
intuitively named). In your case they're different. So, should we:
a) tell Apache to load its modules from abs_objdir
b) copy the dlls and modules to abs_builddir
?
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by "D.J. Heap" <dj...@gmail.com>.
On 1/5/07, Vlad Georgescu <vg...@gmail.com> wrote:
[snip]
> Yeah, copying all the DLLs and modules to the same directory is the
> only solution that works. Copying them to the root of the build tree
> makes sense because our own binaries will be able to use them, and we
> don't have to extend PATH any more. I went ahead and implemented this
> in r22913, so ra_dav tests should be working now.
Great, thanks! It's not quite working, though -- when trying to start
the Apache service I get:
Syntax error on line 11 of
M:/svn-auto-test/fsfs/subversion/tests/cmdline/httpd/httpd.conf:
Cannot load M:/svn-auto-test/fsfs/mod_dav_svn.so into server: The
specified module could not be found.
Which I think means the module wasn't there, or one of it dependencies
wasn't. I'll look at it closer this weekend as soon as I can.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Vlad Georgescu <vg...@gmail.com>.
On 1/5/07, D.J. Heap <dj...@gmail.com> wrote:
> On 1/3/07, Vlad Georgescu <vg...@gmail.com> wrote:
> [snip]
> >
> > Yeah, sorry about that. I just committed a similar (but hopefully
> > correct) fix in r22882.
> >
>
>
> Yep, --disable-shared is working on trunk now for the buildbot, thanks!
>
> So was there consensus on what to do for the ra_dav tests? Copy all
> .so's, .dll's and support files to the test root so Apache can find
> them? I would really rather not copy test build files to the real
> Apache dir.
Yeah, copying all the DLLs and modules to the same directory is the
only solution that works. Copying them to the root of the build tree
makes sense because our own binaries will be able to use them, and we
don't have to extend PATH any more. I went ahead and implemented this
in r22913, so ra_dav tests should be working now.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by "D.J. Heap" <dj...@gmail.com>.
On 1/3/07, Vlad Georgescu <vg...@gmail.com> wrote:
[snip]
>
> Yeah, sorry about that. I just committed a similar (but hopefully
> correct) fix in r22882.
>
Yep, --disable-shared is working on trunk now for the buildbot, thanks!
So was there consensus on what to do for the ra_dav tests? Copy all
.so's, .dll's and support files to the test root so Apache can find
them? I would really rather not copy test build files to the real
Apache dir.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Vlad Georgescu <vg...@gmail.com>.
On 1/3/07, Lieven Govaerts <sv...@mobsol.be> wrote:
> I've tried this patch on the windows buildslave and my laptop, the tests
> don't start:
> Traceback (most recent call last):
> File "C:\devel\subversion\trunk\win-tests.py", line 54, in ?
> gen_obj = gen_win.GeneratorBase('build.conf', version_header, [])
> File "build\generator\gen_base.py", line 123, in __init__
> section.create_targets()
> File "build\generator\gen_base.py", line 339, in create_targets
> self.target = self.target_class(self.name, self.options, self.gen_obj)
> File "build\generator\gen_base.py", line 454, in __init__
> self.msvc_static = options.get('msvc-static') == 'yes' \
> AttributeError: GeneratorBase instance has no attribute 'disable_shared'
Yeah, sorry about that. I just committed a similar (but hopefully
correct) fix in r22882.
--
Vlad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Lieven Govaerts <sv...@mobsol.be>.
Vlad Georgescu wrote:
> Oops. It's supposed to work just like pre-r22841 builds, except that
> it's currently broken. The following patch should fix this:
>
> - self.msvc_static = options.get('msvc-static') == 'yes' # is a static lib
> self.msvc_fake = options.get('msvc-fake') == 'yes' # has fake target
> self.msvc_export = string.split(options.get('msvc-export', ''))
> + # Is a static lib
> + self.msvc_static = options.get('msvc-static') == 'yes' \
> + or (self.msvc_export and gen_obj.disable_shared)
>
I've tried this patch on the windows buildslave and my laptop, the tests
don't start:
Traceback (most recent call last):
File "C:\devel\subversion\trunk\win-tests.py", line 54, in ?
gen_obj = gen_win.GeneratorBase('build.conf', version_header, [])
File "build\generator\gen_base.py", line 123, in __init__
section.create_targets()
File "build\generator\gen_base.py", line 339, in create_targets
self.target = self.target_class(self.name, self.options, self.gen_obj)
File "build\generator\gen_base.py", line 454, in __init__
self.msvc_static = options.get('msvc-static') == 'yes' \
AttributeError: GeneratorBase instance has no attribute 'disable_shared'
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Vlad Georgescu <vg...@gmail.com>.
D.J. Heap wrote:
> On 1/2/07, D.J. Heap <dj...@gmail.com> wrote:
> [snip]
>> I agree with the above, but don't have time to look at right now so I
>> tweaked the buildbot to use --disable-shared until it's addressed.
>
>
> However, that doesn't appear to even build. Is --disable-shared
> supposed to be able to fully build and test everything or is it just
> for building the static libs?
>
> DJ
>
Oops. It's supposed to work just like pre-r22841 builds, except that
it's currently broken. The following patch should fix this:
[[[
Follow-up to r22841: Fix --disable-shared builds on Windows.
* build/generator/gen_base.py
(TargetLib.__init__): If msvc-export is set but disable_shared is
true, build the library statically.
* build/generator/gen_win.py
(get_def_file): Don't create a .def file if disable_shared is true.
]]]
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by "D.J. Heap" <dj...@gmail.com>.
On 1/2/07, D.J. Heap <dj...@gmail.com> wrote:
[snip]
> I agree with the above, but don't have time to look at right now so I
> tweaked the buildbot to use --disable-shared until it's addressed.
However, that doesn't appear to even build. Is --disable-shared
supposed to be able to fully build and test everything or is it just
for building the static libs?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by "D.J. Heap" <dj...@gmail.com>.
On 1/2/07, Branko Čibej <br...@xbc.nu> wrote:
[snip]
> As for the tests -- the buildbots should stop copying the Apache modules
> to the Apache install; instead; win-tests.py should copy all the DLLs
> and httpd .so's to the top of the test tree, and construct an httpd.conf
> that points at the modules there.
I'm pretty sure the tests don't copy the modules to the apache install
-- they make a test config that points to the test module directories
that were copied from the build tree.
I agree with the above, but don't have time to look at right now so I
tweaked the buildbot to use --disable-shared until it's addressed.
DJ
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> On 1/1/07, D.J. Heap <dj...@gmail.com> wrote:
>> It's not the tests that can't find the dll's, though...it is Apache
>> which is a service. Service working directories all default to
>> %WINDIR%\System32, I believe, unless they change it themselves and it
>> doesn't seem likely that Apache would change it to that directory
>> unless there is some config option to do it.
>
> Copying it to Apache's bin\ directory should work though.
>
> I thought that this whole mess is sort of why we've avoided DLLs in
> the past
"We" have? First I've heard of it.
> - it's moderately okay to do that for us, but it's just a
> PITA for people who extend Subversion on Windows. For example, this
> might also wreck TortoiseSVN in similar ways. -- justin
Well here's a paradox -- on the one hand, we've had people clamouring
for DLLs on Windows so that they'd have an easier time of extending SVN;
now you're saying that makes it /harder/ to extend SVN.
Well, nonsense.
* We still have the static libs, which people can continue using if
they want to.
* TortoiseSVN does its own build, so they can either build their own
DLLs (as side-by-side assemblies, which are quite safe), or link
statically.
* We could even link mod_dav_svn statically -- although Subversion's
installer by default points Apache at the mod_dav_svn.so in
Subversion's bin/ directory where all the DLLs will be.
As for the tests -- the buildbots should stop copying the Apache modules
to the Apache install; instead; win-tests.py should copy all the DLLs
and httpd .so's to the top of the test tree, and construct an httpd.conf
that points at the modules there.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 1/1/07, D.J. Heap <dj...@gmail.com> wrote:
> It's not the tests that can't find the dll's, though...it is Apache
> which is a service. Service working directories all default to
> %WINDIR%\System32, I believe, unless they change it themselves and it
> doesn't seem likely that Apache would change it to that directory
> unless there is some config option to do it.
Copying it to Apache's bin\ directory should work though.
I thought that this whole mess is sort of why we've avoided DLLs in
the past - it's moderately okay to do that for us, but it's just a
PITA for people who extend Subversion on Windows. For example, this
might also wreck TortoiseSVN in similar ways. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by "D.J. Heap" <dj...@gmail.com>.
On 1/1/07, Mark Phippard <ma...@gmail.com> wrote:
[snip]
> If it is the current working directory when the tests are started (which I
> believe it typically is) then it would work.
>
It's not the tests that can't find the dll's, though...it is Apache
which is a service. Service working directories all default to
%WINDIR%\System32, I believe, unless they change it themselves and it
doesn't seem likely that Apache would change it to that directory
unless there is some config option to do it.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Mark Phippard <ma...@gmail.com>.
On 1/1/07, D.J. Heap <dj...@gmail.com> wrote:
>
> On 12/31/06, Branko Čibej <br...@xbc.nu> wrote:
> [snip]
> > Maybe win-tests.py should be doing the same thing with the SVN DLLs that
> > it does with the APR DLLs -- copy them to the root of the test dir,
> > instead of changing the path.
> >
>
>
> Hmm, that wouldn't help would it? Or is Apache looking there for some
> reason? Maybe we need to copy the SVN Apache modules and all support
> dll's to the same directory?
If it is the current working directory when the tests are started (which I
believe it typically is) then it would work.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by "D.J. Heap" <dj...@gmail.com>.
On 12/31/06, Branko Čibej <br...@xbc.nu> wrote:
[snip]
> Maybe win-tests.py should be doing the same thing with the SVN DLLs that
> it does with the APR DLLs -- copy them to the root of the test dir,
> instead of changing the path.
>
Hmm, that wouldn't help would it? Or is Apache looking there for some
reason? Maybe we need to copy the SVN Apache modules and all support
dll's to the same directory?
DJ
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Branko Čibej <br...@xbc.nu>.
D.J. Heap wrote:
> On 12/31/06, Lieven Govaerts <lg...@mobsol.be> wrote:
> [snip]
>> The build seems to be working now, but the buildslave's apache isn't
>> starting anymore. Weird, I retried the build, but don't really see the
>> problem.
>>
>> DJ H, can you find out what's wrong?
>>
>
>
> Apache isn't seeing the new dll's. Probably because it is a service
> and gets the system PATH, not the one setup in win-tests.py. Is there
> some way to tweak the temporary apache config to look at the test dll
> paths?
Maybe win-tests.py should be doing the same thing with the SVN DLLs that
it does with the APR DLLs -- copy them to the root of the test dir,
instead of changing the path.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by "D.J. Heap" <dj...@gmail.com>.
On 12/31/06, Lieven Govaerts <lg...@mobsol.be> wrote:
[snip]
> The build seems to be working now, but the buildslave's apache isn't
> starting anymore. Weird, I retried the build, but don't really see the
> problem.
>
> DJ H, can you find out what's wrong?
>
Apache isn't seeing the new dll's. Probably because it is a service
and gets the system PATH, not the one setup in win-tests.py. Is there
some way to tweak the temporary apache config to look at the test dll
paths?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Lieven Govaerts <lg...@mobsol.be>.
Branko Čibej wrote:
> Branko Čibej wrote:
>> Lieven Govaerts wrote:
>>
>>> It looks like the new DLL code doesn't pass the Windows buildslave. Any
>>> idea what goes wrong? Seems to be JavaHL related.
>>>
>>>
>> Damn. I knew I was missing something. I'll look into it.
>>
>
> Heh. Trivial missing dependency. Fixed in r22842.
>
>
The build seems to be working now, but the buildslave's apache isn't
starting anymore. Weird, I retried the build, but don't really see the
problem.
DJ H, can you find out what's wrong?
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Lieven Govaerts wrote:
>
>> It looks like the new DLL code doesn't pass the Windows buildslave. Any
>> idea what goes wrong? Seems to be JavaHL related.
>>
>>
>
> Damn. I knew I was missing something. I'll look into it.
>
Heh. Trivial missing dependency. Fixed in r22842.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn trunk r22841: FAIL (win32-xp VS2005)
Posted by Branko Čibej <br...@xbc.nu>.
Lieven Govaerts wrote:
> It looks like the new DLL code doesn't pass the Windows buildslave. Any
> idea what goes wrong? Seems to be JavaHL related.
>
Damn. I knew I was missing something. I'll look into it.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org