[bug#46728,4/7] gnu: Add s2n.

From 78e69597f63b22a3249853208e88f8f57cf84054 Mon Sep 17 00:00:00 2001
From: Greg Hogan <code@greghogan.com>
Date: Tue, 19 Jan 2021 12:52:01 +0000
Subject: [PATCH 4/7] gnu: Add s2n.

* gnu/packages/tls.scm (s2n): New variable.
---
 gnu/packages/tls.scm | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

+    (license license:asl2.0)))
--
2.30.1

On Tue, Feb 23, 2021 at 06:17:06PM -0500, Greg Hogan wrote:
> From 78e69597f63b22a3249853208e88f8f57cf84054 Mon Sep 17 00:00:00 2001
> From: Greg Hogan <code@greghogan.com>
> Date: Tue, 19 Jan 2021 12:52:01 +0000
> Subject: [PATCH 4/7] gnu: Add s2n.
> 
> * gnu/packages/tls.scm (s2n): New variable.

Thank you for this patch series!

> +    (propagated-inputs
> +     `(("openssl" ,openssl)
> +       ("openssl:static" ,openssl "static")))

I'm wondering specifically about the use of static OpenSSL in these
patches. It's a little unusual to use statically-linked outputs in Guix.
Is it required for s2n?

Hi Leo,

The CMake configuration [1] has both shared and static dependencies on
LibCrypto.

The AWS packages (aws-sdk-cpp and dependencies) are currently built as
static libraries. I would like to build both static and shared but could
not find an example or simple method for building both using cmake. Do you
think it would be worthwhile to extend the cmake-build-system to optionally
configure, build, and install static libraries with additional phases? The
gnu-build-system makes it easy to inline a new phase into the package
definition (when the makefile has both 'make' and 'make static' targets)
but with CMake we are forced to duplicate the configure phase, which is 44
lines of code.

Greg

[1]
https://github.com/aws/s2n-tls/blob/main/cmake/modules/FindLibCrypto.cmake

On Wed, Feb 24, 2021 at 4:34 PM Leo Famulari <leo@famulari.name> wrote:

> On Tue, Feb 23, 2021 at 06:17:06PM -0500, Greg Hogan wrote:
> > From 78e69597f63b22a3249853208e88f8f57cf84054 Mon Sep 17 00:00:00 2001
> > From: Greg Hogan <code@greghogan.com>
> > Date: Tue, 19 Jan 2021 12:52:01 +0000
> > Subject: [PATCH 4/7] gnu: Add s2n.
> >
> > * gnu/packages/tls.scm (s2n): New variable.
>
> Thank you for this patch series!
>
> > +    (propagated-inputs
> > +     `(("openssl" ,openssl)
> > +       ("openssl:static" ,openssl "static")))
>
> I'm wondering specifically about the use of static OpenSSL in these
> patches. It's a little unusual to use statically-linked outputs in Guix.
> Is it required for s2n?
>

Hi,

Greg Hogan <code@greghogan.com> skribis:

> The AWS packages (aws-sdk-cpp and dependencies) are currently built as
> static libraries. I would like to build both static and shared but could
> not find an example or simple method for building both using cmake. Do you
> think it would be worthwhile to extend the cmake-build-system to optionally
> configure, build, and install static libraries with additional phases? The
> gnu-build-system makes it easy to inline a new phase into the package
> definition (when the makefile has both 'make' and 'make static' targets)
> but with CMake we are forced to duplicate the configure phase, which is 44
> lines of code.

In general, it’s best to build only shared libraries.  That allows for
reduced memory usage, fast security updates via grafts, etc.  So if you
could make the AWS packages build as shared libraries only, that’d be
great.

It’s OK to optionally add static libraries, preferably in a separate
output or even a separate package, but that’s not what should be used by
default.

Does that make sense?

Thanks,
Ludo’.

On Tue, Mar 2, 2021 at 2:37 PM Ludovic Courtès <ludo@gnu.org> wrote:

> Hi,
>
> Greg Hogan <code@greghogan.com> skribis:
>
> > The AWS packages (aws-sdk-cpp and dependencies) are currently built as
> > static libraries. I would like to build both static and shared but could
> > not find an example or simple method for building both using cmake. Do
> you
> > think it would be worthwhile to extend the cmake-build-system to
> optionally
> > configure, build, and install static libraries with additional phases?
> The
> > gnu-build-system makes it easy to inline a new phase into the package
> > definition (when the makefile has both 'make' and 'make static' targets)
> > but with CMake we are forced to duplicate the configure phase, which is
> 44
> > lines of code.
>
> In general, it’s best to build only shared libraries.  That allows for
> reduced memory usage, fast security updates via grafts, etc.  So if you
> could make the AWS packages build as shared libraries only, that’d be
> great.
>
> It’s OK to optionally add static libraries, preferably in a separate
> output or even a separate package, but that’s not what should be used by
> default.
>
> Does that make sense?


Yes, I would prefer to provide shared as the default output and static as a
separate output to the same package. There look to be three options:

1) separate packages (as with boost and boost-static). This is simple but
not as elegant (boost-static is the eighth most relevant package when guix
search'ing for "boost").

2) duplicate CMake phases in the package definition (much more verbose than
with gnu-build-system). This results in considerable duplication of build
system code and is unmaintainable.

3) extend the cmake-build-system to optionally configure, build, and
install static libraries with additional phases. The ideal result but
requires modification of the cmake-build-system.

Thoughts?


> Thanks,
> Ludo’.
>

Hi Greg,

Greg Hogan <code@greghogan.com> skribis:

> On Tue, Mar 2, 2021 at 2:37 PM Ludovic Courtès <ludo@gnu.org> wrote:

[...]

>> In general, it’s best to build only shared libraries.  That allows for
>> reduced memory usage, fast security updates via grafts, etc.  So if you
>> could make the AWS packages build as shared libraries only, that’d be
>> great.
>>
>> It’s OK to optionally add static libraries, preferably in a separate
>> output or even a separate package, but that’s not what should be used by
>> default.
>>
>> Does that make sense?
>
>
> Yes, I would prefer to provide shared as the default output and static as a
> separate output to the same package.

One option is to not provide static libraries at all, at least for now.
They make little sense from a Guix perspective anyway.

Would that be an option for you?

> There look to be three options:
>
> 1) separate packages (as with boost and boost-static). This is simple but
> not as elegant (boost-static is the eighth most relevant package when guix
> search'ing for "boost").
>
> 2) duplicate CMake phases in the package definition (much more verbose than
> with gnu-build-system). This results in considerable duplication of build
> system code and is unmaintainable.

Can’t CMake build both static and “shared” (-fPIC) libraries in one go?
I think it can do that.

> 3) extend the cmake-build-system to optionally configure, build, and
> install static libraries with additional phases. The ideal result but
> requires modification of the cmake-build-system.

In the vast majority of cases, we don’t provide static libraries at
all.  The only exceptions are when we need statically linked binaries
for bootstrapping purposes or within the initrd.

HTH,
Ludo’.

Hi Ludo’,

Switched to build as shared libraries, and bumped versions.

Greg

On Mon, Mar 8, 2021 at 8:49 AM Ludovic Courtès <ludo@gnu.org> wrote:

> Hi Greg,
>
> Greg Hogan <code@greghogan.com> skribis:
>
> > On Tue, Mar 2, 2021 at 2:37 PM Ludovic Courtès <ludo@gnu.org> wrote:
>
> [...]
>
> >> In general, it’s best to build only shared libraries.  That allows for
> >> reduced memory usage, fast security updates via grafts, etc.  So if you
> >> could make the AWS packages build as shared libraries only, that’d be
> >> great.
> >>
> >> It’s OK to optionally add static libraries, preferably in a separate
> >> output or even a separate package, but that’s not what should be used by
> >> default.
> >>
> >> Does that make sense?
> >
> >
> > Yes, I would prefer to provide shared as the default output and static
> as a
> > separate output to the same package.
>
> One option is to not provide static libraries at all, at least for now.
> They make little sense from a Guix perspective anyway.
>
> Would that be an option for you?
>
> > There look to be three options:
> >
> > 1) separate packages (as with boost and boost-static). This is simple but
> > not as elegant (boost-static is the eighth most relevant package when
> guix
> > search'ing for "boost").
> >
> > 2) duplicate CMake phases in the package definition (much more verbose
> than
> > with gnu-build-system). This results in considerable duplication of build
> > system code and is unmaintainable.
>
> Can’t CMake build both static and “shared” (-fPIC) libraries in one go?
> I think it can do that.
>
> > 3) extend the cmake-build-system to optionally configure, build, and
> > install static libraries with additional phases. The ideal result but
> > requires modification of the cmake-build-system.
>
> In the vast majority of cases, we don’t provide static libraries at
> all.  The only exceptions are when we need statically linked binaries
> for bootstrapping purposes or within the initrd.
>
> HTH,
> Ludo’.
>

Hi Greg,

Greg Hogan <code@greghogan.com> skribis:

> Switched to build as shared libraries, and bumped versions.

I’ve now pushed all seven patches.

Thanks for taking the time to make these changes!

Ludo’.