> >>> So, problem solved, at least for me ;) > >> > >> I was too quick with my conclusion. Incremental compilation does not > >> work as it should, even on Arch Linux. > >> > >> git revision: c8ad20f36145bb4cd5a61549fd96bb7cbde0f144 > >> > >> Steps (clean checkout): > >> > >> ``` > >> $ autoreconf -fi > >> $ ./configure > >> $ make > >> # first time > >> $ ./bg_printenv --help > >> Usage: bg_printenv [OPTION...] > >> # ... > >> > >> # edit tools/bg_setenv.c > >> $ make > >> # second time > >> $ ./bg_printenv --help > >> Usage: lt-bg_setenv [OPTION...] > >> # ... > >> ``` > >> > >> 1) The first time, ./bg_printenv is an ELF file and everything is > >> fine, i.e. bg_printenv thinks that it is bg_printenv. > >> 2) The second time, ./bg_printenv is a shell script (generated by > >> libtool) and hands over control to .libs/lt-bg_setenv. Thus > >> bg_printenv believes that it is bg_setenv, which is wrong. > > > > FWIW, I took a deeper look into the whole libtool stuff and I can > > only recommend not to do the same for your mental sanity... So: > > > > First time you build it, libtool produces a proper statically linked > > bg_setenv which by argv[0] decides what to do. So far so good. > > > > The next time, i.e., incremental build, libtool in all its wisdom > > decides not to do the same but instead builds bg_setenv *dynamically* > > linked against libebgenv. Then, you have opened the can of worms > > which libtool tries to escape by wrapping executables/scripts, see, > > e.g., [1,2] for the reasoning. This is exactly what we're seeing here. > > > > Luckily, we're after a statically linked bg_setenv anyway, so we don't > > need this "feature". Hence, can you please test whether the following > > patch solves the issue? It did for me in all the scenarios I tested. > > > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -107,7 +107,7 @@ bg_setenv_SOURCES = \ > > tools/bg_setenv.c > > > > bg_setenv_CFLAGS = \ > > - $(AM_CFLAGS) > > + $(AM_CFLAGS) -static > > > > bg_setenv_LDADD = \ > > -lebgenv \ > > > > > > If it does solve the issue, I'll prepare a proper patch and sent it out. > > > > It resolves the build-env weirdness - but why are we after a statically > linked version, installing libebgenv.so twice this way?
Quoting the original patch: "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 distributions may decide to not package it). This may be deprecated and removed in future versions." I think this still holds true and it has some value to have bg_setenv statically linked, in particular for rescue scenarios. Then, if you have further tools wanting to modify the bootloader environment, you install the library contents twice: statically inside bg_setenv and as an .so shared among those tools. So you "wasted" ~40k disk space. If you don't have such tools, you "waste" nothing, i.e., when bg_setenv is your "interface" to the bootloader. IMO, the hassle with a shared library libebgenv.so in rescue/ emergency scenarios is well worth the disk space "waste". But as already noted in the patch, we may deprecate this with a proper phase-out period... 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/20211021075210.7w635sqk3jg5ret7%40MD1ZFJVC.ad001.siemens.net.
