On 20.10.21 22:31, Christian Storm wrote: > Hi Michael, Jan, > >>> 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? 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/5c6afd73-444d-0d20-5ace-76a5409048f5%40siemens.com.
