«

I am having problem to compile a software on my computers. The
software is written in C and it defines a function with the same name
in /usr/include/stdlib.h file.The compile complains about the
conflicted definition and bailed out.
This software is a mathematic software that I do not want to modify.
Is there a simple way to get around this problem?

Thanks.

On Jan 14, 7:28*pm, hqin <qins...@gmail.com> wrote:
> I am having problem to compile a software on my computers. The
> software is written in C and it defines a function with the same name
> in /usr/include/stdlib.h file.The compile complains about the
> conflicted definition and bailed out.
> This software is a mathematic software that I do not want to modify.
> Is there a simple way to get around this problem?
>
> Thanks.

What I do is prefix "k" to the name of any of the functions
I write which might conflict with a standard library function,
as in ksqrt(). Use your own initial, though.

Alternatively, maybe you can set your linker to use your function
instead.
Check the manual.

What is the code, anyway?

hqin <> writes:

> I am having problem to compile a software on my computers. The
> software is written in C and it defines a function with the same name
> in /usr/include/stdlib.h file.The compile complains about the
> conflicted definition and bailed out.
> This software is a mathematic software that I do not want to modify.
> Is there a simple way to get around this problem?

Maybe. More detail would help.

Sometimes this is simply due to using the wrong compiler options -- for
example permitting language extensions rather using standard C. It
would help if you said what the function is and what compiler switches
you use (and which ones you think you need).

--
Ben.

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!


On Jan 14, 10:17*pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> hqin <qins...@gmail.com> writes:
> > I am having problem to compile a software on my computers. The
> > software is written in C and it defines a function with the same name
> > in /usr/include/stdlib.h file.The compile complains about the
> > conflicted definition and bailed out.
> > This software is a mathematic software that I do not want to modify.
> > Is there a simple way to get around this problem?
>
> Maybe. *More detail would help.
>
> Sometimes this is simply due to using the wrong compiler options -- for
> example permitting language extensions rather using standard C. *It
> would help if you said what the function is and what compiler switches
> you use (and which ones you think you need).
>
> --
> Ben.

Here is the Makefile

CC = gcc
#CFLAGS = -g -Wall
CFLAGS = -O3 -Wall
LDLIBS = -lm


targets= makermt catpv catci catrep treeass consel randrep catmt seqmt
makerep catass
objects= misc.o rand.o tree.o freadmat.o opt.o mt19937.o
bindir=../bin

all: $(targets)

makermt: misc.o rand.o freadmat.o mt19937.o
catpv: misc.o
treeass: tree.o misc.o
consel: misc.o rand.o opt.o mt19937.o
catmt: misc.o rand.o mt19937.o
seqmt: freadmat.o misc.o

makerep: misc.o rand.o freadmat.o mt19937.o
catci: misc.o
catrep: misc.o
catass: misc.o
randrep: misc.o rand.o mt19937.o

test: rand.o misc.o mt19937.o
tabpv1: misc.o
tabpv2: misc.o
tabpv4: misc.o

Weird. I tried it on an Ubuntu machine,
and here's what happened:

$ make

gcc -O3 -Wall -c -o misc.o misc.c
In file included from misc.c:21:
misc.h:19: error: conflicting types for ‘dprintf’
/usr/include/stdio.h:397: note: previous declaration of ‘dprintf’ was
here
misc.c:30: error: conflicting types for ‘dprintf’
/usr/include/stdio.h:397: note: previous declaration of ‘dprintf’ was
here
make: *** [misc.o] Error 1

So... I would contact the maintainer of the software, if I were you.

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.

--
Eric Sosman
lid

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 also emailed the author of the software.

Thanks to everyone that have responded. Enjoy the rest of the weekend.

Hong Qin

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.

Can you provide a reference that indicates `psort' is a GNU or gcc
extension? I've seen web pages that refer to BSD and Mac but not GNU.

> Unfortunately, I sort of suspect this won't solve the problem
> altogether. In light of the report elsethread that `dprintf' is also
> doubly declared, [...]

For `dprintf' it's clear that both GNU and Apple are guilty of
extension. According to "info dprintf" on linux,

"These functions are GNU extensions, not in C or POSIX.
Clearly, the names were badly chosen. Many systems (like
MacOS) have incompatible functions called dprintf(),
usually some debugging version of printf() ..."

--
jiw

On 1/15/2011 7:35 PM, James Waldby wrote:
> 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. [...]
>
> Can you provide a reference that indicates `psort' is a GNU or gcc
> extension? I've seen web pages that refer to BSD and Mac but not GNU.

It's not really a matter of which extension or addition or
decoration `psort' belongs to: The point is that the C Standard
does not list `psort' as one of the identifiers <stdlib.h> is
allowed to declare. It is an identifier in the programmer's "name
space," an identifier the programmer must be able to use freely
without fear that <stdlib.h> or <ctype.h> or <whatever.h> or the
compiler itself will somehow use in a conflicting way. As a
programmer, you can use `x' in any way you choose; same with `psort'.

>> Unfortunately, I sort of suspect this won't solve the problem
>> altogether. In light of the report elsethread that `dprintf' is also
>> doubly declared, [...]
>
> For `dprintf' it's clear that both GNU and Apple are guilty of
> extension. According to "info dprintf" on linux,
>
> "These functions are GNU extensions, not in C or POSIX.
> Clearly, the names were badly chosen. Many systems (like
> MacOS) have incompatible functions called dprintf(),
> usually some debugging version of printf() ..."

It's a continuing problem. The C Standard recognizes only two
classes of code-writers: "implementors" and "users." The Standard
carefully divides the identifier name space into three parts, like
Caesar's Gaul: (1) identifiers that the implementors must provide
and that the users can rely upon, (2) identifiers the implementors
can use for whatever purposes they please, and (3) identifiers that
the users can employ for whatever purposes *they* please. This gives
a measure of sanity: The users can be sure that the implementors will
not misappropriate `farthingale', and the implementors can be sure
that the users will not try to use `EFFORT'. (Yes, the division is
sometimes very peculiar; put it down to "hysterical raisins.")

*But* the Standard offers no way for different groups of "users"
to identify themselves and to avoid trampling on each other's names.
If you want to use a popular extension like POSIX, you must give up
on trying to use `fork' as an identifier of your own. If you want to
use the Fastest Fourier Transform in the West, you must avoid trying
to use `fftw_complex' for your own purposes. Eventually, you will
surely find that extension A and library B both define `dingbat', and
do so incompatibly. The "badly chosen" names mentioned in the man
page are really not the fault of the choosers; it is inevitable that
conflicts of this kind will arise. And C per se offers no solution.

C'est la vie.

--
Eric Sosman
lid