«

On Sat, 15 Jan 2011 15:08:17 -0500, Eric Sosman
<> wrote:

>On 1/15/2011 12:58 PM, hqin wrote:
>> 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.

On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin <>
wrote:

>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
>misc.c:748: error: conflicting types for ‘psort’
>/usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
>here
>make: *** [misc.o] Error 1


After the

#include <stdlib.h>

add

#undef psort

and then

#include "misc.h"

The "#undef psort" stops the psort being referenced from “stdlib.h”
so it can be referenced from "misc.h" and that makes for a happy
compiler.

On 1/16/2011 3:59 AM, Richard Sanders wrote:
> On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin<>
> wrote:
>
>> 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
>> misc.c:748: error: conflicting types for ‘psort’
>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
>> here
>> make: *** [misc.o] Error 1
>
>
> After the
>
> #include<stdlib.h>
>
> add
>
> #undef psort
>
> and then
>
> #include "misc.h"
>
> The "#undef psort" stops the psort being referenced from “stdlib.h”
> so it can be referenced from "misc.h" and that makes for a happy
> compiler.

It might be worth a try, but I doubt it will help. From the
wording of the error messages, it looks like `psort' has been
declared as an ordinary identifier, not as (or not only as) a
macro. The #undef will erase a macro definition, if there is
one, but will not affect the visibility of the plain identifier:

int x;
#undef x
double x; // error, despite the #undef

--
Eric Sosman
lid

hqin wrote:
> Here is my solution to this problem.
>
> First, I commented out the conflict definitions in <stdlib.h>. Then,
> "make" runs with some warnings. I tested the software using its
> example data, and it seems to be OK. So, I assume the software is
> compiled correctly.
>
> Then, to avoid causing problems to other software on my osX, I
> restored the original <stdlib.h> file.

I'd still suggest you try the -std=c99 option. Just modify the CFLAGS
line in the Makefile so it says

CFLAGS = -O3 -Wall -std=c99

If that fails too, try -ansi instead of -std=c99.
If it works, you'll have a simple way to compile the software without
touching either its code or your system files.
--
Marcin Grzegorczyk

On Jan 15, 9:58*am, hqin <qins...@gmail.com> wrote:
> 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
> misc.c:748: error: conflicting types for ‘psort’
> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
> here
> make: *** [misc.o] Error 1
>
> I am trying to compile a software CONSEL (http://www.is.titech.ac.jp/
> ~shimo/prog/consel/) on a Mac OsX system.
> I also tried an recent Ubuntu machine and received the same error.
> This is weir because Ubuntu is derived from Debian. Oddly enough, I
> tried on a old version of Ubuntu machine and the problem went away.
> (But this old machine is not usable for my computing project)
>
> The original software was developed in a Debian system. It would be
> great if I can use different gcc switches to get around this.
>
> I am glad that people have responded to this post even on a weekend.
> THANKS!
>

Unfortunately, Apple has decided to pollute the user namespace by
declaring
non-standard extensions psort, psort_b and psort_r in <stdlib.h> and
Ubuntu has
declared the non-standard dprintf in their header, even when there is
supposed to be a standardized method for naming non-standard
extensions.

Your safest and simplest method is to rename the CONSEL psort function
to
p_sort and be done with it. The name only occurs once in each of only
4
files in the source and it is far easier to edit this code than to
play
games with the "standard" headers of OS X, Debian, Ubuntu and all the
flavors of GCC floating around.

On Sun, 16 Jan 2011 11:35:07 -0800 (PST), None
<> wrote:

>On Jan 15, 9:58*am, hqin <qins...@gmail.com> wrote:
>> 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
>> misc.c:748: error: conflicting types for ‘psort’
>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
>> here
>> make: *** [misc.o] Error 1
>>
>> I am trying to compile a software CONSEL (http://www.is.titech.ac.jp/
>> ~shimo/prog/consel/) on a Mac OsX system.
>> I also tried an recent Ubuntu machine and received the same error.
>> This is weir because Ubuntu is derived from Debian. Oddly enough, I
>> tried on a old version of Ubuntu machine and the problem went away.
>> (But this old machine is not usable for my computing project)
>>
>> The original software was developed in a Debian system. It would be
>> great if I can use different gcc switches to get around this.
>>
>> I am glad that people have responded to this post even on a weekend.
>> THANKS!
>>
>
>Unfortunately, Apple has decided to pollute the user namespace by
>declaring
>non-standard extensions psort, psort_b and psort_r in <stdlib.h> and
>Ubuntu has
>declared the non-standard dprintf in their header, even when there is
>supposed to be a standardized method for naming non-standard
>extensions.
>
>Your safest and simplest method is to rename the CONSEL psort function
>to
>p_sort and be done with it. The name only occurs once in each of only
>4
>files in the source and it is far easier to edit this code than to
>play
>games with the "standard" headers of OS X, Debian, Ubuntu and all the
>flavors of GCC floating around.
>

On OS X, add -D_ANSI_SOURCE to your CFLAGS in the Makefile.

On Sun, 16 Jan 2011 08:30:01 -0500, Eric Sosman
<> wrote:

>On 1/16/2011 3:59 AM, Richard Sanders wrote:
>> On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin<>
>> wrote:
>>
>>> 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
>>> misc.c:748: error: conflicting types for ‘psort’
>>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
>>> here
>>> make: *** [misc.o] Error 1
>>
>>
>> After the
>>
>> #include<stdlib.h>
>>
>> add
>>
>> #undef psort
>>
>> and then
>>
>> #include "misc.h"
>>
>> The "#undef psort" stops the psort being referenced from “stdlib.h”
>> so it can be referenced from "misc.h" and that makes for a happy
>> compiler.
>
> It might be worth a try, but I doubt it will help. From the
>wording of the error messages, it looks like `psort' has been
>declared as an ordinary identifier, not as (or not only as) a
>macro. The #undef will erase a macro definition, if there is
>one, but will not affect the visibility of the plain identifier:
>
> int x;
> #undef x
> double x; // error, despite the #undef

You are trying to undef a variable not a function.

#undef psort

It is called function overriding and it does work and has for me since
my turbo c days.

Rather than ruminating just try it. The thing to remember is that the
#undef is only valid for the source file it appeares in.

On 1/16/2011 3:08 PM, Richard Sanders wrote:
> On Sun, 16 Jan 2011 08:30:01 -0500, Eric Sosman
> <> wrote:
>
>> On 1/16/2011 3:59 AM, Richard Sanders wrote:
>>> On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin<>
>>> wrote:
>>>
>>>> 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
>>>> misc.c:748: error: conflicting types for ‘psort’
>>>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
>>>> here
>>>> make: *** [misc.o] Error 1
>>>
>>>
>>> After the
>>>
>>> #include<stdlib.h>
>>>
>>> add
>>>
>>> #undef psort
>>>
>>> and then
>>>
>>> #include "misc.h"
>>>
>>> The "#undef psort" stops the psort being referenced from “stdlib.h”
>>> so it can be referenced from "misc.h" and that makes for a happy
>>> compiler.
>>
>> It might be worth a try, but I doubt it will help. From the
>> wording of the error messages, it looks like `psort' has been
>> declared as an ordinary identifier, not as (or not only as) a
>> macro. The #undef will erase a macro definition, if there is
>> one, but will not affect the visibility of the plain identifier:
>>
>> int x;
>> #undef x
>> double x; // error, despite the #undef
>
> You are trying to undef a variable not a function.

#undef does not apply to variables nor to functions, but to
macros. At the time #undef is processed (and at the time macros
are expanded), there is no difference between a "variable" and
a "function." Not even `int' has any meaning beyond than "I am a
three-character token."

> #undef psort
>
> It is called function overriding and it does work and has for me since
> my turbo c days.

I have no personal experience with Turbo C. However, no C
compiler I've ever used has processed #undef any differently for
macros whose names look like functions than for macros whose
names look like something else. Certainly no Standard-conforming
compiler has ever done so.

> Rather than ruminating just try it. The thing to remember is that the
> #undef is only valid for the source file it appeares in.

Good advice. What happened when you tried it?

--
Eric Sosman
lid

On Sun, 16 Jan 2011 15:26:11 -0500, Eric Sosman
<> wrote:

>On 1/16/2011 3:08 PM, Richard Sanders wrote:
>> On Sun, 16 Jan 2011 08:30:01 -0500, Eric Sosman
>> <> wrote:
>>
>>> On 1/16/2011 3:59 AM, Richard Sanders wrote:
>>>> On Sat, 15 Jan 2011 09:58:42 -0800 (PST), hqin<>
>>>> wrote:
>>>>
>>>>> 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
>>>>> misc.c:748: error: conflicting types for ‘psort’
>>>>> /usr/include/stdlib.h:310: error: previous declaration of ‘psort’ was
>>>>> here
>>>>> make: *** [misc.o] Error 1
>>>>
>>>>
>>>> After the
>>>>
>>>> #include<stdlib.h>
>>>>
>>>> add
>>>>
>>>> #undef psort
>>>>
>>>> and then
>>>>
>>>> #include "misc.h"
>>>>
>>>> The "#undef psort" stops the psort being referenced from “stdlib.h”
>>>> so it can be referenced from "misc.h" and that makes for a happy
>>>> compiler.
>>>
>>> It might be worth a try, but I doubt it will help. From the
>>> wording of the error messages, it looks like `psort' has been
>>> declared as an ordinary identifier, not as (or not only as) a
>>> macro. The #undef will erase a macro definition, if there is
>>> one, but will not affect the visibility of the plain identifier:
>>>
>>> int x;
>>> #undef x
>>> double x; // error, despite the #undef
>>
>> You are trying to undef a variable not a function.
>
> #undef does not apply to variables nor to functions, but to
>macros. At the time #undef is processed (and at the time macros
>are expanded), there is no difference between a "variable" and
>a "function." Not even `int' has any meaning beyond than "I am a
>three-character token."
>
>> #undef psort
>>
>> It is called function overriding and it does work and has for me since
>> my turbo c days.
>
> I have no personal experience with Turbo C. However, no C
>compiler I've ever used has processed #undef any differently for
>macros whose names look like functions than for macros whose
>names look like something else. Certainly no Standard-conforming
>compiler has ever done so.
>
>> Rather than ruminating just try it. The thing to remember is that the
>> #undef is only valid for the source file it appeares in.
>
> Good advice. What happened when you tried it?


It seems to work. Try my example.

#include <stdio.h>
#include <stdlib.h>

#undef printf
/*
** int printf (const char*, ...);
*/

int printf(const char* str, ...)
{
fprintf(stdout, "12345");
return 0;
}


int main()
{
printf("Hello world!\n");
return 0;
}

If the output is "12345" then my own version of printf is used and not
the library version. I got "12345". Had I got "Hello world!" then I
would be wrong and you would be right.

Also note that my implimentation uses the exact same declaration as in
the header file.

"#undef printf" means do not link the libray version, link the
supplied version, it has nothing to do with header files.

On Sun, 16 Jan 2011 15:26:11 -0500, Eric Sosman
<> wrote:
[snip]
>> You are trying to undef a variable not a function.
>
> #undef does not apply to variables nor to functions, but to
>macros.

In my previous post I forgot to aknowledge that if a function is
implimented as a #define then the macro is undefined.

The end result is the same. The library function is not linked and the
custom function is and that is the whole point of it, to be able to
replace library functions with a custom function.