Upcoming build system change

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Upcoming build system change

Richard Levitte - VMS Whacker-2
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.

In particular, this is of interest for the VMS folks, as it's the only
currently workable build system for upcoming version 1.1.


Finding it
==========

For now, this change is available on here:

    https://github.com/levitte/openssl/tree/refactor-build

which is git repo https://github.com/levitte/openssl.git, branch
refactor-build.


Using it
========

Requirements
------------

On all platforms, it requires

- Perl!  Reports tell me that version 5.10.1 works fine but might need
  some extra perl modules (Test::More and possibly others.  Feedback
  welcome!).  Unix usually has it installed or easy to find.  For VMS,
  there's an install kit on sourceforge
  (https://sourceforge.net/projects/vmsperlkit/files/Archive/), and
  Windows, we've always recommended ActiveState Perl
  (http://www.activestate.com/ActivePerl).
- The Perl module Text::Template, which is the driver behind the
  generation Makefile and other files.  This branch relies quite
  heavily on templates.

On Unix, it requires

- the usual developmemt stuff.  cc, as and make would be the really
  bare minimum, and maybe I'm forgetting something, but what is
  usually considered the normal tool chain should work out.

On VMS, it requires

- DEC C...  It's called HP C these days and might be called something
  else again when VSI starts shipping.  It needs to be recent enough
  to support the qualifiers /NAMES=(AS_IS,SHORTENED) and /REPOSITORY
  (I welcome feedback on which the minimum version for this is!)
- DECset, at the very least MMS.  Alternatively, MMK can be used if
  you can find it (if anyone knows of a place that has it for sure,
  feedback is welcome!)
- Of course, the rest of the tool chain, but that comes with the
  operating system, no worries there.

[I certainly hope I didn't forget anything, but if I did, feedback is
welcome!]

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
    make
    make test
    # There is no install target yet, it's coming up!

You will get One Top Makefile that does everything.  It will not touch
any other Makefile.


For VMS users, the unified build is the only one available in this
branch, the old scripts are simply gone.  Instead, you configure just
like you would on any other platform (well, almost, there isn't any
config.com yet, so you'll have to jump directly to the Configure
script), and that will generate a descrip.mms:

    perl Configure vms-alpha ! or vms-ia64
    mms
    mms test
    ! 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!


Features
========

There are a few features in the unified build that are worth testing:

1. Out of source tree builds!  It's perfectly possible to do this:

    mkdir ../build
    cd ../build
    perl ../openssl-src/config
    make
    make test

   (and yes, on VMS as well)

2. The generated Makefile supports parallell make:

    make -j9

   (carefull, though, don't try the silliness I tried: make -j9 clean all)


Future
======

I plan on making the generated Makefile / descrip.mms full featured,
which means at least adding install targets.  Then, on to a template
for a Windows makefile.


=================
Feedback welcome!
=================


Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

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

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

I verified that the windows targets are present in
Configurations/10-main.conf:

     "VC-WIN64A" => {
         inherit_from     => [ "VC-common", asm("x86_64_asm") ],
         cflags           => add(" ", "-DUNICODE -D_UNICODE"),
         sys_id           => "WIN64A",
         bn_ops           => "SIXTY_FOUR_BIT RC4_CHUNK_LL DES_INT
EXPORT_VAR_AS_FN",
         bn_obj           => sub { my $r=join(" ",@_);
$r=~s/x86_64\-gcc/bn_asm/; $r; },
         perlasm_scheme   => "auto",
     build_scheme     => [ "mk1mf", "VC-W64" ],
     },

Am I doing something wrong?  Your email didn't actually say anything
about the windows build...

cheers,

Joey

On 1/14/2016 12:59 PM, 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.
>
> In particular, this is of interest for the VMS folks, as it's the only
> currently workable build system for upcoming version 1.1.
>
>
> Finding it
> ==========
>
> For now, this change is available on here:
>
>      https://github.com/levitte/openssl/tree/refactor-build
>
> which is git repo https://github.com/levitte/openssl.git, branch
> refactor-build.
>
>
> Using it
> ========
>
> Requirements
> ------------
>
> On all platforms, it requires
>
> - Perl!  Reports tell me that version 5.10.1 works fine but might need
>    some extra perl modules (Test::More and possibly others.  Feedback
>    welcome!).  Unix usually has it installed or easy to find.  For VMS,
>    there's an install kit on sourceforge
>    (https://sourceforge.net/projects/vmsperlkit/files/Archive/), and
>    Windows, we've always recommended ActiveState Perl
>    (http://www.activestate.com/ActivePerl).
> - The Perl module Text::Template, which is the driver behind the
>    generation Makefile and other files.  This branch relies quite
>    heavily on templates.
>
> On Unix, it requires
>
> - the usual developmemt stuff.  cc, as and make would be the really
>    bare minimum, and maybe I'm forgetting something, but what is
>    usually considered the normal tool chain should work out.
>
> On VMS, it requires
>
> - DEC C...  It's called HP C these days and might be called something
>    else again when VSI starts shipping.  It needs to be recent enough
>    to support the qualifiers /NAMES=(AS_IS,SHORTENED) and /REPOSITORY
>    (I welcome feedback on which the minimum version for this is!)
> - DECset, at the very least MMS.  Alternatively, MMK can be used if
>    you can find it (if anyone knows of a place that has it for sure,
>    feedback is welcome!)
> - Of course, the rest of the tool chain, but that comes with the
>    operating system, no worries there.
>
> [I certainly hope I didn't forget anything, but if I did, feedback is
> welcome!]
>
> 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
>      make
>      make test
>      # There is no install target yet, it's coming up!
>
> You will get One Top Makefile that does everything.  It will not touch
> any other Makefile.
>
>
> For VMS users, the unified build is the only one available in this
> branch, the old scripts are simply gone.  Instead, you configure just
> like you would on any other platform (well, almost, there isn't any
> config.com yet, so you'll have to jump directly to the Configure
> script), and that will generate a descrip.mms:
>
>      perl Configure vms-alpha ! or vms-ia64
>      mms
>      mms test
>      ! 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!
>
>
> Features
> ========
>
> There are a few features in the unified build that are worth testing:
>
> 1. Out of source tree builds!  It's perfectly possible to do this:
>
>      mkdir ../build
>      cd ../build
>      perl ../openssl-src/config
>      make
>      make test
>
>     (and yes, on VMS as well)
>
> 2. The generated Makefile supports parallell make:
>
>      make -j9
>
>     (carefull, though, don't try the silliness I tried: make -j9 clean all)
>
>
> Future
> ======
>
> I plan on making the generated Makefile / descrip.mms full featured,
> which means at least adding install targets.  Then, on to a template
> for a Windows makefile.
>
>
> =================
> Feedback welcome!
> =================
>
>
> Cheers,
> Richard
>
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Fri, 15 Jan 2016 22:13:20 -0800, Joey Yandle <[hidden email]> 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 (0x0x10100003L)
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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Corinna Vinschen
In reply to this post by Richard Levitte - VMS Whacker-2
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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Sat, 16 Jan 2016 17:46:53 +0100, Corinna Vinschen <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Corinna Vinschen
On Jan 17 01:04, Richard Levitte wrote:

> In message <[hidden email]> on Sat, 16 Jan 2016 17:46:53 +0100, Corinna Vinschen <[hidden email]> 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?
Like the attached?


Corinna

--
Corinna Vinschen
Cygwin Maintainer
Red Hat

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

0001-Fix-configuration-system-to-support-different-archit.patch (2K) Download Attachment
signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/

From 3551960614f451350b791182f423284a2be6f389 Mon Sep 17 00:00:00 2001
From: Richard Levitte <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Corinna Vinschen
On Jan 17 17:50, Richard Levitte wrote:

> In message <[hidden email]> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen <[hidden email]> 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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Corinna Vinschen
On Jan 17 18:13, Corinna Vinschen wrote:

> On Jan 17 17:50, Richard Levitte wrote:
> > In message <[hidden email]> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen <[hidden email]> 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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Richard Levitte - VMS Whacker-2
In reply to this post by Corinna Vinschen
In message <[hidden email]> on Sun, 17 Jan 2016 18:13:50 +0100, Corinna Vinschen <[hidden email]> said:

vinschen> On Jan 17 17:50, Richard Levitte wrote:
vinschen> > In message <[hidden email]> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/

From 2ec18167fdaeb03f45a2f3b726aa6f7fdcf31178 Mon Sep 17 00:00:00 2001
From: Richard Levitte <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Richard Levitte - VMS Whacker-2
In reply to this post by Corinna Vinschen
In message <[hidden email]> on Sun, 17 Jan 2016 18:20:14 +0100, Corinna Vinschen <[hidden email]> said:

vinschen> On Jan 17 18:13, Corinna Vinschen wrote:
vinschen> > On Jan 17 17:50, Richard Levitte wrote:
vinschen> > > In message <[hidden email]> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/

From 264c39920dd8b37345837adec251334db766ac4e Mon Sep 17 00:00:00 2001
From: Richard Levitte <[hidden email]>
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 ([hidden email])
 # 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
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Corinna Vinschen
On Jan 17 18:33, Richard Levitte wrote:

> In message <[hidden email]> on Sun, 17 Jan 2016 18:20:14 +0100, Corinna Vinschen <[hidden email]> said:
>
> vinschen> On Jan 17 18:13, Corinna Vinschen wrote:
> vinschen> > On Jan 17 17:50, Richard Levitte wrote:
> vinschen> > > In message <[hidden email]> on Sun, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen <[hidden email]> 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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Richard Levitte - VMS Whacker-2
In reply to this post by Richard Levitte - VMS Whacker-2
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 <[hidden email]> on Thu, 14 Jan 2016 21:59:03 +0100 (CET), Richard Levitte <[hidden email]> 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
levitte>
levitte>    (and yes, on VMS as well)
levitte>
levitte> 2. The generated Makefile supports parallell make:
levitte>
levitte>     make -j9
levitte>
levitte>    (carefull, though, don't try the silliness I tried: make -j9 clean all)
levitte>
levitte>
levitte> Future
levitte> ======
levitte>
levitte> I plan on making the generated Makefile / descrip.mms full featured,
levitte> which means at least adding install targets.  Then, on to a template
levitte> for a Windows makefile.
levitte>
levitte>
levitte> =================
levitte> Feedback welcome!
levitte> =================
levitte>
levitte>
levitte> Cheers,
levitte> Richard
levitte>
levitte> --
levitte> Richard Levitte         [hidden email]
levitte> OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

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
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

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
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Richard Levitte - VMS Whacker-2
In reply to this post by Corinna Vinschen
In message <[hidden email]> on Sat, 23 Jan 2016 21:27:58 +0100, Corinna Vinschen <[hidden email]> 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.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?

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

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Richard Levitte - VMS Whacker-2
In reply to this post by Corinna Vinschen
In message <[hidden email]> on Sat, 23 Jan 2016 22:01:16 +0100, Corinna Vinschen <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming build system change

Tim Rice
In reply to this post by Corinna Vinschen
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


--
Tim Rice Multitalents (707) 456-1146
[hidden email]


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