Hi Jan,
> > Adapt the build system to build a shared library
> > libebgenv-${EBG_VERSION}.so symlinked to by a
> > libebgenv.so in addition to the static libebgenv.a.
> >
> > This shared library may be used by external software
> > such as SWUpdate [1] wanting to modify EFI Boot Guard's
> > environment without having to statically link against
> > libebgenv.a, following the pattern of libubootenv [2].
> >
> > Note that the bg_setenv utility deliberately remains
> > statically linked against libebgenv.a. for easy
> > inclusion in initramfs or rescue media and to not
> > break existing deployments. Alike, libebgenv.a is
> > still installed via make install (though distrbutions
>
> distributions
Fixed locally for V2.
> > may decide to not package it).
> > This may be deprecated and removed in future versions.
> >
> > [1] https://github.com/sbabic/swupdate
> > [2] https://github.com/sbabic/libubootenv
> >
> > Signed-off-by: Christian Storm <[email protected]>
> > ---
> > .gitignore | 4 ++++
> > Makefile.am | 9 +++++++++
> > configure.ac | 3 +++
> > 3 files changed, 16 insertions(+)
> >
> > diff --git a/.gitignore b/.gitignore
> > index 6433560..c1f0088 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -23,6 +23,7 @@
> > *.so
> > *.so.*
> > *.dylib
> > +*.lai
> >
> > # EFI
> > *.efi
> > @@ -70,6 +71,7 @@ Makefile.in
> > /config.status
> > /config.sub
> > /configure
> > +/configure~
> > /configure.scan
> > /depcomp
> > /install-sh
> > @@ -79,3 +81,5 @@ Makefile.in
> > /tools/tests/Makefile
> > .deps/
> > version.h
> > +m4/
>
> Why that? We have m4/arch.m4 in git.
Yes, this was too broad. We additionally get
m4/libtool.m4
m4/ltoptions.m4
m4/ltsugar.m4
m4/ltversion.m4
m4/lt~obsolete.m4
auto-generated by this change.
I'll exclude them specifically for a V2 as in
m4/libtool.m4
m4/lt*
> > +libtool
> > diff --git a/Makefile.am b/Makefile.am
> > index 12dcb19..7c18227 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -92,6 +92,14 @@ libebgenv_a_CFLAGS = \
> > pkginclude_HEADERS = \
> > include/ebgenv.h
> >
> > +#
> > +# Shared libraries
> > +#
> > +LIBEBGENV_SO_VERSION = $(shell $(EGREP) -o '[0-9]+\.[0-9]+' VERSION)
>
> Do we want to couple the lib version that tightly to the releases?
Well, there's the take on library versioning by autotools
https://www.sourceware.org/autobook/autobook/autobook_61.html
but their semantics seems not to be too widely adopted.
The downside of using the version in the shared library names, quoting
above link:
"[...] and you don't mind forcing your users to relink all of the
applications which use one of your Libtool libraries every time you
make a release, then libtool provides the '-release' flag to encode
the project version number in the name of the library [...]"
is usually handled by distributions that exactly do this: repackage
all dependencies and roll out the update to users ― except for
self-built packages that you have to take care for locally....
Another option would be to bump the version on breaking changes only,
manually, and thus decoupling from the "real" version.
Either way, one has to solve the problem of either relinking dependent
applications on version bumps (and installing the updated EFI bootloader
part) or allowing to have multiple versions of the shared library
installed. In the latter case, one must ensure compatibility to the EFI
bootloader part also touching BGENV.DAT so not to use an outdated shared
library to access it.
So... what are we going to do? :)
Kind regards,
Christian
--
Dr. Christian Storm
Siemens AG, Technology, T RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany
--
You received this message because you are subscribed to the Google Groups "EFI
Boot Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/efibootguard-dev/20210825104551.uld35gcjmdcxh42w%40MD1ZFJVC.ad001.siemens.net.
