Re: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit

[Kim Gräsman]

On Tue, Nov 8, 2016 at 3:05 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:
> On 08/11/2016 14:44, Kim Gräsman wrote:
>>
>> On Tue, Nov 8, 2016 at 2:24 PM, Michael Wojcik
>> <michael.woj...@microfocus.com> wrote:
>>>
>>> My advice, frankly, is to study the OpenSSL build process until you
>>> understand it. We've had
>>> issues in the past with some Windows Perl implementations (currently we
>>> use Cygwin Perl with
>>> a wrapper program that corrects paths)
>>
>> Forgot to mention; I'm building with ActiveState Perl from
>> http://www.ActiveState.com.
>>
> That is the Perl most often quoted as causing problems.
>
> Try Strawberry Perl from http://strawberryperl.com/(Strawberry Perl
> is derived from vanilla Perl, hence the name).

Thanks Jakob. Funny though, it's building successfully here. The OP
hasn't reported his Perl dist yet.

I'll make a note to try with Strawberry Perl moving forward.

- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit

[Kim Gräsman]

On Tue, Nov 8, 2016 at 2:24 PM, Michael Wojcik
 wrote:
>
> My advice, frankly, is to study the OpenSSL build process until you 
> understand it. We've had
> issues in the past with some Windows Perl implementations (currently we use 
> Cygwin Perl with
> a wrapper program that corrects paths)

Forgot to mention; I'm building with ActiveState Perl from
http://www.ActiveState.com.

- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit

[Kim Gräsman]

On Tue, Nov 8, 2016 at 6:26 AM, Ajay Garg  wrote:
>
> Is compiling on windows always such a pain? :(
> On Linux, it compiled perfectly the first time itself.

It's worked well for me in a similar environment. I use DLL builds,
though, so `ntdll.mak` instead of `nt.mak`.

One thing that looks suspicious is this:

> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\VC\
> N\nasm.EXE"' : return code '0x1'

Have you put nasm.exe inside the Visual Studio install dir? That seems
like an odd choice, not sure if the spaces in the path maybe confuses
something?

You also don't mention which directory you're in when running these
commands. I've run everything inside the openssl-1.0.2h (using a
different version) source directory.

- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL with Qt5 on Win7

[Kim Gräsman]

On Thu, Nov 3, 2016 at 2:02 PM, Michel  wrote:

> Hi,
>
>
>
> As nmake is not in your current path, it looks like you didn’t launch the
> ‘Developer Command Prompt for Visual Studio’.
>
>
>
>
>
For posterity, I've gotten that message even when nmake is on the path.
Invoking nmake afterwards works fine.

- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] libraries after the build for WIn platform

[Kim Gräsman]

Hi Ernst,

On Tue, Nov 1, 2016 at 10:25 AM, Ernst Maurer  wrote:
> Thank you for the reply,
> I've tried to build dynamic version (import lib + dll) so I see the libs
> like:
> openssl.lib
> libcrypto.lib
> capi.lib
> and some other ones,
>
> so do you mean that libeay32 and ssleay32 some depricated version ? and
> recommend me to go throu the git history for a looking for? (of course, I
> built from the head of git.)
>
> P.S. I need this for the linking with Microsoft REST SDK (aka Casablanca)

There are two generations of OpenSSL in flight at the moment:

- 1.0.2, the 'old' one. Libs are named libeay32.* and ssleay32.*
- 1.1.0, the 'new' one. Libs are named libcrypto*.* and libssl*.*

1.1.0 was released quite recently, so there's a good chance existing
clients are more compatible with 1.0.2.

We're building 1.0.2 from released source packages so I'm not sure
about the details, but if you have a git clone there should be a tag
or branch you could check out.

- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Architecture-specific headers

[Kim Gräsman]

On Tue, Oct 18, 2016 at 3:31 PM, Michael Wojcik
<michael.woj...@microfocus.com> wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Kim Gräsman
>> Sent: Tuesday, October 18, 2016 07:04
>>
>> On Tue, Oct 18, 2016 at 2:21 PM, Michael Wojcik
>> <michael.woj...@microfocus.com> wrote:
>> >
>> > So, in short: You do in fact have to publish and maintain one architecture-
>> specific header.
>>
>> Thanks, I was afraid so. We're compiling for 6 different targets, so
>> this will turn into an exciting problem :-)
>
> I don't know what your build system looks like, but it wasn't a terribly 
> difficult problem for us. Don't you already have platform-specific headers? 
> You have platform-specific libraries...

No platform-specific headers in third-parties, no.

> I deal with 11 platforms for OpenSSL currently - most of which have multiple 
> flavors (bitness and threadedness; fortunately at the moment we're not doing
> both debug and release builds as well). Not that big a deal to build all of 
> them and harvest opensslconf.h alongside the shared objects / DLLs.

That makes sense to me -- we already build the library paths based on
all the relevant properties, so if I publish opensslconf.h together
with the libraries, I should be able to add the same suffix to the
include path.

Thanks for talking me through it!

- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Architecture-specific headers

[Kim Gräsman]

On Tue, Oct 18, 2016 at 3:11 PM, Salz, Rich  wrote:
>
>> Any chance that OpenSSL 1.1 is different in this regard?
>
> No.
>
> Except that the install-top is simpler to configure.

Thanks, Rich. Yeah, I'm looking forward to the 1.1 build system!

- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Architecture-specific headers

[Kim Gräsman]

Hi Michael,

On Tue, Oct 18, 2016 at 2:21 PM, Michael Wojcik
<michael.woj...@microfocus.com> wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Kim Gräsman
>> Sent: Tuesday, October 18, 2016 04:14
>>
>> Everything seems to work pretty well, but one thing is worrying -- the
>> opensslconf.h header comes out different between the two builds.
>>
>> I'm assuming this only affects implementation details in OpenSSL and
>> not the public API? I don't have to publish and maintain
>> architecture-specific headers, do I?
>
> opensslconf.h is generated from the configuration settings and platform 
> characteristics, and applications must be compiled using the opensslconf.h 
> that corresponds to the build they link to (or one that's equivalent).
>
> Sometimes you can get away with using the wrong opensslconf.h, but this can 
> cause hard-to-find errors. One project I know of went for several years using 
> the wrong opensslconf.h, and it was only discovered when a different project 
> used some other OpenSSL features and got incorrect results on some platforms.
>
> So, in short: You do in fact have to publish and maintain one 
> architecture-specific header.

Thanks, I was afraid so. We're compiling for 6 different targets, so
this will turn into an exciting problem :-)

I'll try to think up a way forward with this.

Any chance that OpenSSL 1.1 is different in this regard?

Thank you,
- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Architecture-specific headers

[Kim Gräsman]

Hi all,

I'm working on building OpenSSL 1.0.2 for both Windows x86 and AMD64,
i.e. the VC-WIN32 and VC-WIN64A platforms.

Everything seems to work pretty well, but one thing is worrying -- the
opensslconf.h header comes out different between the two builds.

I'm assuming this only affects implementation details in OpenSSL and
not the public API? I don't have to publish and maintain
architecture-specific headers, do I?

Attaching a diff from a recent build for reference.

Thanks,
- Kim
--- x86\inc32\openssl\opensslconf.h 2016-10-18 10:19:26.0 +0200
+++ x64\inc32\openssl\opensslconf.h 2016-10-18 10:34:34.0 +0200
@@ -2,14 +2,14 @@
 /* WARNING: Generated automatically from opensslconf.h.in by Configure. */
 
 #ifdef  __cplusplus
 extern "C" {
 #endif
 /* OpenSSL was configured with the following options: */
-#ifndef OPENSSL_SYSNAME_WIN32
-# define OPENSSL_SYSNAME_WIN32
+#ifndef OPENSSL_SYSNAME_WIN64A
+# define OPENSSL_SYSNAME_WIN64A
 #endif
 #ifndef OPENSSL_DOING_MAKEDEPEND
 
 
 #ifndef OPENSSL_NO_EC_NISTP_64_GCC_128
 # define OPENSSL_NO_EC_NISTP_64_GCC_128
@@ -155,41 +155,41 @@
 #endif
 #if !defined(RC4_CHUNK)
 /*
  * This enables code handling data aligned at natural CPU word
  * boundary. See crypto/rc4/rc4_enc.c for further details.
  */
-#undef RC4_CHUNK
+#define RC4_CHUNK unsigned long long
 #endif
 #endif
 
 #if (defined(HEADER_NEW_DES_H) || defined(HEADER_DES_H)) && !defined(DES_LONG)
 /* If this is set to 'unsigned int' on a DEC Alpha, this gives about a
  * %20 speed up (longs are 8 bytes, int's are 4). */
 #ifndef DES_LONG
-#define DES_LONG unsigned long
+#define DES_LONG unsigned int
 #endif
 #endif
 
 #if defined(HEADER_BN_H) && !defined(CONFIG_HEADER_BN_H)
 #define CONFIG_HEADER_BN_H
-#define BN_LLONG
+#undef BN_LLONG
 
 /* Should we define BN_DIV2W here? */
 
 /* Only one for the following should be defined */
 #undef SIXTY_FOUR_BIT_LONG
-#undef SIXTY_FOUR_BIT
-#define THIRTY_TWO_BIT
+#define SIXTY_FOUR_BIT
+#undef THIRTY_TWO_BIT
 #endif
 
 #if defined(HEADER_RC4_LOCL_H) && !defined(CONFIG_HEADER_RC4_LOCL_H)
 #define CONFIG_HEADER_RC4_LOCL_H
 /* if this is defined data[i] is used instead of *data, this is a %20
  * speedup on x86 */
-#define RC4_INDEX
+#undef RC4_INDEX
 #endif
 
 #if defined(HEADER_BF_LOCL_H) && !defined(CONFIG_HEADER_BF_LOCL_H)
 #define CONFIG_HEADER_BF_LOCL_H
 #undef BF_PTR
 #endif /* HEADER_BF_LOCL_H */
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Customize Windows library names

[Kim Gräsman]

Hi Richard,

On Fri, Sep 16, 2016 at 12:08 AM, Richard Levitte <levi...@openssl.org> wrote:
> In message 
> <CANt7B+feUe2W7627Nrw5bVOnZ1Wb5uQ4z57=ry9lwe7d0b2...@mail.gmail.com> on Thu, 
> 15 Sep 2016 12:17:12 +0200, Kim Gräsman <kim.gras...@gmail.com> said:
>
> kim.grasman> I'm looking at integrating OpenSSL 1.1 in our tree, and I 
> noticed the
> kim.grasman> Windows build system now produces decorated lib names.
>
> For DLLs, yes.
>
> kim.grasman> The general pattern seems to be lib_[-].lib 
> where
> kim.grasman>  is only appended for 64-bit builds.
>
> Are you sure?  Looking at my builds, I find libcrypto-1_1.dll and
> libssl-1_1.dll with the import libraries libcrypto.lib and
> libssl.lib.

Ahem. I *was* sure, but with a clean build, I can see you're absolutely right.

I must have mixed up the DLL names and import lib names at some point.

Sorry about the confusion!

- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Customize Windows library names

[Kim Gräsman]

Hi Thomas,

On Thu, Sep 15, 2016 at 4:26 PM, Thomas J. Hruska
 wrote:
>
> The precompiled binary installer variants do this already.  If you are using
> default builds, then that's possibly an option.

We prefer to build from source to allow static and dynamic code
analysis, for example.

But do you have a link to these precompiled binary installers? Do you
know how they accomplish plain names?

Thanks,
- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Customize Windows library names

[Kim Gräsman]

Hi all,

I'm looking at integrating OpenSSL 1.1 in our tree, and I noticed the
Windows build system now produces decorated lib names.

The general pattern seems to be lib_[-].lib where
 is only appended for 64-bit builds.

We'd prefer a naked lib name, at least for import libs (the DLL names
are not important to us, as long as the import lib binds to the right
name).

Is there a supported way of dumbing down the names of libcrypto and
libssl? I can resort to a private patch, but it'd be nice if Configure
could be convinced to keep it simple out of the box.

Thanks,
- Kim
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users