[PATCH libctf] Fix a number of build problems found on Solaris and NetBSD
Sat Jun 1 10:19:00 GMT 2019
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:
> 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
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.)
More information about the Binutils