Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: 1.9/trunk build errors when building without OpenSSL
To: dev@subversion.apache.org
References: <55AD0392.9010609@egosoft.com> <55ADDEDA.6070304@wandisco.com>
From: Stefan Hett <stefan@egosoft.com>
Message-ID: <55AE1598.6020207@egosoft.com>
Date: Tue, 21 Jul 2015 11:49:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55ADDEDA.6070304@wandisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 7/21/2015 7:55 AM, Branko Čibej wrote:
> On 20.07.2015 16:20, Stefan Hett wrote:
>> Hi,
>>
>> following several hours of investigation and discussion on IRC with
>> danielsh, philipm and bert I believe there to be some issue in the
>> build generator for Windows.
>>
>> Running the python command:
>> python gen-make.py -t vcproj --with-zlib=..\zlib --with-apr=..\apr
>> --with-apr-util=..\apr-util --vsnet-version=2010
>>
>> followed by building (using VS 2010 SP1):
>> msbuild subversion_vcnet.sln /t:__ALL_TESTS__ /p:Configuration=Release
>>
>> I get 8 project errors:
>> - libsvn_ra_dll: LINK : fatal error LNK1181: cannot open input file
>> 'ssleay32.lib'
>> [E:\[delete]SVNTest\SVN\src-trunk\build\win32\vcnet-vcproj\libsvn_ra_dll.vcxproj]
>> - test_client: LINK : fatal error LNK1181: cannot open input file
>> 'ssleay32.lib'
>> [E:\[delete]SVNTest\SVN\src-trunk\build\win32\vcnet-vcproj\test_client.vcxproj]
>> - conflict-data-test: LINK : fatal error LNK1181: cannot open input
>> file 'ssleay32.lib'
>> [E:\[delete]SVNTest\SVN\src-trunk\build\win32\vcnet-vcproj\test_conflict_data.vcxproj]
>> - some more tests - all with ssleay32.lib missing
>>
>> ssleay32.lib is an OpenSSL library specified in build.conf in the
>> openssl-section alongside libeay32.lib for the "msvc-libs"-option.
>>
>> Looking at the generated libsvn_ra_dll.vcxproj-file actually shows the
>> additional linker dependencies being set to:
>> [...]ssleay32.lib;libeay32.lib;secur32.lib[...]
>>
>> IMHO this is wrong. I'm explicitly building without OpenSSL as well as
>> without serf and still these OpenSSL/Serf librarie references are
>> being generated in the project files.
>>
>> Taken from build.conf:
>> libsvn_ra specifies "ra_libs" as a libs dependency and "ra-libs"
>> specifies "libsvn_ra_serf" as a libs-dependency which then specifies
>> "serf" as a lib-dependency which defines msvc-libs as secur32.lib.
>> "serf" then also defines "openssl" as the dependency which in effect
>> takes ssleay32.lib and libeay32.lib as the setting for msvc-libs.
>>
>> gen_win.py:get_win_libs: takes the msvc-libs conditionless as the
>> required dependencies *UNLESS* the target specifies msvc_static (in
>> which case get_win_libs returns an empty array).
>>
>> Originally my thought was that the generated dependency tree should be
>> adjusted so it correctly reflects the build-parameter-state (aka: drop
>> serf/openSSL completely) but danielsh clarified to me that he believes
>> the issue rather to be in the part generating the project output since
>> the dependency tree should simply reflect exactly what is specified in
>> the build.conf-file.
>>
>> So I guess that the issue is located in gen_win.py:get_win_libs() not
>> omitting the libraries, if these are not specified by the gen-make
>> commands.
>>
>> I've tested the attached patch and with that applied, running the two
>> build commands stated above succeed with no errors (also verified that
>> the generated project files then no longer contain the lib-references).
>> However, I'm not 100% convinced yet that this is the correct approach
>> or whether some more generic solution would be more suitable (aka one
>> which would handle any optional library not present and the
>> corresponding entry in the build dependency tree).
>> Given that there's already another special case command omitting the
>> ra-serf-install target if "serf" is not found, I guess the patch might
>> be acceptable though.
>> Nevertheless, I think some SVN developer is better of with providing
>> more input on this so to find the right solution.
>>
>> (note: the issue also exists in 1.9 and currently results in the fact
>> that building without OpenSSL fails on Windows - assuming this is not
>> a problem in 1.8, it's a regression of 1.9 compared to 1.8).
> It's very likely not a regression but a long-standing missing feature of
> the Windows build generator.
>
> Note that these days, the only thing that uses OpenSSL is Serf; so, the
> libsvn_ra DLL should only link OpenSSL if we're statically linking Serf
> and if Serf was build with OpenSSL support. Even then, I believe that
> OpenSSL should be in the Serf library dependency list. I'd have expected
> that there'd be no need to mention the OpenSSL importlib dependencies in
> the libsvn_ra project at all ... but ISTR they're needed on Windows
> despite the explicit dependency in Serf?
>
> -- Brane
>
I think I can't follow you here. openssl is only listed as a dependency 
in [serf] in build.conf. There's no explicit dependency to openSSL in 
libsvn_ra. Only the implicit one via serf.
And yes, as far as my understanding with Windows/DLLs goes that's 
needed, unless you build openssl statically and link it that way into serf.

For the record: I didn't test whether building openSSL statically and 
linking it that way with Serf is possible/supported at all.

Regards,
Stefan