[PATCH] Makefile: Fix static tool build on incremental builds

[Christian Storm]

From: Christian Storm <christi...@siemens.com>

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 <christi...@siemens.com>
---
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 \
--
2.33.1

[Jan Kiszka]

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?

Jan

--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

[Christian Storm]

Hi Jan,

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
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.

So, we can put this to -next to meanwhile fix iterative development builds
and wait for my Nix findings.

What do you think?



Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, Technology, T RDA IOT SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany

[Jan Kiszka]

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.

> 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
bullseye and test buster.

>
> So, we can put this to -next to meanwhile fix iterative development builds
> and wait for my Nix findings.
>
> What do you think?
>

I'm still struggling with understanding the practical impact. We install
everything that is needed, but if the user does not re-deploy the new
lib, bg_setenv might be broken, at least in some build environments. If
that is an issue... don't know yet.

[Jan Kiszka]

I meant libtool versions/patches.

> 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.

Thanks,

[Christian Storm]

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.