Re: [openssl-dev] Upcoming build system change

2016-02-09 Thread Richard Levitte 
In message <20160209.084137.1237311317473114554.levi...@openssl.org> on Tue, 09 
Feb 2016 08:41:37 +0100 (CET), Richard Levitte  said:

levitte> In message <16020900205830_2020a...@antinode.info> on Tue, 9 Feb 2016 
00:20:58 -0600 (CST), "Steven M. Schweda"  said:
levitte> sms> For a little recent, related Perl-on-VMS discussion, there's a 
thread on
levitte> sms> comp.os.vms: 
levitte> sms> 
levitte> sms> https://groups.google.com/forum/#!topic/comp.os.vms/npJUbALe9Lo

That discussion explained quite a lot!

I was lucky (*) in my tests, the device of the directory I tested in
was the volume label.

I'm not sure I need your configdata.pm or descrip.mms at this point...

Cheers,
Richard

(*) or not so lucky, I didn't get to have your wonderful experience ;-)

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-02-08 Thread Steven M. Schweda 
> - Perl!  Reports tell me that version 5.10.1 works fine [...]

   Perhaps, but around here, the current version fails pretty badly:

ALP $ perl --version

This is perl 5, version 22, subversion 1 (v5.22.1) built for VMS_AXP

   The generated descrip.mms is defective.  It starts out reasonable,
with stuff like:

SRCDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
BUILDDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build]

but many (supposedly relative) derived paths are bad.  For example:

DEFINE SRCTOP 
[-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
DEFINE BLDTOP 
[-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
$(PERL) 
[-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.test]run_tests.pl
 $(TESTS)

copy-certs :
@ IF 
F$SEARCH("[.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]certs.dir")
 .EQS. "" THEN -
 CREATE/DIR 
[.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.certs]

and so on.  With all this device-directory confusion ("DISK$UTIL5ALPX:"
v. "[.DISK$UTIL5ALPX]"), failures come thick and fast.

   Apparently, all the realpath() and abs2rel() stuff does horrible
things on VMS in some circumstances (like mine).  My default
device:[directory] spec does not include the DISK$volume_label device
name:

ALP $ show default
  UTILITY5_DEV:[UTILITY.source.openssl.openssl-refactor-build]

ALP $ show logical UTILITY5_DEV
   "UTILITY5_DEV" = "ALP$DKC100:" (LNM$SYSTEM_TABLE)

ALP $ show logical DISK$UTIL5ALPX
   "DISK$UTIL5ALPX" = "ALP$DKC100:" (LNM$SYSTEM_TABLE)

   If there's a requirement to use the DISK$volume_label device name,
then there needs to be some (seriously restrictive and/or confusing)
documentation, or else some improved automation to set it as required.

   If Perl can't do this work reliably on VMS, then it might make more
sense to derive such directories/paths using DCL, and let Perl do the
stuff which can be done more portably.

   Knowing approximately nothing about Perl, I'm ill-equipped to
contribute much more to this discussion than complaints about how badly
it works, but I'm open to requests for details or more testing.  For a
little recent, related Perl-on-VMS discussion, there's a thread on
comp.os.vms: 

https://groups.google.com/forum/#!topic/comp.os.vms/npJUbALe9Lo

   I still don't know why the CPAN stuff failed here, but it did.

   I don't object to Perl being required to build OpenSSL, but if the
OpenSSL builders are sensitive to Perl versions, or to fine details in
how the user specifies his default dev:[dir], then I predict abundant
complaints from a large fraction of VMS users who try to build this
stuff.  (Which may not be a large number, of course.)

   I fetched my openssl-refactor-build.zip kit around 14-JAN-2016, so if
significantly changes were made since then, then I don't know about
them.

> ! There is no install target yet.
> ! As a matter of fact, I'd like to talk about exactly where it
> ! should install.  Let's talk!

   Because VMS lacks a popular default localtion (like /usr/local), I
suggest asking the victim where he'd like it.

> Feedback welcome!

   I'm almost always willing to complain.



   Steven M. Schweda   sms@antinode-info
   382 South Warwick Street(+1) 651-699-9818
   Saint Paul  MN  55105-2547
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-02-08 Thread Richard Levitte 
In message <16020900205830_2020a...@antinode.info> on Tue, 9 Feb 2016 00:20:58 
-0600 (CST), "Steven M. Schweda"  said:

sms> > - Perl!  Reports tell me that version 5.10.1 works fine [...]
sms> 
sms>Perhaps, but around here, the current version fails pretty badly:
sms> 
sms> ALP $ perl --version
sms> 
sms> This is perl 5, version 22, subversion 1 (v5.22.1) built for
sms> VMS_AXP

In my case:

$ perl --version

This is perl 5, version 20, subversion 1 (v5.20.1) built for VMS_AXP

I sure hope things haven't gone for the worse...

sms>The generated descrip.mms is defective.  It starts out reasonable,
sms> with stuff like:
sms> 
sms> SRCDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
sms> BUILDDIR=DISK$UTIL5ALPX:[UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
sms> 
sms> but many (supposedly relative) derived paths are bad.  For example:
sms> 
sms> DEFINE SRCTOP 
[-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
sms> DEFINE BLDTOP 
[-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]
sms> $(PERL) 
[-.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.test]run_tests.pl
 $(TESTS)

That's...  bad.

I would like three things from you:

1. The configuration command line you used.
2. configdata.pm (it's produced by Configure)
3. descrip.mms

("We are the Spanish Inquisition...")

sms> copy-certs :
sms> @ IF 
F$SEARCH("[.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build]certs.dir")
 .EQS. "" THEN -
sms>  CREATE/DIR 
[.DISK$UTIL5ALPX.UTILITY.SOURCE.OPENSSL.openssl-refactor-build.certs]
sms> 
sms> and so on.  With all this device-directory confusion ("DISK$UTIL5ALPX:"
sms> v. "[.DISK$UTIL5ALPX]"), failures come thick and fast.
sms> 
sms>Apparently, all the realpath() and abs2rel() stuff does horrible
sms> things on VMS in some circumstances (like mine).

It seems there are circumstances I haven't tested (yet).  Although, I
recall having some (unrelated) trouble with realpath(), that might be
something for me to look into.

sms> My default device:[directory] spec does not include the DISK$volume_label 
device
sms> name:
sms> 
sms> ALP $ show default
sms>   UTILITY5_DEV:[UTILITY.source.openssl.openssl-refactor-build]

Was this the directory you configured and built in as well?
(I'm asking, because Configure now supports building outside of the
source directory)

sms> ALP $ show logical UTILITY5_DEV
sms>"UTILITY5_DEV" = "ALP$DKC100:" (LNM$SYSTEM_TABLE)
sms> 
sms> ALP $ show logical DISK$UTIL5ALPX
sms>"DISK$UTIL5ALPX" = "ALP$DKC100:" (LNM$SYSTEM_TABLE)
sms> 
sms>If there's a requirement to use the DISK$volume_label device name,
sms> then there needs to be some (seriously restrictive and/or confusing)
sms> documentation, or else some improved automation to set it as required.

No such requirement.  Configure is supposed to figure things out from
your default directory and other given data.

sms>Knowing approximately nothing about Perl, I'm ill-equipped to
sms> contribute much more to this discussion than complaints about how badly
sms> it works, but I'm open to requests for details or more testing.

Thanks.

sms> For a little recent, related Perl-on-VMS discussion, there's a thread on
sms> comp.os.vms: 
sms> 
sms> https://groups.google.com/forum/#!topic/comp.os.vms/npJUbALe9Lo

(Oh my, I haven't approached Usenet or whatever it has become in ages)

sms>I fetched my openssl-refactor-build.zip kit around 14-JAN-2016, so if
sms> significantly changes were made since then, then I don't know about
sms> them.

Things have changed a bit, it might be that a newer fetch clears
things up.  Not going to guarantee it, though, so let me check through
the stuff I hope you'll send me first.

sms> > ! There is no install target yet.
sms> > ! As a matter of fact, I'd like to talk about exactly where it
sms> > ! should install.  Let's talk!
sms> 
sms>Because VMS lacks a popular default localtion (like /usr/local), I
sms> suggest asking the victim where he'd like it.

Actually, from looking at what the vms-ports folks do, it seems that
SYS$COMMON:['name'...] is a popular location

sms> > Feedback welcome!
sms> 
sms>I'm almost always willing to complain.

Heh ;-)

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Richard Levitte 


On January 23, 2016 11:55:54 PM GMT+01:00, Tim Rice  
wrote:
>On Sat, 23 Jan 2016, Corinna Vinschen wrote:
>
>> diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl
>src/openssl-1.1-rc1/util/mkbuildinf.pl
>> --- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl   2016-01-23
>21:02:18.386710976 +0100
>> +++ src/openssl-1.1-rc1/util/mkbuildinf.pl   2016-01-23
>21:15:19.705883094 +0100
>> @@ -1,4 +1,4 @@
>> -#!/usr/local/bin/perl
>> +#!/usr/bin/perl
>
>A more portable fix would be
>#!/usr/bin/env perl

Yes. Thanks for the reminder. 

-- 
levi...@openssl.org 
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Quanah Gibson-Mount 
--On Monday, January 25, 2016 12:05 AM +0100 Richard Levitte 
 wrote:



quanah> Actually it was Ubuntu rather than RHEL.  Unfortuantely, beyond
that, quanah> we're lacking on details, other than it was a perl found in
quanah> /usr/local/bin.

Ok, so I take it someone had made a local build and installation of
perl and forgot to clear it out when the perl package was installed.
That *ahem* happens to me at times.  That's nothing the OpenSSL build
can have any control over, or env.

Generally speaking, '#!/usr/bin/env perl' is the right thing to do,
really.


Yeah, I'm primarily noting it so that if it comes up in the future, there's 
an idea as to what the solution is for the end user (fix their path, etc).


--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Corinna Vinschen 
On Jan 23 22:12, Richard Levitte wrote:
> In message <20160123210116.gb13...@calimero.vinschen.de> on Sat, 23 Jan 2016 
> 22:01:16 +0100, Corinna Vinschen  said:
> 
> vinschen> On Jan 23 21:35, Kurt Roeckx wrote:
> vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote:
> vinschen> > > 
> vinschen> > > Last but not least, we have another problem with enginesdir.  
> To allow a
> vinschen> > > rolling release cycle, we have to support multiple versions of 
> openssl
> vinschen> > > in parallel.  The problem here is that the enginesdir needs to 
> be
> vinschen> > > versioned to allow per-openssl version engines.  The build 
> scripts don't
> vinschen> > > allow for this.  Right now we're using a patch as the below one 
> to tweak
> vinschen> > > the configury to allow specifying the engines dir during build 
> time.
> vinschen> > > Would it hurt terribly to include something like the below 
> patch?
> vinschen> > 
> vinschen> > In general, I would like to have a directory for the engines that
> vinschen> > relates to OSSL_DYNAMIC_OLDEST.
> vinschen> 
> vinschen> That probably won't work for Cygwin.  The engines are linked 
> against the
> vinschen> versioned DLLs of the OpenSSL version they have been built for,  
> Even
> vinschen> assuming binary compatibility, an engine linked against openssl-1.0 
> will
> vinschen> pull in openssl-1.0 DLLs, even when loaded from openssl-1.1.  We 
> have to
> vinschen> keep the engines separate.
> 
> This is interesting, actually.  OSSL_DYNAMIC_OLDEST has some design
> around it that's meant to permit EXACTLY that kind of mixture.  It's
> in the macro IMPLEMENT_DYNAMIC_BIND_FN.  However, it's possible it's
> not doing enough, and figuring out what else it needs to do is a
> venture I think is worth spending some time on.

The problem here is Windows and how DLL dependencies are resolved.
We're using versioned DLLs, e.g.

  /usr/bin/cygcrypto-0.9.8.dll
  /usr/bin/cygcrypto-1.0.0.dll
  /usr/bin/cygcrypto-1.1.dll

When building engines, the engines are shared libs linking against the
crypto DLL.  This creates a hard dependency to the DLL the engine has
been linked against.  So, consider using an application linked against
cygcrypto-1.1.dll.  It loads an engine built with and thus linked
against cygcrypto-1.0.0.dll.  While the application will use functions
from cygcrypto-1.1.dll, the engine will use functions from
cygcrypto-1.0.0.dll.  Hilarity ensues.  Unless cygcrypto-1.0.0.dll has
been deprecated and removed.  In which case loading the engine fails.

To decouple an engine from a DLL version, what we would have to do is
to change the engines not to link against libcrypto, but rather to load
*all* functions dynamically at runtime (dlload/dlsym(*)).  Only this
would allow to decouple the engines from a specific versioned DLL.


Corinna


(*) On Windows (but NOT Cygwin): LoadLibrary/GetProcAddress.


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Kurt Roeckx 
On Sun, Jan 24, 2016 at 01:19:00PM +0100, Corinna Vinschen wrote:
> On Jan 23 22:12, Richard Levitte wrote:
> > In message <20160123210116.gb13...@calimero.vinschen.de> on Sat, 23 Jan 
> > 2016 22:01:16 +0100, Corinna Vinschen  said:
> > 
> > vinschen> On Jan 23 21:35, Kurt Roeckx wrote:
> > vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen 
> > wrote:
> > vinschen> > > 
> > vinschen> > > Last but not least, we have another problem with enginesdir.  
> > To allow a
> > vinschen> > > rolling release cycle, we have to support multiple versions 
> > of openssl
> > vinschen> > > in parallel.  The problem here is that the enginesdir needs 
> > to be
> > vinschen> > > versioned to allow per-openssl version engines.  The build 
> > scripts don't
> > vinschen> > > allow for this.  Right now we're using a patch as the below 
> > one to tweak
> > vinschen> > > the configury to allow specifying the engines dir during 
> > build time.
> > vinschen> > > Would it hurt terribly to include something like the below 
> > patch?
> > vinschen> > 
> > vinschen> > In general, I would like to have a directory for the engines 
> > that
> > vinschen> > relates to OSSL_DYNAMIC_OLDEST.
> > vinschen> 
> > vinschen> That probably won't work for Cygwin.  The engines are linked 
> > against the
> > vinschen> versioned DLLs of the OpenSSL version they have been built for,  
> > Even
> > vinschen> assuming binary compatibility, an engine linked against 
> > openssl-1.0 will
> > vinschen> pull in openssl-1.0 DLLs, even when loaded from openssl-1.1.  We 
> > have to
> > vinschen> keep the engines separate.
> > 
> > This is interesting, actually.  OSSL_DYNAMIC_OLDEST has some design
> > around it that's meant to permit EXACTLY that kind of mixture.  It's
> > in the macro IMPLEMENT_DYNAMIC_BIND_FN.  However, it's possible it's
> > not doing enough, and figuring out what else it needs to do is a
> > venture I think is worth spending some time on.
> 
> The problem here is Windows and how DLL dependencies are resolved.
> We're using versioned DLLs, e.g.
> 
>   /usr/bin/cygcrypto-0.9.8.dll
>   /usr/bin/cygcrypto-1.0.0.dll
>   /usr/bin/cygcrypto-1.1.dll

So it's name is like the soname on Linux and others?  I'm guessing
only cygwin is doing that and other windows versions still use
things like libeay32.dll?

So engines build for 1.0.X can be loaded with any
"cygcrypto-1.0.0.dll"?

> When building engines, the engines are shared libs linking against the
> crypto DLL.  This creates a hard dependency to the DLL the engine has
> been linked against.  So, consider using an application linked against
> cygcrypto-1.1.dll.  It loads an engine built with and thus linked
> against cygcrypto-1.0.0.dll.  While the application will use functions
> from cygcrypto-1.1.dll, the engine will use functions from
> cygcrypto-1.0.0.dll.  Hilarity ensues.  Unless cygcrypto-1.0.0.dll has
> been deprecated and removed.  In which case loading the engine fails.
> 
> To decouple an engine from a DLL version, what we would have to do is
> to change the engines not to link against libcrypto, but rather to load
> *all* functions dynamically at runtime (dlload/dlsym(*)).  Only this
> would allow to decouple the engines from a specific versioned DLL.

Note that OSSL_DYNAMIC_OLDEST changed in 1.1.

Even if the engines for 1.1 were compatible with 1.0, we'd have
the same problem on Linux, it also knows to which soname it was
linked.


Kurt

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

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Corinna Vinschen 
On Jan 23 22:08, Richard Levitte wrote:
> In message <20160123202758.ga13...@calimero.vinschen.de> on Sat, 23 Jan 2016 
> 21:27:58 +0100, Corinna Vinschen  said:
> vinschen> Second, the build fails trying to compile crypto/cversion.c:
> vinschen> 
> vinschen> crypto/cversion.c:62:23: fatal error: buildinf.h: No such file or 
> directory
> vinschen>  # include "buildinf.h"
> vinschen>^
> vinschen> 
> vinschen> The reason is that buildinf.h can't be built because 
> util/mkbuildinf.pl
> vinschen> requires /usr/local/bin/perl rather than /usr/bin/perl:
> vinschen> 
> vinschen> diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl 
> src/openssl-1.1-rc1/util/mkbuildinf.pl
> vinschen> --- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl  2016-01-23 
> 21:02:18.386710976 +0100
> vinschen> +++ src/openssl-1.1-rc1/util/mkbuildinf.pl  2016-01-23 
> 21:15:19.705883094 +0100
> vinschen> @@ -1,4 +1,4 @@
> vinschen> -#!/usr/local/bin/perl
> vinschen> +#!/usr/bin/perl
> vinschen>  
> vinschen>  my ($cflags, $platform) = @ARGV;
> 
> Interesting...  Shouldn't the crypto/buildinf.h target have failed?

It didn't.  I just got the error message later with crypto/cversion.c.

> vinschen> Last but not least, we have another problem with enginesdir.  To 
> allow a
> vinschen> rolling release cycle, we have to support multiple versions of 
> openssl
> vinschen> in parallel.  The problem here is that the enginesdir needs to be
> vinschen> versioned to allow per-openssl version engines.  The build scripts 
> don't
> vinschen> allow for this.  Right now we're using a patch as the below one to 
> tweak
> vinschen> the configury to allow specifying the engines dir during build time.
> vinschen> Would it hurt terribly to include something like the below patch?
> vinschen> 
> vinschen> 
> vinschen> +++ src/openssl-1.1-rc1/Configure   2016-01-23 21:03:43.604076740 
> +0100
> vinschen> @@ -221,6 +221,7 @@ $config{prefix}="";
> vinschen>  $config{openssldir}="";
> vinschen>  $config{processor}="";
> vinschen>  $config{libdir}="";
> vinschen> +$config{enginesdir}="";
> vinschen>  $config{install_prefix}= "$ENV{'INSTALL_PREFIX'}";
> vinschen>  $config{cross_compile_prefix}="";
> vinschen>  $config{fipslibdir}="/usr/local/ssl/fips-2.0/lib/";
> vinschen> @@ -633,6 +634,10 @@ foreach (@argvcopy)
> vinschen> {
> vinschen> $config{libdir}=$1;
> vinschen> }
> vinschen> +   elsif (/^--enginesdir=(.*)$/)
> vinschen> +   {
> vinschen> +   $config{enginesdir}=$1;
> vinschen> +   }
> vinschen> elsif (/^--openssldir=(.*)$/)
> vinschen> {
> vinschen> $config{openssldir}=$1;
> vinschen> @@ -893,7 +898,7 @@ if ($target{build_file} eq "Makefile"
> vinschen>  $target{multilib}="" if !-d "$config{prefix}/lib$target{multilib}";
> vinschen>  
> vinschen>  $config{libdir}="lib$target{multilib}" if $config{libdir} eq "";
> vinschen> -$config{enginesdir}=$config{prefix} . "/" . $config{libdir}  . 
> "/engines";
> vinschen> +$config{enginesdir}=$config{prefix} . "/" . $config{libdir}  . 
> "/engines" if $config{enginesdir} eq "";
> vinschen>  
> vinschen>  push @{$config{defines}},
> vinschen>  map { (my $x = $_) =~ s/^OPENSSL_NO_/OPENSSL_EXPERIMENTAL_/; 
> $x }
> 
> Sure, that can be done.

Thanks!

> BTW, the refactor-build branch is a little off right now...  I have a
> bunch of fixes in my personal repo that haven't gone out there yet.
> Dunno if you've followed what's happening in master, but FYI, the
> refactor-build branch is starting to show up there, one little piece
> at a time (doing it that way made it easier for our review process).
> So right now, refactor-build is on pause until enough has come out on
> master.

Ok, no worries.  I'm quite busy with non-Cygwin stuff right now anyway
so I'm not concerned if this takes a bit more time :}


Corinna


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Richard Levitte 


Corinna Vinschen  skrev: (24 januari 2016 13:19:00 CET)
>On Jan 23 22:12, Richard Levitte wrote:
>> In message <20160123210116.gb13...@calimero.vinschen.de> on Sat, 23
>Jan 2016 22:01:16 +0100, Corinna Vinschen  said:
>> 
>> vinschen> On Jan 23 21:35, Kurt Roeckx wrote:
>> vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna
>Vinschen wrote:
>> vinschen> > > 
>> vinschen> > > Last but not least, we have another problem with
>enginesdir.  To allow a
>> vinschen> > > rolling release cycle, we have to support multiple
>versions of openssl
>> vinschen> > > in parallel.  The problem here is that the enginesdir
>needs to be
>> vinschen> > > versioned to allow per-openssl version engines.  The
>build scripts don't
>> vinschen> > > allow for this.  Right now we're using a patch as the
>below one to tweak
>> vinschen> > > the configury to allow specifying the engines dir
>during build time.
>> vinschen> > > Would it hurt terribly to include something like the
>below patch?
>> vinschen> > 
>> vinschen> > In general, I would like to have a directory for the
>engines that
>> vinschen> > relates to OSSL_DYNAMIC_OLDEST.
>> vinschen> 
>> vinschen> That probably won't work for Cygwin.  The engines are
>linked against the
>> vinschen> versioned DLLs of the OpenSSL version they have been built
>for,  Even
>> vinschen> assuming binary compatibility, an engine linked against
>openssl-1.0 will
>> vinschen> pull in openssl-1.0 DLLs, even when loaded from
>openssl-1.1.  We have to
>> vinschen> keep the engines separate.
>> 
>> This is interesting, actually.  OSSL_DYNAMIC_OLDEST has some design
>> around it that's meant to permit EXACTLY that kind of mixture.  It's
>> in the macro IMPLEMENT_DYNAMIC_BIND_FN.  However, it's possible it's
>> not doing enough, and figuring out what else it needs to do is a
>> venture I think is worth spending some time on.
>
>The problem here is Windows and how DLL dependencies are resolved.
>We're using versioned DLLs, e.g.
>
>  /usr/bin/cygcrypto-0.9.8.dll
>  /usr/bin/cygcrypto-1.0.0.dll
>  /usr/bin/cygcrypto-1.1.dll
>
>When building engines, the engines are shared libs linking against the
>crypto DLL.  This creates a hard dependency to the DLL the engine has
>been linked against.  So, consider using an application linked against
>cygcrypto-1.1.dll.  It loads an engine built with and thus linked
>against cygcrypto-1.0.0.dll.  While the application will use functions
>from cygcrypto-1.1.dll, the engine will use functions from
>cygcrypto-1.0.0.dll.

Yes, exactly. The way the engine API was designed from the start, that exact 
situation is meant to be supported. However, it's been long since I tested that 
aspect, so I can't personally tell if there's a bit of rot in there. That's 
certainly worth investigating... 

> Hilarity ensues.

Ok, so, a bit of rot or something other I fail to think of. Do you have details 
you'd like to share? 

> Unless cygcrypto-1.0.0.dll has
>been deprecated and removed.  In which case loading the engine fails.
>
>To decouple an engine from a DLL version, what we would have to do is
>to change the engines not to link against libcrypto, but rather to load
>*all* functions dynamically at runtime (dlload/dlsym(*)).  Only this
>would allow to decouple the engines from a specific versioned DLL.

The decoupling of versions is supposed to be between the loading application 
and the loaded engine, not between them and the libcrypto versions they each 
use. 

>
>
>Corinna
>
>
>(*) On Windows (but NOT Cygwin): LoadLibrary/GetProcAddress.
>
>
>
>
>___
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Corinna Vinschen 
On Jan 24 13:19, Corinna Vinschen wrote:
> On Jan 23 22:12, Richard Levitte wrote:
> > In message <20160123210116.gb13...@calimero.vinschen.de> on Sat, 23 Jan 
> > 2016 22:01:16 +0100, Corinna Vinschen  said:
> > 
> > vinschen> On Jan 23 21:35, Kurt Roeckx wrote:
> > vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen 
> > wrote:
> > vinschen> > > 
> > vinschen> > > Last but not least, we have another problem with enginesdir.  
> > To allow a
> > vinschen> > > rolling release cycle, we have to support multiple versions 
> > of openssl
> > vinschen> > > in parallel.  The problem here is that the enginesdir needs 
> > to be
> > vinschen> > > versioned to allow per-openssl version engines.  The build 
> > scripts don't
> > vinschen> > > allow for this.  Right now we're using a patch as the below 
> > one to tweak
> > vinschen> > > the configury to allow specifying the engines dir during 
> > build time.
> > vinschen> > > Would it hurt terribly to include something like the below 
> > patch?
> > vinschen> > 
> > vinschen> > In general, I would like to have a directory for the engines 
> > that
> > vinschen> > relates to OSSL_DYNAMIC_OLDEST.
> > vinschen> 
> > vinschen> That probably won't work for Cygwin.  The engines are linked 
> > against the
> > vinschen> versioned DLLs of the OpenSSL version they have been built for,  
> > Even
> > vinschen> assuming binary compatibility, an engine linked against 
> > openssl-1.0 will
> > vinschen> pull in openssl-1.0 DLLs, even when loaded from openssl-1.1.  We 
> > have to
> > vinschen> keep the engines separate.
> > 
> > This is interesting, actually.  OSSL_DYNAMIC_OLDEST has some design
> > around it that's meant to permit EXACTLY that kind of mixture.  It's
> > in the macro IMPLEMENT_DYNAMIC_BIND_FN.  However, it's possible it's
> > not doing enough, and figuring out what else it needs to do is a
> > venture I think is worth spending some time on.
> 
> The problem here is Windows and how DLL dependencies are resolved.
> We're using versioned DLLs, e.g.
> 
>   /usr/bin/cygcrypto-0.9.8.dll
>   /usr/bin/cygcrypto-1.0.0.dll
>   /usr/bin/cygcrypto-1.1.dll
> 
> When building engines, the engines are shared libs linking against the
> crypto DLL.  This creates a hard dependency to the DLL the engine has
> been linked against.  So, consider using an application linked against
> cygcrypto-1.1.dll.  It loads an engine built with and thus linked
> against cygcrypto-1.0.0.dll.  While the application will use functions
> from cygcrypto-1.1.dll, the engine will use functions from
> cygcrypto-1.0.0.dll.  Hilarity ensues.  Unless cygcrypto-1.0.0.dll has
> been deprecated and removed.  In which case loading the engine fails.
> 
> To decouple an engine from a DLL version, what we would have to do is
> to change the engines not to link against libcrypto, but rather to load
> *all* functions dynamically at runtime (dlload/dlsym(*)).

...in conjunction with symlinks, e.g.

  dlload ("/usr/lib/libcrypto.so", ...)

with /usr/lib/libcrypto.so being a symlink to the latest DLL:

  /usr/lib/libcrypto.so -> /usr/bin/cygcrypto-1.1.dll


Corinna


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Corinna Vinschen 
On Jan 24 14:41, Richard Levitte wrote:
> Corinna Vinschen  skrev: (24 januari 2016 13:19:00 CET)
> >On Jan 23 22:12, Richard Levitte wrote:
> >> This is interesting, actually.  OSSL_DYNAMIC_OLDEST has some design
> >> around it that's meant to permit EXACTLY that kind of mixture.  It's
> >> in the macro IMPLEMENT_DYNAMIC_BIND_FN.  However, it's possible it's
> >> not doing enough, and figuring out what else it needs to do is a
> >> venture I think is worth spending some time on.
> >
> >The problem here is Windows and how DLL dependencies are resolved.
> >We're using versioned DLLs, e.g.
> >
> >  /usr/bin/cygcrypto-0.9.8.dll
> >  /usr/bin/cygcrypto-1.0.0.dll
> >  /usr/bin/cygcrypto-1.1.dll
> >
> >When building engines, the engines are shared libs linking against the
> >crypto DLL.  This creates a hard dependency to the DLL the engine has
> >been linked against.  So, consider using an application linked against
> >cygcrypto-1.1.dll.  It loads an engine built with and thus linked
> >against cygcrypto-1.0.0.dll.  While the application will use functions
> >from cygcrypto-1.1.dll, the engine will use functions from
> >cygcrypto-1.0.0.dll.
> 
> Yes, exactly. The way the engine API was designed from the start, that
> exact situation is meant to be supported. However, it's been long
> since I tested that aspect, so I can't personally tell if there's a
> bit of rot in there. That's certainly worth investigating... 
> 
> > Hilarity ensues.
> 
> Ok, so, a bit of rot or something other I fail to think of. Do you
> have details you'd like to share? 

No, that was only an attempt at humor.  I don't know either if that
works as desired...

> > Unless cygcrypto-1.0.0.dll has
> >been deprecated and removed.  In which case loading the engine fails.
> >
> >To decouple an engine from a DLL version, what we would have to do is
> >to change the engines not to link against libcrypto, but rather to load
> >*all* functions dynamically at runtime (dlload/dlsym(*)).  Only this
> >would allow to decouple the engines from a specific versioned DLL.
> 
> The decoupling of versions is supposed to be between the loading
> application and the loaded engine, not between them and the libcrypto
> versions they each use.

Hmm, ok.  I thought that it's not desired to run an application with one
crypto lib and the engine with another.  I can't exactly judge the
implications, but that sounds like it could result in problems, not only
on Cygwin, FWIW.  Is there any shared data between the calling crypto
lib and the engine?  What if the idea how to handle this shared data is
different between the crypto lib *calling* the engine and the crypto lib
*called* by the engine?

Still, the immediate problem is that a rolling release distro has to
keep two sets of engines depending on the OpenSSL release to support
existing packages until they have been rebuilt.  The other issues
is stuff you can judge much better than me,


Thanks,
Corinna


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Corinna Vinschen 
On Jan 24 14:35, Kurt Roeckx wrote:
> On Sun, Jan 24, 2016 at 01:19:00PM +0100, Corinna Vinschen wrote:
> > On Jan 23 22:12, Richard Levitte wrote:
> > > This is interesting, actually.  OSSL_DYNAMIC_OLDEST has some design
> > > around it that's meant to permit EXACTLY that kind of mixture.  It's
> > > in the macro IMPLEMENT_DYNAMIC_BIND_FN.  However, it's possible it's
> > > not doing enough, and figuring out what else it needs to do is a
> > > venture I think is worth spending some time on.
> > 
> > The problem here is Windows and how DLL dependencies are resolved.
> > We're using versioned DLLs, e.g.
> > 
> >   /usr/bin/cygcrypto-0.9.8.dll
> >   /usr/bin/cygcrypto-1.0.0.dll
> >   /usr/bin/cygcrypto-1.1.dll
> 
> So it's name is like the soname on Linux and others?  I'm guessing
> only cygwin is doing that and other windows versions still use
> things like libeay32.dll?

Yes, exactly.  Cygwin is much more trying to be like a Linux distro on
top of Windows.  This includes how we handle shared libs, within the
bounds of [history and] what can be done under Windows, of course.

> So engines build for 1.0.X can be loaded with any
> "cygcrypto-1.0.0.dll"?

Yep.

> > When building engines, the engines are shared libs linking against the
> > crypto DLL.  This creates a hard dependency to the DLL the engine has
> > been linked against.  So, consider using an application linked against
> > cygcrypto-1.1.dll.  It loads an engine built with and thus linked
> > against cygcrypto-1.0.0.dll.  While the application will use functions
> > from cygcrypto-1.1.dll, the engine will use functions from
> > cygcrypto-1.0.0.dll.  Hilarity ensues.  Unless cygcrypto-1.0.0.dll has
> > been deprecated and removed.  In which case loading the engine fails.
> > 
> > To decouple an engine from a DLL version, what we would have to do is
> > to change the engines not to link against libcrypto, but rather to load
> > *all* functions dynamically at runtime (dlload/dlsym(*)).  Only this
> > would allow to decouple the engines from a specific versioned DLL.
> 
> Note that OSSL_DYNAMIC_OLDEST changed in 1.1.
> 
> Even if the engines for 1.1 were compatible with 1.0, we'd have
> the same problem on Linux, it also knows to which soname it was
> linked.

Ah, good to know.


Thanks,
Corinna


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Richard Levitte 


On January 24, 2016 3:52:19 PM GMT+01:00, Corinna Vinschen 
 wrote:
>On Jan 24 14:41, Richard Levitte wrote:
>> Corinna Vinschen  skrev: (24 januari 2016
>13:19:00 CET)
>> >On Jan 23 22:12, Richard Levitte wrote:
>> >> This is interesting, actually.  OSSL_DYNAMIC_OLDEST has some
>design
>> >> around it that's meant to permit EXACTLY that kind of mixture. 
>It's
>> >> in the macro IMPLEMENT_DYNAMIC_BIND_FN.  However, it's possible
>it's
>> >> not doing enough, and figuring out what else it needs to do is a
>> >> venture I think is worth spending some time on.
>> >
>> >The problem here is Windows and how DLL dependencies are resolved.
>> >We're using versioned DLLs, e.g.
>> >
>> >  /usr/bin/cygcrypto-0.9.8.dll
>> >  /usr/bin/cygcrypto-1.0.0.dll
>> >  /usr/bin/cygcrypto-1.1.dll
>> >
>> >When building engines, the engines are shared libs linking against
>the
>> >crypto DLL.  This creates a hard dependency to the DLL the engine
>has
>> >been linked against.  So, consider using an application linked
>against
>> >cygcrypto-1.1.dll.  It loads an engine built with and thus linked
>> >against cygcrypto-1.0.0.dll.  While the application will use
>functions
>> >from cygcrypto-1.1.dll, the engine will use functions from
>> >cygcrypto-1.0.0.dll.
>> 
>> Yes, exactly. The way the engine API was designed from the start,
>that
>> exact situation is meant to be supported. However, it's been long
>> since I tested that aspect, so I can't personally tell if there's a
>> bit of rot in there. That's certainly worth investigating... 
>> 
>> > Hilarity ensues.
>> 
>> Ok, so, a bit of rot or something other I fail to think of. Do you
>> have details you'd like to share? 
>
>No, that was only an attempt at humor.  I don't know either if that
>works as desired...
>
>> > Unless cygcrypto-1.0.0.dll has
>> >been deprecated and removed.  In which case loading the engine
>fails.
>> >
>> >To decouple an engine from a DLL version, what we would have to do
>is
>> >to change the engines not to link against libcrypto, but rather to
>load
>> >*all* functions dynamically at runtime (dlload/dlsym(*)).  Only this
>> >would allow to decouple the engines from a specific versioned DLL.
>> 
>> The decoupling of versions is supposed to be between the loading
>> application and the loaded engine, not between them and the libcrypto
>> versions they each use.
>
>Hmm, ok.  I thought that it's not desired to run an application with
>one
>crypto lib and the engine with another.  I can't exactly judge the
>implications, but that sounds like it could result in problems, not
>only
>on Cygwin, FWIW.  Is there any shared data between the calling crypto
>lib and the engine?  What if the idea how to handle this shared data is
>different between the crypto lib *calling* the engine and the crypto
>lib
>*called* by the engine?

They aren't supposed to share data, except for a few things, such as the heap. 
That's why heap handling hooks are passed when binding an engine, among a few 
other things... 

>Still, the immediate problem is that a rolling release distro has to
>keep two sets of engines depending on the OpenSSL release to support
>existing packages until they have been rebuilt.  The other issues
>is stuff you can judge much better than me,
>
>
>Thanks,
>Corinna
>
>
>
>
>___
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
levi...@openssl.org 
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Richard Levitte 
In message  on Sun, 24 Jan 2016 
12:36:29 -0800, Quanah Gibson-Mount  said:

quanah> --On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte
quanah> -- wrote:
quanah> 
quanah> >> A more portable fix would be
quanah> >># !/usr/bin/env perl
quanah> >
quanah> > Yes. Thanks for the reminder.
quanah> 
quanah> Hm, we did that in some script in Zimbra, and it ended up causing
quanah> segfaults on RHEL systems that were pulling in a different perl than
quanah> the system perl. I'll see if I can track down exactly what the issue
quanah> was.

Sounds like crappy $PATH...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Quanah Gibson-Mount 
--On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte 
 wrote:



A more portable fix would be
# !/usr/bin/env perl


Yes. Thanks for the reminder.


Hm, we did that in some script in Zimbra, and it ended up causing segfaults 
on RHEL systems that were pulling in a different perl than the system perl. 
I'll see if I can track down exactly what the issue was.


--Quanah


--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Quanah Gibson-Mount 
--On Sunday, January 24, 2016 11:30 PM +0100 Richard Levitte 
 wrote:



In message  on Sun, 24 Jan 2016
12:36:29 -0800, Quanah Gibson-Mount  said:

quanah> --On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte
quanah> -- wrote:
quanah>
quanah> >> A more portable fix would be
quanah> >># !/usr/bin/env perl
quanah> >
quanah> > Yes. Thanks for the reminder.
quanah>
quanah> Hm, we did that in some script in Zimbra, and it ended up causing
quanah> segfaults on RHEL systems that were pulling in a different perl
than quanah> the system perl. I'll see if I can track down exactly what
the issue quanah> was.

Sounds like crappy $PATH...


Actually it was Ubuntu rather than RHEL.  Unfortuantely, beyond that, we're 
lacking on details, other than it was a perl found in /usr/local/bin.


--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.

Zimbra ::  the leader in open source messaging and collaboration
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-24 Thread Richard Levitte 
In message  on Sun, 24 Jan 2016 
14:45:13 -0800, Quanah Gibson-Mount  said:

quanah> --On Sunday, January 24, 2016 11:30 PM +0100 Richard Levitte
quanah> -- wrote:
quanah> 
quanah> > In message  on Sun, 24 Jan
quanah> > 2016
quanah> > 12:36:29 -0800, Quanah Gibson-Mount  said:
quanah> >
quanah> > quanah> --On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte
quanah> > quanah> -- wrote:
quanah> > quanah>
quanah> > quanah> >> A more portable fix would be
quanah> > quanah> >># !/usr/bin/env perl
quanah> > quanah> >
quanah> > quanah> > Yes. Thanks for the reminder.
quanah> > quanah>
quanah> > quanah> Hm, we did that in some script in Zimbra, and it ended up
quanah> > causing
quanah> > quanah> segfaults on RHEL systems that were pulling in a different
quanah> > perl
quanah> > than quanah> the system perl. I'll see if I can track down exactly
quanah> > what
quanah> > the issue quanah> was.
quanah> >
quanah> > Sounds like crappy $PATH...
quanah> 
quanah> Actually it was Ubuntu rather than RHEL.  Unfortuantely, beyond that,
quanah> we're lacking on details, other than it was a perl found in
quanah> /usr/local/bin.

Ok, so I take it someone had made a local build and installation of
perl and forgot to clear it out when the perl package was installed.
That *ahem* happens to me at times.  That's nothing the OpenSSL build
can have any control over, or env.

Generally speaking, '#!/usr/bin/env perl' is the right thing to do,
really.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-23 Thread Richard Levitte 
In message <20160123202758.ga13...@calimero.vinschen.de> on Sat, 23 Jan 2016 
21:27:58 +0100, Corinna Vinschen  said:

vinschen> Hi Richard,
vinschen> 
vinschen> On Jan 18 23:50, Richard Levitte wrote:
vinschen> > FYI,
vinschen> > 
vinschen> > The branch has been updated, the Makfile template now has install
vinschen> > targets as well, and I did the mods I could see would be necessary 
for
vinschen> > Cygwin and Mingw.  I would appreciate it if someone could help me 
try
vinschen> > those out.
vinschen> > 
vinschen> > Remember to configure with --unified.
vinschen> 
vinschen> I tested this on 64 bit Cygwin and stumbled over a minor and a major
vinschen> problem.  First, there's a typo in crypto/bn/Makefile.in, using eight
vinschen> spaces rather than a TAB:
vinschen> 
vinschen> 
vinschen> diff -upr origsrc/openssl-1.1-rc1/crypto/bn/Makefile.in 
src/openssl-1.1-rc1/crypto/bn/Makefile.in
vinschen> --- origsrc/openssl-1.1-rc1/crypto/bn/Makefile.in 2016-01-23 
21:02:12.604753995 +0100
vinschen> +++ src/openssl-1.1-rc1/crypto/bn/Makefile.in 2016-01-23 
21:03:58.394966621 +0100
vinschen> @@ -161,6 +161,6 @@ clean:
vinschen>  
vinschen>  # Different flavours of make disagree on where output goes
vinschen>  .c.o:
vinschen> -$(CC) $(CFLAGS) -c $< -o $@
vinschen> + $(CC) $(CFLAGS) -c $< -o $@

Ah hah!  I wonder why my make hasn't complained?

vinschen> Second, the build fails trying to compile crypto/cversion.c:
vinschen> 
vinschen> crypto/cversion.c:62:23: fatal error: buildinf.h: No such file or 
directory
vinschen>  # include "buildinf.h"
vinschen>^
vinschen> 
vinschen> The reason is that buildinf.h can't be built because 
util/mkbuildinf.pl
vinschen> requires /usr/local/bin/perl rather than /usr/bin/perl:
vinschen> 
vinschen> diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl 
src/openssl-1.1-rc1/util/mkbuildinf.pl
vinschen> --- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl2016-01-23 
21:02:18.386710976 +0100
vinschen> +++ src/openssl-1.1-rc1/util/mkbuildinf.pl2016-01-23 
21:15:19.705883094 +0100
vinschen> @@ -1,4 +1,4 @@
vinschen> -#!/usr/local/bin/perl
vinschen> +#!/usr/bin/perl
vinschen>  
vinschen>  my ($cflags, $platform) = @ARGV;

Interesting...  Shouldn't the crypto/buildinf.h target have failed?

vinschen> The build eventually fails with the following error message, which I
vinschen> don't quite understand.  The libraries should have been built before
vinschen> trying to build the engines due to hard dependencies, but for some
vinschen> reason they aren't.  Sorry, I have no fix for that :(

I do.  Don't remember the details this moment, but that did happen to
me as well, and I recall figuring out what went on.

vinschen> Last but not least, we have another problem with enginesdir.  To 
allow a
vinschen> rolling release cycle, we have to support multiple versions of openssl
vinschen> in parallel.  The problem here is that the enginesdir needs to be
vinschen> versioned to allow per-openssl version engines.  The build scripts 
don't
vinschen> allow for this.  Right now we're using a patch as the below one to 
tweak
vinschen> the configury to allow specifying the engines dir during build time.
vinschen> Would it hurt terribly to include something like the below patch?
vinschen> 
vinschen> 
vinschen> +++ src/openssl-1.1-rc1/Configure 2016-01-23 21:03:43.604076740 
+0100
vinschen> @@ -221,6 +221,7 @@ $config{prefix}="";
vinschen>  $config{openssldir}="";
vinschen>  $config{processor}="";
vinschen>  $config{libdir}="";
vinschen> +$config{enginesdir}="";
vinschen>  $config{install_prefix}= "$ENV{'INSTALL_PREFIX'}";
vinschen>  $config{cross_compile_prefix}="";
vinschen>  $config{fipslibdir}="/usr/local/ssl/fips-2.0/lib/";
vinschen> @@ -633,6 +634,10 @@ foreach (@argvcopy)
vinschen>   {
vinschen>   $config{libdir}=$1;
vinschen>   }
vinschen> + elsif (/^--enginesdir=(.*)$/)
vinschen> + {
vinschen> + $config{enginesdir}=$1;
vinschen> + }
vinschen>   elsif (/^--openssldir=(.*)$/)
vinschen>   {
vinschen>   $config{openssldir}=$1;
vinschen> @@ -893,7 +898,7 @@ if ($target{build_file} eq "Makefile"
vinschen>  $target{multilib}="" if !-d "$config{prefix}/lib$target{multilib}";
vinschen>  
vinschen>  $config{libdir}="lib$target{multilib}" if $config{libdir} eq "";
vinschen> -$config{enginesdir}=$config{prefix} . "/" . $config{libdir}  . 
"/engines";
vinschen> +$config{enginesdir}=$config{prefix} . "/" . $config{libdir}  . 
"/engines" if $config{enginesdir} eq "";
vinschen>  
vinschen>  push @{$config{defines}},
vinschen>  map { (my $x = $_) =~ s/^OPENSSL_NO_/OPENSSL_EXPERIMENTAL_/; $x }

Sure, that can be done.

BTW, the refactor-build branch is a little off right now...  I have a
bunch of fixes in my personal repo that haven't gone out there yet.
Dunno if

Re: [openssl-dev] Upcoming build system change

2016-01-23 Thread Corinna Vinschen 
Hi Richard,

On Jan 18 23:50, Richard Levitte wrote:
> FYI,
> 
> The branch has been updated, the Makfile template now has install
> targets as well, and I did the mods I could see would be necessary for
> Cygwin and Mingw.  I would appreciate it if someone could help me try
> those out.
> 
> Remember to configure with --unified.

I tested this on 64 bit Cygwin and stumbled over a minor and a major
problem.  First, there's a typo in crypto/bn/Makefile.in, using eight
spaces rather than a TAB:


diff -upr origsrc/openssl-1.1-rc1/crypto/bn/Makefile.in 
src/openssl-1.1-rc1/crypto/bn/Makefile.in
--- origsrc/openssl-1.1-rc1/crypto/bn/Makefile.in   2016-01-23 
21:02:12.604753995 +0100
+++ src/openssl-1.1-rc1/crypto/bn/Makefile.in   2016-01-23 21:03:58.394966621 
+0100
@@ -161,6 +161,6 @@ clean:
 
 # Different flavours of make disagree on where output goes
 .c.o:
-$(CC) $(CFLAGS) -c $< -o $@
+   $(CC) $(CFLAGS) -c $< -o $@
 
 # DO NOT DELETE THIS LINE -- make depend depends on it.


Second, the build fails trying to compile crypto/cversion.c:

crypto/cversion.c:62:23: fatal error: buildinf.h: No such file or directory
 # include "buildinf.h"
   ^

The reason is that buildinf.h can't be built because util/mkbuildinf.pl
requires /usr/local/bin/perl rather than /usr/bin/perl:

diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl 
src/openssl-1.1-rc1/util/mkbuildinf.pl
--- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl  2016-01-23 21:02:18.386710976 
+0100
+++ src/openssl-1.1-rc1/util/mkbuildinf.pl  2016-01-23 21:15:19.705883094 
+0100
@@ -1,4 +1,4 @@
-#!/usr/local/bin/perl
+#!/usr/bin/perl
 
 my ($cflags, $platform) = @ARGV;


The build eventually fails with the following error message, which I
don't quite understand.  The libraries should have been built before
trying to build the engines due to hard dependencies, but for some
reason they aren't.  Sorry, I have no fix for that :(

Last but not least, we have another problem with enginesdir.  To allow a
rolling release cycle, we have to support multiple versions of openssl
in parallel.  The problem here is that the enginesdir needs to be
versioned to allow per-openssl version engines.  The build scripts don't
allow for this.  Right now we're using a patch as the below one to tweak
the configury to allow specifying the engines dir during build time.
Would it hurt terribly to include something like the below patch?


+++ src/openssl-1.1-rc1/Configure   2016-01-23 21:03:43.604076740 +0100
@@ -221,6 +221,7 @@ $config{prefix}="";
 $config{openssldir}="";
 $config{processor}="";
 $config{libdir}="";
+$config{enginesdir}="";
 $config{install_prefix}= "$ENV{'INSTALL_PREFIX'}";
 $config{cross_compile_prefix}="";
 $config{fipslibdir}="/usr/local/ssl/fips-2.0/lib/";
@@ -633,6 +634,10 @@ foreach (@argvcopy)
{
$config{libdir}=$1;
}
+   elsif (/^--enginesdir=(.*)$/)
+   {
+   $config{enginesdir}=$1;
+   }
elsif (/^--openssldir=(.*)$/)
{
$config{openssldir}=$1;
@@ -893,7 +898,7 @@ if ($target{build_file} eq "Makefile"
 $target{multilib}="" if !-d "$config{prefix}/lib$target{multilib}";
 
 $config{libdir}="lib$target{multilib}" if $config{libdir} eq "";
-$config{enginesdir}=$config{prefix} . "/" . $config{libdir}  . "/engines";
+$config{enginesdir}=$config{prefix} . "/" . $config{libdir}  . "/engines" if 
$config{enginesdir} eq "";
 
 push @{$config{defines}},
 map { (my $x = $_) =~ s/^OPENSSL_NO_/OPENSSL_EXPERIMENTAL_/; $x }


Thanks,
Corinna


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-23 Thread Kurt Roeckx 
On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote:
> 
> Last but not least, we have another problem with enginesdir.  To allow a
> rolling release cycle, we have to support multiple versions of openssl
> in parallel.  The problem here is that the enginesdir needs to be
> versioned to allow per-openssl version engines.  The build scripts don't
> allow for this.  Right now we're using a patch as the below one to tweak
> the configury to allow specifying the engines dir during build time.
> Would it hurt terribly to include something like the below patch?

In general, I would like to have a directory for the engines that
relates to OSSL_DYNAMIC_OLDEST.


Kurt

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

Re: [openssl-dev] Upcoming build system change

2016-01-23 Thread Kurt Roeckx 
On Sat, Jan 23, 2016 at 10:01:16PM +0100, Corinna Vinschen wrote:
> On Jan 23 21:35, Kurt Roeckx wrote:
> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote:
> > > 
> > > Last but not least, we have another problem with enginesdir.  To allow a
> > > rolling release cycle, we have to support multiple versions of openssl
> > > in parallel.  The problem here is that the enginesdir needs to be
> > > versioned to allow per-openssl version engines.  The build scripts don't
> > > allow for this.  Right now we're using a patch as the below one to tweak
> > > the configury to allow specifying the engines dir during build time.
> > > Would it hurt terribly to include something like the below patch?
> > 
> > In general, I would like to have a directory for the engines that
> > relates to OSSL_DYNAMIC_OLDEST.
> 
> That probably won't work for Cygwin.  The engines are linked against the
> versioned DLLs of the OpenSSL version they have been built for,  Even
> assuming binary compatibility, an engine linked against openssl-1.0 will
> pull in openssl-1.0 DLLs, even when loaded from openssl-1.1.  We have to
> keep the engines separate.

How does that work on cygwin?


Kurt

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

Re: [openssl-dev] Upcoming build system change

2016-01-23 Thread Tim Rice 
On Sat, 23 Jan 2016, Corinna Vinschen wrote:

> diff -upr origsrc/openssl-1.1-rc1/util/mkbuildinf.pl 
> src/openssl-1.1-rc1/util/mkbuildinf.pl
> --- origsrc/openssl-1.1-rc1/util/mkbuildinf.pl2016-01-23 
> 21:02:18.386710976 +0100
> +++ src/openssl-1.1-rc1/util/mkbuildinf.pl2016-01-23 21:15:19.705883094 
> +0100
> @@ -1,4 +1,4 @@
> -#!/usr/local/bin/perl
> +#!/usr/bin/perl

A more portable fix would be
#!/usr/bin/env perl


-- 
Tim RiceMultitalents(707) 456-1146
t...@multitalents.net


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

Re: [openssl-dev] Upcoming build system change

2016-01-23 Thread Corinna Vinschen 
On Jan 23 21:35, Kurt Roeckx wrote:
> On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote:
> > 
> > Last but not least, we have another problem with enginesdir.  To allow a
> > rolling release cycle, we have to support multiple versions of openssl
> > in parallel.  The problem here is that the enginesdir needs to be
> > versioned to allow per-openssl version engines.  The build scripts don't
> > allow for this.  Right now we're using a patch as the below one to tweak
> > the configury to allow specifying the engines dir during build time.
> > Would it hurt terribly to include something like the below patch?
> 
> In general, I would like to have a directory for the engines that
> relates to OSSL_DYNAMIC_OLDEST.

That probably won't work for Cygwin.  The engines are linked against the
versioned DLLs of the OpenSSL version they have been built for,  Even
assuming binary compatibility, an engine linked against openssl-1.0 will
pull in openssl-1.0 DLLs, even when loaded from openssl-1.1.  We have to
keep the engines separate.


Corinna


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-23 Thread Richard Levitte 
In message <20160123210116.gb13...@calimero.vinschen.de> on Sat, 23 Jan 2016 
22:01:16 +0100, Corinna Vinschen  said:

vinschen> On Jan 23 21:35, Kurt Roeckx wrote:
vinschen> > On Sat, Jan 23, 2016 at 09:27:58PM +0100, Corinna Vinschen wrote:
vinschen> > > 
vinschen> > > Last but not least, we have another problem with enginesdir.  To 
allow a
vinschen> > > rolling release cycle, we have to support multiple versions of 
openssl
vinschen> > > in parallel.  The problem here is that the enginesdir needs to be
vinschen> > > versioned to allow per-openssl version engines.  The build 
scripts don't
vinschen> > > allow for this.  Right now we're using a patch as the below one 
to tweak
vinschen> > > the configury to allow specifying the engines dir during build 
time.
vinschen> > > Would it hurt terribly to include something like the below patch?
vinschen> > 
vinschen> > In general, I would like to have a directory for the engines that
vinschen> > relates to OSSL_DYNAMIC_OLDEST.
vinschen> 
vinschen> That probably won't work for Cygwin.  The engines are linked against 
the
vinschen> versioned DLLs of the OpenSSL version they have been built for,  Even
vinschen> assuming binary compatibility, an engine linked against openssl-1.0 
will
vinschen> pull in openssl-1.0 DLLs, even when loaded from openssl-1.1.  We have 
to
vinschen> keep the engines separate.

This is interesting, actually.  OSSL_DYNAMIC_OLDEST has some design
around it that's meant to permit EXACTLY that kind of mixture.  It's
in the macro IMPLEMENT_DYNAMIC_BIND_FN.  However, it's possible it's
not doing enough, and figuring out what else it needs to do is a
venture I think is worth spending some time on.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-18 Thread Richard Levitte 
FYI,

The branch has been updated, the Makfile template now has install
targets as well, and I did the mods I could see would be necessary for
Cygwin and Mingw.  I would appreciate it if someone could help me try
those out.

Remember to configure with --unified.

Next thing coming up is install targets on VMS.  And with that, I have
to rethink the defaults for the installation directories.

Cheers,
Richard

In message <20160114.215903.813205413779228431.levi...@openssl.org> on Thu, 14 
Jan 2016 21:59:03 +0100 (CET), Richard Levitte  said:

levitte> Hi,
levitte> 
levitte> there's an effort going on to revamp the build system for future
levitte> OpenSSL, coining it as "unified".  The intention is to have one and
levitte> the same base of information for all platforms, instead of having to
levitte> maintain one set of files for Unixly platforms, one makefile generator
levitte> for Windowsy platforms, and one pile of scripts with a serious case of
levitte> bit rot for VMS.
levitte> 
levitte> In particular, this is of interest for the VMS folks, as it's the only
levitte> currently workable build system for upcoming version 1.1.
levitte> 
levitte> 
levitte> Finding it
levitte> ==
levitte> 
levitte> For now, this change is available on here:
levitte> 
levitte> https://github.com/levitte/openssl/tree/refactor-build
levitte> 
levitte> which is git repo https://github.com/levitte/openssl.git, branch
levitte> refactor-build.
levitte> 
levitte> 
levitte> Using it
levitte> 
levitte> 
levitte> Requirements
levitte> 
levitte> 
levitte> On all platforms, it requires
levitte> 
levitte> - Perl!  Reports tell me that version 5.10.1 works fine but might need
levitte>   some extra perl modules (Test::More and possibly others.  Feedback
levitte>   welcome!).  Unix usually has it installed or easy to find.  For VMS,
levitte>   there's an install kit on sourceforge
levitte>   (https://sourceforge.net/projects/vmsperlkit/files/Archive/), and
levitte>   Windows, we've always recommended ActiveState Perl
levitte>   (http://www.activestate.com/ActivePerl).
levitte> - The Perl module Text::Template, which is the driver behind the
levitte>   generation Makefile and other files.  This branch relies quite
levitte>   heavily on templates.
levitte> 
levitte> On Unix, it requires
levitte> 
levitte> - the usual developmemt stuff.  cc, as and make would be the really
levitte>   bare minimum, and maybe I'm forgetting something, but what is
levitte>   usually considered the normal tool chain should work out.
levitte> 
levitte> On VMS, it requires
levitte> 
levitte> - DEC C...  It's called HP C these days and might be called something
levitte>   else again when VSI starts shipping.  It needs to be recent enough
levitte>   to support the qualifiers /NAMES=(AS_IS,SHORTENED) and /REPOSITORY
levitte>   (I welcome feedback on which the minimum version for this is!)
levitte> - DECset, at the very least MMS.  Alternatively, MMK can be used if
levitte>   you can find it (if anyone knows of a place that has it for sure,
levitte>   feedback is welcome!)
levitte> - Of course, the rest of the tool chain, but that comes with the
levitte>   operating system, no worries there.
levitte> 
levitte> [I certainly hope I didn't forget anything, but if I did, feedback is
levitte> welcome!]
levitte> 
levitte> Config and build
levitte> 
levitte> 
levitte> For Unix users, who are used to the usual generation of a top Makefile
levitte> from Makefile.org...  that is, Makefile.in since recently, this it
levitte> still the default, but you can always use the unified build as an
levitte> alternative by adding the flag --unified, like so:
levitte> 
levitte> ./config --unified
levitte> make
levitte> make test
levitte> # There is no install target yet, it's coming up!
levitte> 
levitte> You will get One Top Makefile that does everything.  It will not touch
levitte> any other Makefile.
levitte> 
levitte> 
levitte> For VMS users, the unified build is the only one available in this
levitte> branch, the old scripts are simply gone.  Instead, you configure just
levitte> like you would on any other platform (well, almost, there isn't any
levitte> config.com yet, so you'll have to jump directly to the Configure
levitte> script), and that will generate a descrip.mms:
levitte> 
levitte> perl Configure vms-alpha   ! or vms-ia64
levitte> mms
levitte> mms test
levitte> ! There is no install target yet.
levitte> ! As a matter of fact, I'd like to talk about exactly where it
levitte> ! should install.  Let's talk!
levitte> 
levitte> 
levitte> Features
levitte> 
levitte> 
levitte> There are a few features in the unified build that are worth testing:
levitte> 
levitte> 1. Out of source tree builds!  It's perfectly possible to do this:
levitte> 
levitte> mkdir ../build
levitte> cd ../build
levitte> perl ../openssl-src/config
levitte> make
levitte> make test

Re: [openssl-dev] Upcoming build system change

2016-01-17 Thread Corinna Vinschen 
On Jan 17 18:33, Richard Levitte wrote:
> In message <20160117172014.gc16...@calimero.vinschen.de> on Sun, 17 Jan 2016 
> 18:20:14 +0100, Corinna Vinschen  said:
> 
> vinschen> On Jan 17 18:13, Corinna Vinschen wrote:
> vinschen> > On Jan 17 17:50, Richard Levitte wrote:
> vinschen> > > In message <20160117154353.gc9...@calimero.vinschen.de> on Sun, 
> 17 Jan 2016 16:43:53 +0100, Corinna Vinschen  said:
> vinschen> > > 
> vinschen> > > vinschen> On Jan 17 01:04, Richard Levitte wrote:
> vinschen> > > vinschen> > If you have a look in "config", it doesn't generate 
> "Cygwin-x86_64" at
> vinschen> > > vinschen> > all.  Would you be willing to have a look at that 
> script and modernise
> vinschen> > > vinschen> > it regarding Cygwin?
> vinschen> > > vinschen> 
> vinschen> > > vinschen> Like the attached?
> vinschen> > > 
> vinschen> > > Thank you, that helped...  it was less traumatic than I 
> imagined ;-)
> vinschen> > > I've attached a small fixup, your thoughts?
> vinschen> > 
> vinschen> > Well, that works, too.  But if we ever support another 
> architecture,
> vinschen> > we'd have to tweak two files, config and 10-main.conf, rather 
> then just
> vinschen> > one, 10-main.conf.
> vinschen> 
> vinschen> Btw., when calling Configure rather than config, i686 would be 
> simpler
> vinschen> for the package builder since it could just use the build variable
> vinschen> ${ARCH}, rather than having to check and explicitely turn this to 
> "x86".
> vinschen> 
> vinschen> 
> vinschen> Just saying...
> 
> I was just thinking of that, as well as a backward compatibility name
> Cygwin.

Looks good to me, as discussed in PM.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-17 Thread Richard Levitte 
In message <20160117154353.gc9...@calimero.vinschen.de> on Sun, 17 Jan 2016 
16:43:53 +0100, Corinna Vinschen  said:

vinschen> On Jan 17 01:04, Richard Levitte wrote:
vinschen> > If you have a look in "config", it doesn't generate "Cygwin-x86_64" 
at
vinschen> > all.  Would you be willing to have a look at that script and 
modernise
vinschen> > it regarding Cygwin?
vinschen> 
vinschen> Like the attached?

Thank you, that helped...  it was less traumatic than I imagined ;-)
I've attached a small fixup, your thoughts?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
>From 3551960614f451350b791182f423284a2be6f389 Mon Sep 17 00:00:00 2001
From: Richard Levitte 
Date: Sun, 17 Jan 2016 17:48:53 +0100
Subject: [PATCH] FIXUP to adjust names and include i[345]86

---
 Configurations/10-main.conf | 2 +-
 config  | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
index b1528c1..479bc58 100644
--- a/Configurations/10-main.conf
+++ b/Configurations/10-main.conf
@@ -1221,7 +1221,7 @@
 },
 
  Cygwin
-"Cygwin-i686" => {
+"Cygwin-x86" => {
 inherit_from => [ asm("x86_asm") ],
 cc   => "gcc",
 cflags   => "-DTERMIOS -DL_ENDIAN -Wall",
diff --git a/config b/config
index 6f8ee91..f962dce 100755
--- a/config
+++ b/config
@@ -806,7 +806,8 @@ case "$GUESSOS" in
 	fi
 	;;
   # these are all covered by the catchall below
-  *-*-cygwin) OUT="Cygwin-${MACHINE}" ;;
+  x86_64-pc-cygwin) OUT="Cygwin-x86_64" ;;
+  *-*-cygwin) OUT="Cygwin-x86" ;;
   x86pc-*-qnx6) OUT="QNX6-i386" ;;
   *-*-qnx6) OUT="QNX6" ;;
   x86-*-android|i?86-*-android) OUT="android-x86" ;;
-- 
2.7.0.rc3

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

Re: [openssl-dev] Upcoming build system change

2016-01-17 Thread Corinna Vinschen 
On Jan 17 17:50, Richard Levitte wrote:
> In message <20160117154353.gc9...@calimero.vinschen.de> on Sun, 17 Jan 2016 
> 16:43:53 +0100, Corinna Vinschen  said:
> 
> vinschen> On Jan 17 01:04, Richard Levitte wrote:
> vinschen> > If you have a look in "config", it doesn't generate 
> "Cygwin-x86_64" at
> vinschen> > all.  Would you be willing to have a look at that script and 
> modernise
> vinschen> > it regarding Cygwin?
> vinschen> 
> vinschen> Like the attached?
> 
> Thank you, that helped...  it was less traumatic than I imagined ;-)
> I've attached a small fixup, your thoughts?

Well, that works, too.  But if we ever support another architecture,
we'd have to tweak two files, config and 10-main.conf, rather then just
one, 10-main.conf.



Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-17 Thread Corinna Vinschen 
On Jan 17 18:13, Corinna Vinschen wrote:
> On Jan 17 17:50, Richard Levitte wrote:
> > In message <20160117154353.gc9...@calimero.vinschen.de> on Sun, 17 Jan 2016 
> > 16:43:53 +0100, Corinna Vinschen  said:
> > 
> > vinschen> On Jan 17 01:04, Richard Levitte wrote:
> > vinschen> > If you have a look in "config", it doesn't generate 
> > "Cygwin-x86_64" at
> > vinschen> > all.  Would you be willing to have a look at that script and 
> > modernise
> > vinschen> > it regarding Cygwin?
> > vinschen> 
> > vinschen> Like the attached?
> > 
> > Thank you, that helped...  it was less traumatic than I imagined ;-)
> > I've attached a small fixup, your thoughts?
> 
> Well, that works, too.  But if we ever support another architecture,
> we'd have to tweak two files, config and 10-main.conf, rather then just
> one, 10-main.conf.

Btw., when calling Configure rather than config, i686 would be simpler
for the package builder since it could just use the build variable
${ARCH}, rather than having to check and explicitely turn this to "x86".


Just saying...
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-17 Thread Richard Levitte 
In message <20160117171350.ga16...@calimero.vinschen.de> on Sun, 17 Jan 2016 
18:13:50 +0100, Corinna Vinschen  said:

vinschen> On Jan 17 17:50, Richard Levitte wrote:
vinschen> > In message <20160117154353.gc9...@calimero.vinschen.de> on Sun, 17 
Jan 2016 16:43:53 +0100, Corinna Vinschen  said:
vinschen> > 
vinschen> > vinschen> On Jan 17 01:04, Richard Levitte wrote:
vinschen> > vinschen> > If you have a look in "config", it doesn't generate 
"Cygwin-x86_64" at
vinschen> > vinschen> > all.  Would you be willing to have a look at that 
script and modernise
vinschen> > vinschen> > it regarding Cygwin?
vinschen> > vinschen> 
vinschen> > vinschen> Like the attached?
vinschen> > 
vinschen> > Thank you, that helped...  it was less traumatic than I imagined ;-)
vinschen> > I've attached a small fixup, your thoughts?
vinschen> 
vinschen> Well, that works, too.  But if we ever support another architecture,
vinschen> we'd have to tweak two files, config and 10-main.conf, rather then 
just
vinschen> one, 10-main.conf.

I can live with that.  Or, well, that's actually just a slightly
different fixup away.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
>From 2ec18167fdaeb03f45a2f3b726aa6f7fdcf31178 Mon Sep 17 00:00:00 2001
From: Richard Levitte 
Date: Sun, 17 Jan 2016 17:48:53 +0100
Subject: [PATCH 1/2] FIXUP to adjust names and include i[345]86

---
 Configurations/10-main.conf | 2 +-
 config  | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
index b1528c1..479bc58 100644
--- a/Configurations/10-main.conf
+++ b/Configurations/10-main.conf
@@ -1221,7 +1221,7 @@
 },
 
  Cygwin
-"Cygwin-i686" => {
+"Cygwin-x86" => {
 inherit_from => [ asm("x86_asm") ],
 cc   => "gcc",
 cflags   => "-DTERMIOS -DL_ENDIAN -Wall",
diff --git a/config b/config
index 6f8ee91..000b7f0 100755
--- a/config
+++ b/config
@@ -806,6 +806,8 @@ case "$GUESSOS" in
 	fi
 	;;
   # these are all covered by the catchall below
+  x86_64-pc-cygwin) OUT="Cygwin-x86_64" ;;
+  i[3456]86-*-cygwin) OUT="Cygwin-x86" ;;
   *-*-cygwin) OUT="Cygwin-${MACHINE}" ;;
   x86pc-*-qnx6) OUT="QNX6-i386" ;;
   *-*-qnx6) OUT="QNX6" ;;
-- 
2.7.0.rc3

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

Re: [openssl-dev] Upcoming build system change

2016-01-17 Thread Richard Levitte 
In message <20160117172014.gc16...@calimero.vinschen.de> on Sun, 17 Jan 2016 
18:20:14 +0100, Corinna Vinschen  said:

vinschen> On Jan 17 18:13, Corinna Vinschen wrote:
vinschen> > On Jan 17 17:50, Richard Levitte wrote:
vinschen> > > In message <20160117154353.gc9...@calimero.vinschen.de> on Sun, 
17 Jan 2016 16:43:53 +0100, Corinna Vinschen  said:
vinschen> > > 
vinschen> > > vinschen> On Jan 17 01:04, Richard Levitte wrote:
vinschen> > > vinschen> > If you have a look in "config", it doesn't generate 
"Cygwin-x86_64" at
vinschen> > > vinschen> > all.  Would you be willing to have a look at that 
script and modernise
vinschen> > > vinschen> > it regarding Cygwin?
vinschen> > > vinschen> 
vinschen> > > vinschen> Like the attached?
vinschen> > > 
vinschen> > > Thank you, that helped...  it was less traumatic than I imagined 
;-)
vinschen> > > I've attached a small fixup, your thoughts?
vinschen> > 
vinschen> > Well, that works, too.  But if we ever support another architecture,
vinschen> > we'd have to tweak two files, config and 10-main.conf, rather then 
just
vinschen> > one, 10-main.conf.
vinschen> 
vinschen> Btw., when calling Configure rather than config, i686 would be simpler
vinschen> for the package builder since it could just use the build variable
vinschen> ${ARCH}, rather than having to check and explicitely turn this to 
"x86".
vinschen> 
vinschen> 
vinschen> Just saying...

I was just thinking of that, as well as a backward compatibility name
Cygwin.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
>From 264c39920dd8b37345837adec251334db766ac4e Mon Sep 17 00:00:00 2001
From: Richard Levitte 
Date: Sun, 17 Jan 2016 18:03:04 +0100
Subject: [PATCH 2/2] Add some extra Cygwin targets as aliases for Cygwin-x86

Cygwin was used for x86 before, so let's keep it around for those who
still use it (it make Configure reconf possible).
Cygwin-i[3456]86 for those that might generate and pass a target name
directly to Configure.
---
 Configurations/10-main.conf | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
index 479bc58..06911ac 100644
--- a/Configurations/10-main.conf
+++ b/Configurations/10-main.conf
@@ -1251,6 +1251,23 @@
 shared_ldflag=> "-shared",
 shared_extension => ".dll.a",
 },
+# Backward compatibility for those using this target
+"Cygwin" => {
+	inherit_from => [ "Cygwin-x86" ]
+},
+# In case someone constructs the Cygwin target name themself
+"Cygwin-i386" => {
+	inherit_from => [ "Cygwin-x86" ]
+},
+"Cygwin-i486" => {
+	inherit_from => [ "Cygwin-x86" ]
+},
+"Cygwin-i586" => {
+	inherit_from => [ "Cygwin-x86" ]
+},
+"Cygwin-i686" => {
+	inherit_from => [ "Cygwin-x86" ]
+},
 
  NetWare from David Ward (dsw...@novell.com)
 # requires either MetroWerks NLM development tools, or gcc / nlmconv
-- 
2.7.0.rc3

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

Re: [openssl-dev] Upcoming build system change

2016-01-16 Thread Richard Levitte 
In message <5699df80.6030...@dancingdragon.be> on Fri, 15 Jan 2016 22:13:20 
-0800, Joey Yandle  said:

dragon> I tried building your branch on windows, but the windows Configure
dragon> targets appear to be missing:

I haven't done anything specific with Windows yet...  or, quite
frankly, checked it very much...  My focus has been mainly on Unix and
VMS.  I do have some start of a makefile for Windows as well, but it's
just that, as start.

dragon> c:\src\openssl>perl Configure VC-WIN64A
dragon> Configuring OpenSSL version 1.1.0-pre3-dev (0x0x1013L)
dragon> ...
dragon> Configuring for VC-WIN64A
dragon> Warning! target VC-WIN64A doesn't exist!
dragon> Can't use an undefined value as an ARRAY reference at Configure line
dragon> 825.

This surprises me a bit, but we've had some issues surrounding this
very target in master as well...  it came down to Configure being a
bit petty and has been changed accordingly, but my branch hasn't been
rebased on the freshest master yet, so the fix hasn't propagated to my
branch yet.  I'm going to deal with that tomorrow and will make sure
to verify the usual Windows configs then.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-16 Thread Richard Levitte 
In message <20160116164653.gh12...@calimero.vinschen.de> on Sat, 16 Jan 2016 
17:46:53 +0100, Corinna Vinschen  said:

vinschen> > ./config --unified
vinschen> 
vinschen> I tried that and it doesn't work correctly for Cygwin on x86_64.
vinschen> Rather than choosing the "Cygwin-x86_64" configuration, it chooses
vinschen> the "Cygwin" configuration which is for the i686 based 32 bit
vinschen> version of Cygwin.
vinschen> 
vinschen> Can this be recified easily.
vinschen> 
vinschen> Btw., for the new unified configuration it might make sense to
vinschen> rename "Cygwin" to "Cygwin-i686".  -march could then be set for
vinschen> i686 as well since 32 bit Cygwin won't run on older CPUs anyway.

Hey Corinna,

This particular issue has nothing at all to do with with my build
system changes, and everything to do with the "config" script.  Its
responsability is to figure out what the platform target should be and
then call Configure with it.

If you have a look in "config", it doesn't generate "Cygwin-x86_64" at
all.  Would you be willing to have a look at that script and modernise
it regarding Cygwin?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Upcoming build system change

2016-01-16 Thread Corinna Vinschen 
Hi Richard,

On Jan 14 21:59, Richard Levitte wrote:
> Hi,
> 
> there's an effort going on to revamp the build system for future
> OpenSSL, coining it as "unified".  The intention is to have one and
> the same base of information for all platforms, instead of having to
> maintain one set of files for Unixly platforms, one makefile generator
> for Windowsy platforms, and one pile of scripts with a serious case of
> bit rot for VMS.
> [...]
> Config and build
> 
> 
> For Unix users, who are used to the usual generation of a top Makefile
> from Makefile.org...  that is, Makefile.in since recently, this it
> still the default, but you can always use the unified build as an
> alternative by adding the flag --unified, like so:
> 
> ./config --unified

I tried that and it doesn't work correctly for Cygwin on x86_64.
Rather than choosing the "Cygwin-x86_64" configuration, it chooses
the "Cygwin" configuration which is for the i686 based 32 bit
version of Cygwin.

Can this be recified easily.

Btw., for the new unified configuration it might make sense to
rename "Cygwin" to "Cygwin-i686".  -march could then be set for
i686 as well since 32 bit Cygwin won't run on older CPUs anyway.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev