Hi Jan, > >>>> On first build, libtool produces a proper statically linked > >>>> bg_setenv tool which by argv[0] decides whether to printenv > >>>> or setenv. > >>>> > >>>> On subsequent builds, e.g., while incrementally developing, > >>>> libtool *dynamically* links bg_setenv against libebgenv and > >>>> applies "magic" [1,2] to compensate for library paths. > >>>> This breaks the bg_setenv argv[0] logic. > >>>> > >>>> So, state explicitly that bg_setenv is to be linked statically. > >>>> > >>>> [1] > >>>> https://www.gnu.org/software/libtool/manual/html_node/Linking-executables.html#Linking-executables > >>>> [2] https://autotools.io/libtool/wrappers.html > >>>> > >>>> Signed-off-by: Christian Storm <[email protected]> > >>>> --- > >>>> Makefile.am | 2 +- > >>>> 1 file changed, 1 insertion(+), 1 deletion(-) > >>>> > >>>> diff --git a/Makefile.am b/Makefile.am > >>>> index 3545ae2..2a5f8f8 100644 > >>>> --- 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 \ > >>>> > >>> > >>> OK, that means we are now shipping a bg_setenv with 0.9 that dynamically > >>> links against libebgenv. In 0.8, it was statically linked, right? Do you > >>> think this qualifies for a 0.9.1? > >> > >> On first build, everything is fine. So, if you package EBG (one time > >> build and package) you'll get a statically linked bg_setenv and it's > > > > Nope, this does not seem to be generally true. I've just done a clean > > out-of-tree build, and the installed bg_setenv was linked dynamically > > against libebgenv.
OK, please try with my "Makefile: Fix static tool build on incremental builds, again" patch on top. At least it has solved the issue on Nix for which Michael provided repro steps. Maybe it does also solve it on SUSE? > >> fine. If you start developing and doing iterative builds, the then 2nd > >> and following builds is where libtool interferes. > >> So I do not see an urgent need to rush out a 0.9.1, yet. > >> > >> I still have to investigate Michael's Nix issue to sort it out thoroughly. > >> On Bullseye and Arch the above patch fixes the issue as he has confirmed. > > > > I'm an SUSE. Probably the binutils version again. Let me double-check > > I meant libtool versions/patches. Another distro to test, the more, the better! > > bullseye and test buster. > > > > Both Debian releases are unaffected on first build. > > Well, maybe indeed less critical. Let's queues this up in next for now. I agree, it does make live easier when doing incremental development on some distros at least and it apparently doesn't hurt. When we've found the root cause and have eradicated it, a point release may probably be nice. 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/20211102211934.ynznpnne65l7xfn2%40MD1ZFJVC.ad001.siemens.net.
