Re: [PATCH libctf] Fix a number of build problems found on Solaris and NetBSD

[Nick Alcock <nick dot alcock at oracle dot com>]

On 31 May 2019, John Marshall outgrape:

> ../../../binutils-gdb/libctf/qsort_r.c:33:21: note: expanded from macro '_quicksort'
> # define _quicksort qsort_r
> ^
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/stdlib.h:325:7: note:
> previous declaration is here
> void     qsort_r(void *__base, size_t __nel, size_t __width, void *,
> ^
>
> MacOS (and e.g. it appears FreeBSD, but there it is possibly hidden by a __BSD_VISIBLE define) declares a qsort_r() function with a different signature:
>
> 	void
> 	qsort_r(void *base, size_t nel, size_t width, void *thunk,
> 		int (*compar)(void *, const void *, const void *));
>
> i.e. the extra void* argument is added before the comparison function rather than after, and similarly in the callback's parameters.
>
> The generated libctf/config.h contains "#define HAVE_DECL_QSORT_R 1", so it's a bit surprising that it tries to build qsort_r.c at all. I suspect AC_LIBOBJ([qsort_r]) should be inside a conditional. However, even if qsort_r.o were properly omitted, trying to use the system qsort_r() with its different signature won't work.

Quite. I didn't realise qsort_r() was so nonportable that qsort_r()s
with entirely different type signatures were out there.

> Changing the identifier (e.g. to qsort_r_bork) in the four libctf/*.[ch] files it appears in leads to a working compilation.

Downside: this can be quite a *large* sort. Doing this would mean
eschewing the system qsort() at all times. Do we want to do that? (Is it
actually going to be any faster than gnulib's?)

> Incidentally, this warning seems accurate in saying this free() should be further down:
>
> ../../../binutils-gdb/libctf/ctf-dump.c:276:13: warning: variable 'bit' is uninitialized when used here

Ugh. Sorry, this was the most recently-written code in libctf and
sometimes that shows: in this case some late code motion on my part
shoved the free some lines up, to before its first allocation. (Freeing
a garbage pointer would cause obvious problems in real use, of course,
but the code that generates the function info section is still under
development...)

Will fix, of course. (I wonder why I haven't seen this warning with any
of the GCCs I've compiled it with... oh, this is one of the middle-end
warnings whose appearance depends on fine details of the optimizer,
right? That might explain it.)