Re: [openssl-users] Architecture-specific headers

[Kim Gräsman]

On Tue, Oct 18, 2016 at 3:31 PM, Michael Wojcik
 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
>>  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

[Michael Wojcik]

> 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
>  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...

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.

> Any chance that OpenSSL 1.1 is different in this regard?

I don't see how it could be. Other OpenSSL headers need to know information 
about the configuration used to build OpenSSL, and the attributes of the 
platform such as endianness. Some of the settings in opensslconf.h are 
necessary for correctness; others greatly affect performance. There are also 
convenience settings like the default OPENSSLDIR. That information is required 
at compile time and has to come from somewhere.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



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

Re: [openssl-users] Architecture-specific headers

[Salz, Rich]

> Any chance that OpenSSL 1.1 is different in this regard?

No.

Except that the install-top is simpler to configure.
-- 
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
 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

Re: [openssl-users] Architecture-specific headers

[Michael Wojcik]

> 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.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



-- 
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