Re: [Fwd: Inconsistency in ARM support]
On 26 October 2014 22:43, Andy Polyakov ap...@openssl.org wrote: Hi, There is inconsistency in ARM support and I'd like to gather some opinions on how to resolve it. Circulate this to ARM people near you. At some point an inconsistency of following nature was introduced and then just grew. OpenSSL attempts to adapt to processor it's running on by detecting capabilities and using run-time switch between different code paths. The code probing capabilities is compiled and executed on all supported ARM architectures, ARMv4 through ARMv8. Original rationale was that one should be able to produce universal binary that can be executed on wide range of processors and deliver optimal performance on all of them. But at the same time assembly modules have #if __ARM_ARCH__=X which effectively renders them not as universal as implied in capability probing code. This is the inconsistency. There are two ways to resolve it. 1. __ARM_ARCH__ is effectively controlled by compiler -march command line option, which naturally also controls compiler-generated outcome. In order to live up to original intention to produce universal binary, it would be appropriate to tell *compiler* to generate code for minimal architecture one wants to target, but tell *assembler* to accept instructions for maximum architecture one wants to target, e.g. -march=armv4 -Wa,-march=armv7-a. 2. Abandon the idea of producing true universal binary and limit capability detection to contemporary processor families, ARMv7/8 for the moment of this writing. And run pre-ARMv7 without capability detection (there is nothing to detect really). I suppose distro vendors would prefer 2nd option, because everything has to match anyway. ISV on the other hand might prefer 1st one, unless of course they target specific distros one by one rather than providing unified binaries that can be executed on multiple distros. I think it is perfectly feasible to have one universal build. The usual reason for /not/ having a universal build is that the compiler can emit faster instructions that are not available on the older architectures, but in OpenSSL's case, that is being handled by the runtime selected alternatives anyway. Implied question also is if it's *worth* it. My personal preference is universal too, but what if it creates more problems than it solves. Or it attempt to solve non-existing problem if ISVs are targeting platforms one by one anyway. Or if nobody really cares about pre-ARMv7 when it comes to software *distribution*, i.e. pre-AMRv7 is interesting only in individual cases when you have to target very specific processor and build everything yourself anyway. Well, even if ARMv5 may be a dead target according to some, with Raspberry PI being a non-Thumb2 ARMv6 which I don't think should end up in the 'legacy' column, we are still dealing with a fair amount of variation between the targets that I feel should be supported by the 'high end' build. So yes, I think it is worth it. Since the minimum architecture required by a piece of assembler code is a property of the code itself, it should be encoded into it using .arch/.fpu declarations, and there is no need for the '-Wa' GCC option above. The reason for why I suggested -Wa is to be able to support legacy toolchains, as we can't afford assuming that everybody has capable enough assembler. Basically idea is to be as flexible as possible to meet worst case local circumstances. Yes, this means that the suggestion was actually incomplete, because, as assembler doesn't tell which command line option was passed, one has to convey the missing information by other means, by additional -D option. I want to remind that question is *not* about removing run-time switch as concept, but rather about distinguishing pre-ARMv7 and ARMv=7. I.e. NEON/cryto switch will stay, the only question if it's worth imposing it on pre-ARMv7 builds [assuming that such binaries will be executed even on ARMv=7 systems]. Yes, that is perfectly clear. So we can target armv4 on the compiler command line, and still get crypto instructions when executing the resulting binary on a v8 system. So I would vote for #1, but with the .arch/.fpu declarations moved to the asm files. This is undesired, because we don't want to make assumption that every assembler actually supports these directives and required values. It's safe to assume for big distro vendors, but there are people struggling with exotic toolchains. Well, in that case, will they be able to assemble the file in the first place, even with some -Wa, switch added? I know we deal with that using #ifdef's now, but those should be dropped imo. Perhaps we should introduce MIN_ARCH and MAX_ARCH variables, where the defaults are v4 and v8 respectively, and we can add Configure targets that narrow this down for targets like these? This still allows the distros to target a newer minimum architecture version, and in places
Re: [Fwd: Inconsistency in ARM support]
I want to remind that question is *not* about removing run-time switch as concept, but rather about distinguishing pre-ARMv7 and ARMv=7. I.e. NEON/cryto switch will stay, the only question if it's worth imposing it on pre-ARMv7 builds [assuming that such binaries will be executed even on ARMv=7 systems]. Yes, that is perfectly clear. So we can target armv4 on the compiler command line, and still get crypto instructions when executing the resulting binary on a v8 system. So I would vote for #1, but with the .arch/.fpu declarations moved to the asm files. This is undesired, because we don't want to make assumption that every assembler actually supports these directives and required values. It's safe to assume for big distro vendors, but there are people struggling with exotic toolchains. Well, in that case, will they be able to assemble the file in the first place, even with some -Wa, switch added? Yes, but developer would have the *freedom* to specify -Wa that matches specific environment. I know we deal with that using #ifdef's now, but those should be dropped imo. I'd like to drop them too, but I don't see it as question of liking, at least not for now :-( Perhaps we should introduce MIN_ARCH and MAX_ARCH variables, That's exactly what I meant by convey the missing information by other means, by additional -D option. It looks like specifying maximum would be sufficient. I mean minimum would be controlled by -march to compiler and then -Wa -DMAX could complement it. where the defaults are v4 and v8 respectively, and we can add Configure targets that narrow this down for targets like these? Right now there is only one linux-armv4, and there is no architecture-specific flag there. This implies that you either rely on compiler default or pass specific flag explicitly at configuration stage. ./config actually does exactly this by adding -march=armv7-a if executed on armv7 system. So as alternative to this you'd pass -march=armvmin -Wa,-march=armvmax -D*MAX*=max, thus putting all controls to users' hands. ... #1 has my preference regardless. Got it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3564] Build error OpenSSL 1.0.1i
Followed your instructions regarding changing the target. But received different problems with the assembler. See below Y:\OpenSSL\openssl-1.0.1iperl Configure VC-WIN64A no-asm no-hw Configuring for VC-WIN64A no-asm [option] OPENSSL_NO_ASM no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-hw [option] OPENSSL_NO_HW no-jpake[experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-shared [default] no-store[experimental] OPENSSL_NO_STORE (skip dir) no-unit-test[default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=1 CC=cl CFLAG =-DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYS NAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_N O_DEPRECATE EX_LIBS = CPUID_OBJ =mem_clr.o BN_ASM=bn_asm.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_core.o aes_cbc.o BF_ENC=bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM = RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ = ENGINES_OBJ = PROCESSOR = RANLIB=true ARFLAGS = PERL =perl SIXTY_FOUR_BIT mode DES_INT used RC4_CHUNK is unsigned long long Configured for VC-WIN64A. Y:\OpenSSL\openssl-1.0.1ims\do_win64a Y:\OpenSSL\openssl-1.0.1iperl util\mkfiles.pl 1MINFO Y:\OpenSSL\openssl-1.0.1icmd /c nasm -f win64 -v 1NUL 21 Y:\OpenSSL\openssl-1.0.1iif 1 NEQ 0 goto ml64 Y:\OpenSSL\openssl-1.0.1iperl ms\uplink-x86_64.pl masm 1ms\uptable.asm Y:\OpenSSL\openssl-1.0.1iml64 -c -Foms\uptable.obj ms\uptable.asm 'ml64' is not recognized as an internal or external command, operable program or batch file. Y:\OpenSSL\openssl-1.0.1iperl util\mk1mf.pl VC-WIN64A 1ms\nt.mak Y:\OpenSSL\openssl-1.0.1iperl util\mk1mf.pl dll VC-WIN64A 1ms\ntdll.mak Y:\OpenSSL\openssl-1.0.1iperl util\mkdef.pl 32 libeay 1ms\libeay32.def Y:\OpenSSL\openssl-1.0.1iperl util\mkdef.pl 32 ssleay 1ms\ssleay32.def Y:\OpenSSL\openssl-1.0.1i Y:\OpenSSL\openssl-1.0.1inmake -f ms\ntdll.mak Microsoft (R) Program Maintenance Utility Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. Building OpenSSL perl util/mkdir-p.pl tmp32dll created directory `tmp32dll' perl util/mkdir-p.pl out32dll created directory `out32dll' perl util/mkdir-p.pl inc32 created directory `inc32' perl util/mkdir-p.pl inc32\openssl created directory `inc32/openssl' perl util/copy.pl .\.\e_os.h tmp32dll\e_os.h . snip cl /Fotmp32dll\srp_vfy.obj -Iinc32 -Itmp32dll /MD /Ox -DOPENSSL_THREADS -DDSO_WIN32 -W3 -G s0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_ SECURE_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -D OPENSSL_NO_HW -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL -DOPENSSL _BUILD_SHLIBCRYPTO -c .\crypto\srp\srp_vfy.c srp_vfy.c rc /fotmp32dll\libeay32.res /d CRYPTO ms\version32.rc Microsoft (R) Windows (R) Resource Compiler Version 6.2.9200.16384 Copyright (C) Microsoft Corporation. All rights reserved. ml /c ms\uptable.asm Microsoft (R) Macro Assembler Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. Assembling: ms\uptable.asm ms\uptable.asm(9) : error A2006:undefined symbol : rsp ms\uptable.asm(10) : error A2006:undefined symbol : rsp ms\uptable.asm(11) : error A2006:undefined symbol : rsp ms\uptable.asm(12) : error A2006:undefined symbol : rsp ms\uptable.asm(13) : error A2006:undefined symbol : rcx ms\uptable.asm(14) : error A2006:undefined symbol : rdx ms\uptable.asm(16) : error A2006:undefined symbol : rcx ms\uptable.asm(17) : error A2006:undefined symbol : rdx ms\uptable.asm(18) : error A2006:undefined symbol : r8 ms\uptable.asm(19) : error A2006:undefined symbol : r9 ms\uptable.asm(20) : error A2006:undefined symbol : rax snip ms\uptable.asm(141) : error A2006:undefined symbol : rsp ms\uptable.asm(142) : error A2006:undefined symbol : rax ms\uptable.asm(149) : error A2006:undefined symbol : rsp ms\uptable.asm(150) : error A2006:undefined symbol : rsp ms\uptable.asm(151) : error A2006:undefined symbol : rsp ms\uptable.asm(152) : error A2006:undefined symbol : rsp ms\uptable.asm(153) : error A2006:undefined symbol : rcx ms\uptable.asm(154) : error A2006:undefined symbol : rdx ms\uptable.asm(156) : error A2006:undefined symbol : rcx
Re: [Fwd: Inconsistency in ARM support]
On 27 October 2014 15:11, Andy Polyakov ap...@openssl.org wrote: I want to remind that question is *not* about removing run-time switch as concept, but rather about distinguishing pre-ARMv7 and ARMv=7. I.e. NEON/cryto switch will stay, the only question if it's worth imposing it on pre-ARMv7 builds [assuming that such binaries will be executed even on ARMv=7 systems]. Yes, that is perfectly clear. So we can target armv4 on the compiler command line, and still get crypto instructions when executing the resulting binary on a v8 system. So I would vote for #1, but with the .arch/.fpu declarations moved to the asm files. This is undesired, because we don't want to make assumption that every assembler actually supports these directives and required values. It's safe to assume for big distro vendors, but there are people struggling with exotic toolchains. Well, in that case, will they be able to assemble the file in the first place, even with some -Wa, switch added? Yes, but developer would have the *freedom* to specify -Wa that matches specific environment. I know we deal with that using #ifdef's now, but those should be dropped imo. I'd like to drop them too, but I don't see it as question of liking, at least not for now :-( Perhaps we should introduce MIN_ARCH and MAX_ARCH variables, That's exactly what I meant by convey the missing information by other means, by additional -D option. It looks like specifying maximum would be sufficient. I mean minimum would be controlled by -march to compiler and then -Wa -DMAX could complement it. OK, that sounds doable. But if -Wa is going to be used as a matter of course to pass arch/fpu options, we should get rid of all #ifdef's against things like __thumb2__, as they can be out of sync. where the defaults are v4 and v8 respectively, and we can add Configure targets that narrow this down for targets like these? Right now there is only one linux-armv4, and there is no architecture-specific flag there. This implies that you either rely on compiler default or pass specific flag explicitly at configuration stage. ./config actually does exactly this by adding -march=armv7-a if executed on armv7 system. So as alternative to this you'd pass -march=armvmin -Wa,-march=armvmax -D*MAX*=max, thus putting all controls to users' hands. ... #1 has my preference regardless. Got it. OK. So the existing linux-armv4 target becomes a 'native' target then, where the minimum architecture is decided by the compiler, and the maximum architecture is whatever the most advanced one is that supports all of the runtime selected options. Would it be sufficient to have a single alternative target where the max architecture == min architecture, both based on the compiler's default? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Fwd: Inconsistency in ARM support]
where the defaults are v4 and v8 respectively, and we can add Configure targets that narrow this down for targets like these? Right now there is only one linux-armv4, and there is no architecture-specific flag there. This implies that you either rely on compiler default or pass specific flag explicitly at configuration stage. ./config actually does exactly this by adding -march=armv7-a if executed on armv7 system. So as alternative to this you'd pass -march=armvmin -Wa,-march=armvmax -D*MAX*=max, thus putting all controls to users' hands. ... #1 has my preference regardless. Got it. OK. So the existing linux-armv4 target becomes a 'native' target then, where the minimum architecture is decided by the compiler, and the maximum architecture is whatever the most advanced one is that supports all of the runtime selected options. Would it be sufficient to have a single alternative target where the max architecture == min architecture, both based on the compiler's default? I see no need as './Configure linux-armv4' without extra arguments would be min==max==compiler_default. Additional -march=armvX would be min==max==X. And additional -Wa -D would be min!=max. (I'll comment on the other thing later). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Fwd: Inconsistency in ARM support]
OK, that sounds doable. But if -Wa is going to be used as a matter of course to pass arch/fpu options, we should get rid of all #ifdef's against things like __thumb2__, as they can be out of sync. First of all users would have to recognize and accept that they can't pass -march=armv4 to compiler and at the same time instruct assembler to generate thumb. Because it would undermine whole idea. Then keep in mind that -march=armv4 would never define __thumb2__, so that as long as we look at __ARM_ARCH__ (and not __ARM_MAX_ARCH__) when choosing between .thumb and .code 32, it's not a problem from preprocessor viewpoint. But removing those #ifdefs would prevent user from specifying min==max==7 and thumb. In other words logic around __thumb2__ might have to be refined, but I think it can still be useful. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3564] Build error OpenSSL 1.0.1i
Followed your instructions regarding changing the target. But received different problems with the assembler. See below Y:\OpenSSL\openssl-1.0.1icmd /c nasm -f win64 -v 1NUL 21 Y:\OpenSSL\openssl-1.0.1iif 1 NEQ 0 goto ml64 Y:\OpenSSL\openssl-1.0.1iperl ms\uplink-x86_64.pl masm 1ms\uptable.asm Y:\OpenSSL\openssl-1.0.1iml64 -c -Foms\uptable.obj ms\uptable.asm 'ml64' is not recognized as an internal or external command, operable program or batch file. You do need assembler. If you don't have ml64 (no, ml won't do), then just download nasm and drop it anywhere on %PATH%. Actually nasm is preferred. If in doubt, always use nasm. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: error OpenSsl.obj : error LNK2001: símbolo externo public: struct rsa_st * __thiscall OpenSsl::RSA_new(void) (?RSA_new@OpenSsl@@$$FQAEPAUrsa_st@@XZ) sin resolver C:\Programas\PruFormOpSsl\Releas
OpenSSL version: output of 'openssl version -a': c:\OpenSSL-Win32openssl version -a OpenSSL 1.0.1j 15 Oct 2014 built on: Wed Oct 15 14:33:56 2014 platform: VC-WIN32 options: bn(64,32) rc4(8x,mmx) des(idx,cisc,2,long) idea(int) blowfish(idx) compiler: cl -D_USE_32BIT_TIME_T /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN3 2 -D_USE_32BIT_TIME_T -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_L EAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS - DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA2 56_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENS SL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE OPENSSLDIR: /usr/local/ssl OS Name, Version, Hardware platform: Nombre del SO Microsoft Windows 7 Ultimate Versión 6.1.7600 compilación 7600 Descripción adicional del SO No disponible Fabricante del SO Microsoft Corporation Nombre del sistema WIN-8E8RA3F7M0F Fabricante del sistema VMware, Inc. Modelo del sistema VMware Virtual Platform Tipo de sistema Equipo basado en X86 Procesador Pentium(R) Dual-Core CPU E5200 @ 2.50GHz, 2501 Mhz, 1 procesadores principales, 1 procesadores lógicos Versión y fecha de BIOS Phoenix Technologies LTD 6.00, 18/09/2009 Versión de SMBIOS 2.4 Directorio de Windows C:\Windows Directorio del sistema C:\Windows\system32 Dispositivo de arranque \Device\HarddiskVolume1 Configuración regional España Capa de abstracción de hardware Versión = 6.1.7600.16385 Nombre de usuario WIN-8E8RA3F7M0F\Administrador Zona horaria Hora estándar de Argentina Memoria física instalada (RAM) 1,00 GB Memoria física total 1,00 GB Memoria física disponible 271 MB Memoria virtual total 2,00 GB Memoria virtual disponible 1,13 GB Espacio de archivo de paginación 1,00 GB Archivo de paginación C:\pagefile.sys Compiler Details (name, version): Microsoft Visual Studio Premium 2012 Versión 11.0.50727.1 RTMREL Microsoft .NET Framework Versión 4.5.50709 Versión instalada: Premium Corrector ortográfico de Análisis de código de Visual Studio 2012 04941-004-0043007-02225 Corrector ortográfico de Análisis de código de Microsoft® Visual Studio® 2012 Partes de International CorrectSpell™ spelling correction system © 1993 por Lernout Hauspie Speech Products N.V. Reservados todos los derechos. The American Heritage® Dictionary of the English Language, Third Edition Copyright © 1992 Houghton Mifflin Company. Versión electrónica bajo licencia de Lernout Hauspie Speech Products N.V. Todos los derechos reservados. LightSwitch para Visual Studio 2012 04941-004-0043007-02225 Microsoft LightSwitch para Visual Studio 2012 Office Developer Tools 04941-004-0043007-02225 Microsoft Office Developer Tools Team Explorer para Visual Studio 2012 04941-004-0043007-02225 Microsoft Team Explorer para Visual Studio 2012 Visual Basic 2012 04941-004-0043007-02225 Microsoft Visual Basic 2012 Visual C# 2012 04941-004-0043007-02225 Microsoft Visual C# 2012 Visual C++ 2012 04941-004-0043007-02225 Microsoft Visual C++ 2012 Visual F# 2012 04941-004-0043007-02225 Microsoft Visual F# 2012 Visual Studio 2012 SharePoint Developer Tools 04941-004-0043007-02225 Microsoft Visual Studio 2012 SharePoint Developer Tools Administrador de paquetes NuGet 2.0.30625.9003 Administrador de paquetes NuGet en Visual Studio. Para obtener más información acerca de NuGet, visite http://docs.nuget.org/. Herramientas web para desarrolladores 1.0.30710.0 Las herramientas para desarrolladores de Microsoft contienen los componentes siguientes: Inspector de página: herramienta que ofrece una forma eficiente de descomponer aplicaciones web y diagnosticar problemas de servidores front-end. Publicación web: extensiones que requiere la publicación web para servidores hospedados así como servidores locales. Plantillas de formulario web: incluye las plantillas predeterminadas para aplicaciones de formulario web. Extensiones de editor: incluye extensiones de editor JS, CSS y HTML que mejoran ampliamente la experiencia de desarrollo. PreEmptive Analytics Visualizer 1.0 Extensión de Microsoft Visual Studio para visualizar los resúmenes agregados desde el producto PreEmptive
RE: error OpenSsl.obj : error LNK2001: símbolo externo public: struct rsa_st * __thiscall OpenSsl::RSA_new(void) (?RSA_new@OpenSsl@@$$FQAEPAUrsa_st@@XZ) sin resolver C:\Programas\PruFormOpSsl\Releas
This is a question about using OpenSSL, it should be discussed on openssl-users not openssl-dev. You do not appear to be linking your program against the OpenSSL libraries. You need to change your configuration for building your program to link against the libeay32.lib and ssleay32.lib libraries which were installed with OpenSSL. Regards, jjf From: Fischel [mailto:fajbus...@yahoo.com.ar] Sent: Monday, October 27, 2014 7:26 PM To: openssl-dev@openssl.org hi: It reject's the mail for very large file. I incude program's modules only I look forward to your reply Thank's a lot El Lunes, 27 de octubre, 2014 16:07:33, Fischel HYPERLINK mailto:fajbus...@yahoo.com.arfajbus...@yahoo.com.ar escribió: hi: Build an application in vc ++ that attached to mail To compile it, it gives me the error title. The error log file has: Compilación iniciada a las 27/10/2014 16:57:47. Proyecto c:\Programas\PruFormOpSsl\PruForm\PruForm.vcxproj en el nodo 2 (Rebuild destinos). ClCompile: C:\Program Files\Microsoft Visual Studio 11.0\VC\bin\CL.exe /c /AIC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\\ /AIC:\Program Files\Windows Kits\8.0\References\CommonConfiguration\Neutral /AIC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\\ /Zi /clr /nologo /W3 /WX- /O2 /Oy- /GL /D WIN32 /D NDEBUG /EHa /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Ycstdafx.h /FpRelease\PruForm.pch /FoRelease\\ /FdRelease\vc110.pdb /TP /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\mscorlib.dll /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.Data.dll /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.dll /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.Drawing.dll /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.Windows.Forms.dll /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.Xml.dll /analyze- /errorReport:prompt /clr:nostdlib stdafx.cpp stdafx.cpp C:\Program Files\Microsoft Visual Studio 11.0\VC\bin\CL.exe /c /AIC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\\ /AIC:\Program Files\Windows Kits\8.0\References\CommonConfiguration\Neutral /AIC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Facades\\ /Zi /clr /nologo /W3 /WX- /O2 /Oy- /GL /D WIN32 /D NDEBUG /EHa /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Yustdafx.h /FpRelease\PruForm.pch /FoRelease\\ /FdRelease\vc110.pdb /TP /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\mscorlib.dll /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.Data.dll /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.dll /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.Drawing.dll /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.Windows.Forms.dll /FUC:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\System.Xml.dll /analyze- /errorReport:prompt /clr:nostdlib AssemblyInfo.cpp OpenSsl.cpp PruForm.cpp AssemblyInfo.cpp OpenSsl.cpp PruForm.cpp Generando código... C:\Program Files\Microsoft Visual Studio 11.0\VC\bin\CL.exe /c /Zi /clr /nologo /W3 /WX- /O2 /Oy- /GL /D WIN32 /D NDEBUG /EHa /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /FoRelease\\ /FdRelease\vc110.pdb /TP /analyze- /errorReport:prompt C:\Users\Administrador\AppData\Local\Temp\.NETFramework,Version=v4.5.AssemblyAttributes.cpp .NETFramework,Version=v4.5.AssemblyAttributes.cpp ResourceCompile: C:\Program Files\Windows Kits\8.0\bin\x86\rc.exe /l0x0409 /nologo /foRelease\app.res app.rc Link: C:\Program Files\Microsoft Visual Studio 11.0\VC\bin\link.exe /ERRORREPORT:PROMPT /OUT:C:\Programas\PruFormOpSsl\Release\PruForm.exe /INCREMENTAL:NO /NOLOGO /ASSEMBLYRESOURCE:Release\PruForm.Form1.resources /MANIFEST /MANIFESTUAC:level='asInvoker' uiAccess='false' /manifest:embed /DEBUG /PDB:C:\Programas\PruFormOpSsl\Release\PruForm.pdb /SUBSYSTEM:WINDOWS /PGD:C:\Programas\PruFormOpSsl\Release\PruForm.pgd /LTCG:PGInstrument /TLBID:1 /ENTRY:main /DYNAMICBASE /FIXED:NO /NXCOMPAT /MACHINE:X86 /SAFESEH Release\app.res Release\AssemblyInfo.obj Release\OpenSsl.obj Release\PruForm.obj Release\stdafx.obj Release\.NETFramework,Version=v4.5.AssemblyAttributes.obj OpenSsl.obj : error LNK2001: símbolo externo public: struct rsa_st * __thiscall OpenSsl::RSA_new(void) (?RSA_new@OpenSsl@@$$FQAEPAUrsa_st@@XZ) sin resolver C:\Programas\PruFormOpSsl\Release\PruForm.exe : fatal error LNK1120: 1 externos sin resolver Compilación del proyecto terminada c:\Programas\PruFormOpSsl\PruForm\PruForm.vcxproj (Rebuild
