Message ID | CA+3U0ZmcORcU94-WtbL5TEcN0nphpojR_OB8thr2m5uPw7LM4g@mail.gmail.com |
---|---|
State | Accepted |
Headers | show |
Series | gnu: aws-sdk-cpp: Update to 1.8.148. | expand |
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’.
diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm index 775e915534..2048dc5bbe 100644 --- a/gnu/packages/tls.scm +++ b/gnu/packages/tls.scm @@ -1024,3 +1024,25 @@ relatively simple Bash script.") derived from Mozilla's collection.") (home-page "https://certifi.io") (license license:mpl2.0)))) + +(define-public s2n + (package + (name "s2n") + (version "1.0.0") + (source (origin + (method git-fetch) + (uri (git-reference + (url (string-append "https://github.com/awslabs/" name)) + (commit (string-append "v" version)))) + (file-name (git-file-name name version)) + (sha256 + (base32 + "1q6kmgwb8jxmc4ijzk9pkqzz8lsbfsv9hyzqvy944w7306zx1r5h")))) + (build-system cmake-build-system) + (propagated-inputs + `(("openssl" ,openssl) + ("openssl:static" ,openssl "static"))) + (synopsis "SSL/TLS implementation") + (description "This library provides a C99 implementation of SSL/TLS.") + (home-page "https://github.com/awslabs/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