Here is the compiling error:
ace:src hqin$ make
gcc -O3 -Wall -c -o misc.o misc.c
In file included from misc.c:21:
misc.h:106: error: conflicting types for ‘psort’
/usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
here
[...]
A Standard-conforming <stdlib.h> must not even mention `psort',
much less declare it. However, gcc's default mode of operation is
not Standard-conforming: it compiles a sort of C-with-extras dialect
rather than C. If you provide the right compilation flags, gcc will
at least attempt to conform to the Standard, and in this mode will
almost certainly not declare `psort' in <stdlib.h>. Try adding the
`-ansi -pedantic' flags (or `-std=c99 -pedantic' if the code is
fairly new). You may need to remove `-pedantic', as lots of code
isn't clean enough for it, but you'll surely need one of the others.
Unfortunately, I sort of suspect this won't solve the problem
altogether. In light of the report elsethread that `dprintf' is also
doubly declared, it may turn out that the code contains its own
"free-hand" declarations of these identifiers, and expects to find
them in a library. If that's the case, the real cure is probably to
drop `-ansi' (or `-std=c99') and to delete the offending declarations
from the source. But try changing the flags first: Cross the other
bridge only if you actually come to it.
It appears to be an Apple extension in OS X 10.6.x that didn't appear
in OS X 10.4.x. Their man page reads (reformatted):
PSORT(3) BSD Library Functions Manual PSORT(3)
NAME
psort, psort_b, psort_r -- parallel sort functions
SYNOPSIS
#include <stdlib.h>
void
psort(void *base, size_t nel, size_t width,
int (*compar)(const void *, const void *));
void
psort_b(void *base, size_t nel, size_t width,
int (^compar)(const void *, const void *));
void
psort_r(void *base, size_t nel, size_t width, void *thunk,
int (*compar)(void *, const void *, const void *));
DESCRIPTION
The psort(), psort_b(), and psort_r() functions are parallel sort
routines that are drop-in compatible with the corresponding
qsort() function (see qsort(3) for a description of the
arguments). On multi-processor machines, multiple threads may be
created to simultaneously perform the sort calculations,
resulting in an overall faster sort result. Overhead in managing
the threads limits the maximum speed improvement to somewhat less
that the number of processors available. For example, on a
4-processor machine, a typical sort on a large array might result
in 3.2 times faster sorting than a regular qsort().
RESTRICTIONS
Because of the multi-threaded nature of the sort, the comparison
function is expected to perform its own synchronization that
might be required for data physically outside the two objects
passed to the comparison function. However, no synchronization
is required for the two object themselves, unless some third
party is also accessing those objects.
Additional memory is temporary allocated to deal with the
parallel nature of the computation.
Because of the overhead of maintaining multiple threads, the
psort() family of routines may choose to just call qsort(3) when
there is no advantage to parallelizing (for example, when the
number of objects in the array is too small, or only one
processor is available).
Like qsort(3), the sort is not stable.
RETURN VALUES
The psort(), psort_b() and psort_r() functions return no value.
SEE ALSO
qsort(3)
Mac OS X Nov 25, 2008 Mac OS X
I doesn't matter what dialect you choose.
