Re: [libgpiod][PATCH 1/1] dbus: manager: fix linker not finding libgpiod.so

["Börge Strümpfel" <boerge.struempfel@gmail.com>]

Hi Bart,

On Thu, Feb 6, 2025 at 9:48 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Thu, Feb 6, 2025 at 12:46 AM Börge Strümpfel
> <boerge.struempfel@gmail.com> wrote:
> >
> > Hi Bart,
> >
> > While preparing a patch to add gpio-manager to mainline Buildroot, I
> > encountered this issue again. That is, I can successfully compile the
> > gpio-manager manually (using autotools/gcc/ld provided by ubuntu 2024) however,
> > when using the Buildroot infrastructure, I get a compiler error, stating that
> > the libgpiod.so.3 cannot be found.
> >
> > After further investigation, I'm increasingly unsure on how the
> > libgpiod.so.3 is supposed to be found by the linker in the first place:
> >
> > From what I see, gpio-manager depends on:
> > - bindings/glib/libgpiod-glib
> > - dbus/lib/libgpiodbus
>
> Correct.
>
> > - lib/libgpiod
>
> This one is an indirect dependency, it's already pulled in by libgpiod-glib.so.
>

Yes. You are right - there are no direct calls into the libgpiod
library only via
libgpiod-glib.so. I also verified that the libgpiod is properly build and linked
against the libgpiod.so.

> >
> > However, I see no direct reference in dbus/manager/Makefile.am, nor can I see
> > an indirect reference via the Makefile.am files used to generate:
> > - bindings/glib/libgpiod-glib.la
> > - dbus/lib/libgpiodbus.la
> >
> > Am I missing something obvious?
> >
>
> These are generated in different directories, the Makefiles in there
> take care of this.
>
> > Furthermore upon review, I believe the solution I proposed last October was
> > flawed - I should have used:
> > LDADD += $(top_builddir)/lib/libgpiod.la
>
> On Ubuntu, I see that gpio-manager is only linked against
> libgpiod-glib.so and libgpiodbus.so. However if I cross-compile on
> yocto, it's linked against libgpiod.so as well. I don't know exactly
> what the differences in linker setup are but yocto is able to find
> libgpiod without problems. Before we add an unnecessary flag, may I
> suggest looking into how yocto does the linking?

Here is what I have figured out so far:
 - whether libgpiod.so is linked to the final execuatble seems to be
at least partially
   dependent    on the version of autotools and/or libtools. (Tested
by backporting
   yocto's autotools and libtools)
 - there is a fix in the yocto recipe for finding the libgpiod.so bit
it conserns only
   gobject introspection, which is not the problem I am facing with buildroot
 - The behaviour of the problem I am facing in buildroot does not depend on
   gobject introspection as far as I can tell, since the error happens
independent
   of it. (which is good in my understanding, since it is what I would expect)
  - there is a flag in the libtool "link_all_deplibs" which yocto sets
to "unknown" and
    which in buildroot is set to "no" after the configure step (I
couldn't figure out the
    reason for this yet) If I manually tweek this value in buildroot
between the configure
    and build steps, the gpio-manager is build successfully (with or
without an explicit
    link to libgpiod.so depending on the version of libtools used).
However setting
    this flag to "no" in yocto, still leads to a successful build.
Therefore I don't think,
    this is the root-cause of this problem.

By now I fully agree with you, that gpio-manager should not get libgpiod.so as
a dependency even if I don't know yet where this error is coming from.

Kind Regards, and thanks for your support,
Boerge