Crypto/samples: openssl is missing the shared lib/ddl for libeay32 (debug & release)

[zosrothko]

Hi

It seems that the openssl directory is missing the shared lib/ddl for libeay32 (debug & release)

1>------ Début de la génération : Projet : genrsakey, Configuration : debug_shared Win32 ------ 1>LINK : fatal error LNK1104: impossible d'ouvrir le fichier 'libeay32.lib' ========== Génération : 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

1>------ Début de la génération : Projet : genrsakey, Configuration : release_shared Win32 ------ 1>LINK : fatal error LNK1181: impossible d'ouvrir le fichier en entrée 'libeay32.lib' ========== Génération : 0 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

By the way, the script %POCO_BASE%\openssl\buildall.cmd does not work neither. %POCO_BASE%\openssl is missing as prefix of buildall.ps1 and even with the fix, it seems to fail cause of PS

[aleks-f]

PowerShell scripts to build openssl on windows are not meant for end-users; they are an internal tool to pre-build openssl on windows (in order to be able to provide paths in VS solutions that will be valid on target system) and the dependency on PowerShell is clearly stated. On any platform other than windows, system openssl should be used. As for missing directories, send a pull, or I'll look into it for 1.7

[zosrothko]

I fixed the build.ps1 script so it runs also with .Net starting from 3.0 using the Ionic.Zip.ZipFile instead of System.IO.Compression.FileSystem but it remains a problem. build.ps1 produces shared libraries with name ending in Md/Mdd while other prebuild openssl package like the one provided here https://slproweb.com/download/$($env:ssl)OpenSSL-1_0_2d.exe are providing shared openssl libs following the Poco standard, i.e libeay32.dll/libeay32.lib. Thus, IMO, build.ps1 should be changed to produce also openssl shared libs following the Poco standard so that openssl references inside the Poco code be independent of the openssl origin.

Attached the patch for using Ionic.Zip.ZipFile and to start 7za.exe as a PS Start Process.

I would suggest also to move the openssl directory under Crypto so that logically linked suff be at close place in the source tree.

build.ps1.patch.txt

[aleks-f]

Naming of the libraries is with specific purpose - to add some sanity in distinguishing between 32 and 64 bit binaries, MT/D(d) postfix is same as slpro (check their lib/VC directory); if someone is linking with another openssl, they will have to change directories in VS projects anyway. The goal of shipping precompiled binaries was to build Crypto and NetSSL out-of-the-box on windows, without requirement for dependencies installation.

Since this is an internal tool, not meant for end-users and used rarely (release only), I'm not really seeing much point in laboring over how to extract archives. But, if another tool is to be used for decompression, then it should be downloaded automatically, like the other tools (unless Ionic comes with .Net, which to me it does not like it is the case).

[zosrothko]

The https://slproweb.com/download/Win32OpenSSL-1_0_2d.exe brings the following libs: Win32OpenSSL-1_0_2d/libeay32.dll Win32OpenSSL-1_0_2d/ssleay32.dll Win32OpenSSL-1_0_2d/lib/libeay32.lib Win32OpenSSL-1_0_2d/lib/ssleay32.lib

The https://slproweb.com/download/Win64OpenSSL-1_0_2d.exe brings the following libs: Win64OpenSSL-1_0_2d/libeay32.dll Win64OpenSSL-1_0_2d/ssleay32.dll Win64OpenSSL-1_0_2d/lib/libeay32.lib Win64OpenSSL-1_0_2d/lib/ssleay32.lib

Each Win32OpenSSL-1_0_2d/lib/VC Win64OpenSSL-1_0_2d/lib/VC brings also the staic libs as Win32OpenSSL-1_0_2d/lib/VC/libeayMD32.lib Win32OpenSSL-1_0_2d/lib/VC/ssleayMD32.lib Win64OpenSSL-1_0_2d/lib/VC/libeayMD32.lib Win64OpenSSL-1_0_2d/lib/VC/ssleayMD32.lib

Moreover, the poco/Crypto/samples/genrsakey/genrsakey_vs120.vcxproj updated a year ago is referencing libeay32.lib and ssleay32.lib for the shared_debug and shared_release linkmode.

<Link>
  <AdditionalDependencies>libeay32.lib;ssleay32.lib;ws2_32.lib;iphlpapi.lib;%(AdditionalDependencies)</AdditionalDependencies>
  <OutputFile>bin\genrsakeyd.exe</OutputFile>

Thus, IMO, openssl should provide the same set of libraries.

About Ionic.Zip.ZipFile, this is a chicken.egg problem. The original build.ps1 script is using System.IO.Compression.FileSystem for unzipping 7zip itself is available only starting from .Net 4.5. For user like me that are stack to .Net 3.0, one should use Ionic.Zip as a replacement. But ?Net 4.5 is not downloaded by build.ps1 since it should downloaded/installed apart. I do not see what it cannot the same for Ionic. The best option is to add Ionic\zip-v1.9\Release\Ionic.Zip.dll to the git repo so that it would not need to be downloaded and make this build.ps1 script workable on everyversion of .Net.

[zosrothko]

Hi The following link errors when building Poco with VS2014/Win32 are also in the scope of the openssl problems:

libeay32MTd.lib(txt_db.obj) : error LNK2001: unresolved external symbol _iob_func [Z:\git\poco\Crypto\testsuite\TestSuite_vs140.vcxp roj] libeay32MTd.lib(cryptlib.obj) : error LNK2019: unresolved external symbol _sscanf referenced in function _OPENSSL_cpuid_setup [Z:\git\ poco\Crypto\testsuite\TestSuite_vs140.vcxproj] libeay32MTd.lib(v3_utl.obj) : error LNK2001: unresolved external symbol _sscanf [Z:\git\poco\Crypto\testsuite\TestSuite_vs140.vcxproj] libeay32MTd.lib(cryptlib.obj) : error LNK2019: unresolved external symbol vsnprintf referenced in function _OPENSSL_showfatal [Z:\gi t\poco\Crypto\testsuite\TestSuite_vs140.vcxproj] libeay32MTd.lib(gost_eng.obj) : error LNK2019: unresolved external symbol _printf referenced in function _bind_gost [Z:\git\poco\Crypt o\testsuite\TestSuite_vs140.vcxproj] libeay32MTd.lib(pqueue.obj) : error LNK2001: unresolved external symbol _printf [Z:\git\poco\Crypto\testsuite\TestSuite_vs140.vcxproj] bin\static_mt\TestSuited.exe : fatal error LNK1120: 4 unresolved externals [Z:\git\poco\Crypto\testsuite\TestSuite_vs140.vcxproj]

According investigatation, Microsoft has made major change in CRT Runtime : https://connect.microsoft.com/VisualStudio/feedback/details/1144980/error-lnk2001-unresolved-external-symbol-imp-iob-func "The static library needs to be compiled with the same compiler toolset that the application is compiled with."

In visual studio 2015, stdin, stderr, stdout are defined as follow :

define stdin (__acrt_iob_func(0))

define stdout (__acrt_iob_func(1))

define stderr (__acrt_iob_func(2))

But previously, they were defined as:

define stdin (&__iob_func()[0])

define stdout (&__iob_func()[1])

define stderr (&__iob_func()[2])

So, one should comppile OpenSSL with VS2013 for linking OpenSSL with Poco compiled by VS2013 one should comppile OpenSSL with VS2015 for linking OpenSSL with Poco compiled by VS2015 and for sure both OpenSSL (VS2013, VS2015)(Win32, x64) should be available for the overall build.

[aleks-f]

Up to VS2013 the binaries built with 2008 build fine. As for 2015, I was able to reproduce the problem and it means we'll have to provide separate binaries. If we have the problem, then everyone else who distributes binaries must have the same problem.

As for naming of binaries, that will not change for two reasons:

1) 64 bit binary should not have 32 in the name; whatever company from northwest Pacific came up with such logic has a twisted sense of humor

2) we need 32/64 bit naming to be able to generate VS projects; while we could change the progen code and perpetuate the above mentioned twisted logic, I am not inclined to do that

[aleks-f]

fixed

[aleks-f]

and fixed also VS 2015 static linking; openssl has been hacking their build since begining of time but I guess they did not get to VS 2015 yet

[aleks-f]

@zosrothko : please switch AppVeyor build now to use internal openssl binaries; it should all build, including static

[zosrothko]

Ok will do in the flow of fixing AppVeyor issues