Re: [openssl-users] newer openSSL no longer produce libeay32 on Windows?
On 08/06/2017 20:26, Ludwig, Mark wrote: From: Jakob Bohm, Thursday, June 08, 2017 12:32 PM On 08/06/2017 18:48, Baojun Wang wrote: Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well as libcrypto-1_1-x64.dll, this could be painful for application who has to specify openssl dependency, for example now I have to choose ssl-1_1-x64 and crypto-1_1-x64 as extra-libs, but I imagine there's a more idiomatic way to make linking on windows (not only 64-bit) easier, do you have any idea? Traditionally, Windows (like Unix) uses the same file name for 32 and 64 bits, but puts them in different directories. If they need to be in the same directory for some applications, the traditional solution is to insert "32" or "64" on its own, while still using the same file name for different architectures with the same bitness. For example a compile for 32 bit MIPS (supported by older Windows releases) or 32 bit ARM (supported by newer releases) would have the same name as for 32 bit x86. Similar for the 4 64 bit architectures supported at various times (Alpha 64 bit, Itanium, AMD x86_64, 64 bit ARM). Microsoft did some crazy experiments with a directory scheme called SxS for versioned DLLs, its badly done and should be avoided if possible. The side-by-side (SxS) stuff has its place, but to use it effectively requires using a "manifest" to identify the dependencies explicitly. I also don't recommend it for general use. Regarding the "32" suffix, you'll see that throughout Windows itself, on modern 64-bit versions, because the "32" dates back to the 1990s when Windows was trying to grow out of being a 16-bit DOS program (WIN.EXE) into a 32-bit "operating system" (Windows NT). Many people are misdirected with the term "Win32" into thinking that means 32-bit when it really only means "not 16-bit." Anything labeled "Win32" could be either 32-bit or 64-bit. I haven't started working with OpenSSL 1.1.n, but in OpenSSL 1.0.2, all 64-bit builds produce identically-named binaries such as libeay32.lib and libeay32.dll in the "out32" directory. I know, that was (part of) the basis for my answer. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] newer openSSL no longer produce libeay32 on Windows?
> From: Jakob Bohm, Thursday, June 08, 2017 12:32 PM > > On 08/06/2017 18:48, Baojun Wang wrote: > > Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well > > as libcrypto-1_1-x64.dll, this could be painful for application who > > has to specify openssl dependency, for example now I have to choose > > ssl-1_1-x64 and crypto-1_1-x64 as extra-libs, but I imagine there's a > > more idiomatic way to make linking on windows (not only 64-bit) > > easier, do you have any idea? > Traditionally, Windows (like Unix) uses the same file name for > 32 and 64 bits, but puts them in different directories. If > they need to be in the same directory for some applications, > the traditional solution is to insert "32" or "64" on its own, > while still using the same file name for different architectures > with the same bitness. For example a compile for 32 bit MIPS > (supported by older Windows releases) or 32 bit ARM (supported > by newer releases) would have the same name as for 32 bit x86. > Similar for the 4 64 bit architectures supported at various > times (Alpha 64 bit, Itanium, AMD x86_64, 64 bit ARM). > > Microsoft did some crazy experiments with a directory scheme > called SxS for versioned DLLs, its badly done and should be > avoided if possible. The side-by-side (SxS) stuff has its place, but to use it effectively requires using a "manifest" to identify the dependencies explicitly. I also don't recommend it for general use. Regarding the "32" suffix, you'll see that throughout Windows itself, on modern 64-bit versions, because the "32" dates back to the 1990s when Windows was trying to grow out of being a 16-bit DOS program (WIN.EXE) into a 32-bit "operating system" (Windows NT). Many people are misdirected with the term "Win32" into thinking that means 32-bit when it really only means "not 16-bit." Anything labeled "Win32" could be either 32-bit or 64-bit. I haven't started working with OpenSSL 1.1.n, but in OpenSSL 1.0.2, all 64-bit builds produce identically-named binaries such as libeay32.lib and libeay32.dll in the "out32" directory. Hope this helps, Mark -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] newer openSSL no longer produce libeay32 on Windows?
On 08/06/2017 18:48, Baojun Wang wrote: On windows platform, Some libraries (not openSSL) explicitly link with libeay32.dll, however, it seems openSSL 1.1+ only builds libssl & libcrypto (personally I prefer this, because it is consistent with other *nix platforms). What is the purpose of libeay32? Is it only for 32-bit windows, and is it only part of older openSSL (0.9.8ish)? libeay was the historic name for libcrypto back when OpenSSL was SSLeay, the Windows port was late in implementing the name change. Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well as libcrypto-1_1-x64.dll, this could be painful for application who has to specify openssl dependency, for example now I have to choose ssl-1_1-x64 and crypto-1_1-x64 as extra-libs, but I imagine there's a more idiomatic way to make linking on windows (not only 64-bit) easier, do you have any idea? Traditionally, Windows (like Unix) uses the same file name for 32 and 64 bits, but puts them in different directories. If they need to be in the same directory for some applications, the traditional solution is to insert "32" or "64" on its own, while still using the same file name for different architectures with the same bitness. For example a compile for 32 bit MIPS (supported by older Windows releases) or 32 bit ARM (supported by newer releases) would have the same name as for 32 bit x86. Similar for the 4 64 bit architectures supported at various times (Alpha 64 bit, Itanium, AMD x86_64, 64 bit ARM). Microsoft did some crazy experiments with a directory scheme called SxS for versioned DLLs, its badly done and should be avoided if possible. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] newer openSSL no longer produce libeay32 on Windows?
Hi list, On windows platform, Some libraries (not openSSL) explicitly link with libeay32.dll, however, it seems openSSL 1.1+ only builds libssl & libcrypto (personally I prefer this, because it is consistent with other *nix platforms). What is the purpose of libeay32? Is it only for 32-bit windows, and is it only part of older openSSL (0.9.8ish)? Also on Windows (64-bit), openssl produces libssl-1_1-x64.dll as well as libcrypto-1_1-x64.dll, this could be painful for application who has to specify openssl dependency, for example now I have to choose ssl-1_1-x64 and crypto-1_1-x64 as extra-libs, but I imagine there's a more idiomatic way to make linking on windows (not only 64-bit) easier, do you have any idea? Thanks baojun -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
