[PATCH v2] Support building when fts and obstack aren't part of libc.

[Mark Wielaard]

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 [1] 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 [1] 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 [2], 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.

Thanks,

Mark