You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Dale Hirt <da...@sbcltd.com> on 2003/04/21 21:09:36 UTC
gen-make.py oddness
So,
When I run "python gen-make.py -t dsp", it seems to output correctly,
however, when I go to build svn, it errors out with:
Linking...
libsvn_client.lib(diff.obj) : error LNK2001: unresolved external symbol
_svn_diff_file_output_unified
libsvn_client.lib(diff.obj) : error LNK2001: unresolved external symbol
_svn_diff_contains_diffs
libsvn_client.lib(diff.obj) : error LNK2001: unresolved external symbol
_svn_diff_file_diff
libsvn_client.lib(merge.obj) : error LNK2001: unresolved external symbol
_svn_diff_contains_conflicts
libsvn_client.lib(merge.obj) : error LNK2001: unresolved external symbol
_svn_diff_file_output_merge
libsvn_client.lib(merge.obj) : error LNK2001: unresolved external symbol
_svn_diff_file_diff3
..\..\..\Release\svn.exe : fatal error LNK1120: 6 unresolved externals
Error executing link.exe.
I traced it out to the fact that it seems that the only libs being linked to
are "mswsock.lib ws2_32.lib advapi32.lib rpcrt4.lib shfolder.lib
libdb40.lib" in every exe file.
The generator seems to not be picking up any other subversion libs, when it
parses build.conf.
Thanks,
Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gen-make.py oddness
Posted by Branko Čibej <br...@xbc.nu>.
Brandon Ehle wrote:
>>
>>
>> Yup, saw that myself.
>>
>>
>>
>>> I traced it out to the fact that it seems that the only libs being
>>> linked to
>>> are "mswsock.lib ws2_32.lib advapi32.lib rpcrt4.lib shfolder.lib
>>> libdb40.lib" in every exe file.
>>>
>>> The generator seems to not be picking up any other subversion libs,
>>> when it
>>> parses build.conf.
>>>
>>>
>>
>> It's not as simple as that. It does pick up all the libs and registers
>> them as project dependencies (in the .dsw file), which implies linking.
>> However, it's wrong in that it assumes that dependencies are transitive.
>> They're not.
>>
>> The generator should be adding _all_ the dependencies it finds to the
>> project, not just the first level of the dependency DAG.
>>
>>
>>
> The problem with that is that you get thousands of errors about
> duplicately defined symbols during linking if a project is somehow
> dependended upon twice by two different static libraries (though you
> are definitely right about shared libraries). Therefore we try to
> determine that a library is only dependended upon once by any given
> executable. Visual Studio .NET fixes this problem, but for Visual C++
> 6 we have to be smart about the dependency tree.
Have you looked at the patch I posted yesterday? Uh, this morning? It
fixes that particular problem. I just don't know what's going wrong with
the compiled execs.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gen-make.py oddness
Posted by Brandon Ehle <az...@yahoo.com>.
>
>
>Yup, saw that myself.
>
>
>
>>I traced it out to the fact that it seems that the only libs being linked to
>>are "mswsock.lib ws2_32.lib advapi32.lib rpcrt4.lib shfolder.lib
>>libdb40.lib" in every exe file.
>>
>>The generator seems to not be picking up any other subversion libs, when it
>>parses build.conf.
>>
>>
>>
>It's not as simple as that. It does pick up all the libs and registers
>them as project dependencies (in the .dsw file), which implies linking.
>However, it's wrong in that it assumes that dependencies are transitive.
>They're not.
>
>The generator should be adding _all_ the dependencies it finds to the
>project, not just the first level of the dependency DAG.
>
>
>
The problem with that is that you get thousands of errors about
duplicately defined symbols during linking if a project is somehow
dependended upon twice by two different static libraries (though you are
definitely right about shared libraries). Therefore we try to determine
that a library is only dependended upon once by any given executable.
Visual Studio .NET fixes this problem, but for Visual C++ 6 we have to
be smart about the dependency tree.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gen-make.py oddness
Posted by Branko Čibej <br...@xbc.nu>.
Dale Hirt wrote:
>So,
>
>When I run "python gen-make.py -t dsp", it seems to output correctly,
>however, when I go to build svn, it errors out with:
>
>Linking...
>libsvn_client.lib(diff.obj) : error LNK2001: unresolved external symbol
>_svn_diff_file_output_unified
>libsvn_client.lib(diff.obj) : error LNK2001: unresolved external symbol
>_svn_diff_contains_diffs
>libsvn_client.lib(diff.obj) : error LNK2001: unresolved external symbol
>_svn_diff_file_diff
>libsvn_client.lib(merge.obj) : error LNK2001: unresolved external symbol
>_svn_diff_contains_conflicts
>libsvn_client.lib(merge.obj) : error LNK2001: unresolved external symbol
>_svn_diff_file_output_merge
>libsvn_client.lib(merge.obj) : error LNK2001: unresolved external symbol
>_svn_diff_file_diff3
>..\..\..\Release\svn.exe : fatal error LNK1120: 6 unresolved externals
>Error executing link.exe.
>
Yup, saw that myself.
>I traced it out to the fact that it seems that the only libs being linked to
>are "mswsock.lib ws2_32.lib advapi32.lib rpcrt4.lib shfolder.lib
>libdb40.lib" in every exe file.
>
>The generator seems to not be picking up any other subversion libs, when it
>parses build.conf.
>
>
It's not as simple as that. It does pick up all the libs and registers
them as project dependencies (in the .dsw file), which implies linking.
However, it's wrong in that it assumes that dependencies are transitive.
They're not.
The generator should be adding _all_ the dependencies it finds to the
project, not just the first level of the dependency DAG.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org