[PATCH v2] Support building when fts and obstack aren't part of libc.
Tue Nov 17 13:32:55 GMT 2020
On Tue, 2020-11-03 at 20:39 -0300, Érico Nogueira via Elfutils-devel wrote:
> On Tue Nov 3, 2020 at 10:33 PM -03, Dmitry V. Levin wrote:
> > On Sun, Nov 01, 2020 at 09:48:50PM -0300, Érico Nogueira via
> > Elfutils-devel wrote:
> > >
> > > +saved_LIBS="$LIBS"
> > > +AC_SEARCH_LIBS([_obstack_free], [obstack])
> > > +LIBS="$saved_LIBS"
> > > +case "$ac_cv_search__obstack_free" in
> > > + no) AC_MSG_FAILURE([failed to find obstack_free]) ;;
> > > + -l*) obstack_LIBS="$ac_cv_search__obstack_free" ;;
> > > + *) obstack_LIBS= ;;
> > > +esac
> > > +AC_SUBST([obstack_LIBS])
> > > +
> > Hmm. In  I suggested to check for obstack_free, but
> > here I see you're checking for _obstack_free instead.
> > Since both symbols are provided by glibc, I wonder what was
> > the reason for this change. Is it something to do with libobstack?
> I'm using the version of libobstack  that as far as I know is used by
> most musl-based distros (some of them pull directly from pullmoll's
> personal repo rather than from the void-linux namespace).
> As you can see in , obstack_free is a macro, and AC_SEARCH_LIBS
> didn't seem able to find it during my testing. On the other hand,
> _obstack_free was an actual function, so I switched to it.
> > By the way, the text of AC_MSG_FAILURE is out of sync with the symbol
> > name.
> Indeed. I can send a fix for it together with the argp patch if that's
> ok. Thanks for noticing.
It does look like all (exported) obstack symbols start with _obstack
(although there also is an non-underscore alias obstack_free in glibc).
So checking for _obstack_free seems correct. If you could sent a patch
(together with the argp check cleanup) to make the failure message to
also mention the underscore that would be great.
More information about the Elfutils-devel