On 25.08.21 12:45, Christian Storm wrote:
> 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? :)
>
The compatibility to bgenv.dat revisions is the task of the lib, in the
future, see the other thread.
But it's likely safer to avoid the manual version bump, thus forgetting
an update when changing the lib APIs.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
--
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/35eaeaca-80d0-3286-49bf-3ee5d2c4c8fc%40siemens.com.
