This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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/ 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

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.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]