Don't know why this compilation generated, I'm sure no 2 mains exist:

make votei
gcc vote.c datamanager.c -o votei vote.c -L. -lhungarian
vote.c: In function `main':
vote.c:254: warning: passing arg 2 of `hungarian_init' from incompatible
pointer type
vote.c: In function `main':
vote.c:254: warning: passing arg 2 of `hungarian_init' from incompatible
pointer type
/tmp/ccsVGl95.o(.text+0x0): In function `main':
: multiple definition of `main'
/tmp/ccSVKJyx.o(.text+0x0): first defined here
collect2: ld returned 1 exit status
make: *** [votei] Error 1


Makefile:
CC = gcc
AR = ar

CFLAGS = -O3 -Wall -I.
LDFLAGS = -L. -lhungarian

all: libhungarian.a hungarian_test

votei: vote.c datamanager.c $(HUNGARIANLIB)
$(CC) $(CFLAGS) vote.c datamanager.c assignmentoptimal.c -o $@ $<
$(LDFLAGS)

votei: vote.c datamanager.c $(HUNGARIANLIB)
$(CC) vote.c datamanager.c -o $@ $< $(LDFLAGS)

why comp.lang.c faq hasn't covered compilation topic? Where should I go for
more information?

a wrote:
> Don't know why this compilation generated, I'm sure no 2 mains exist:

You may be sure of this fact, but gcc seems to disagree. It would be
much easier to figure out whether you or gcc is right, if you had
actually bothered to give us copies of your code.

a wrote:

> Don't know why this compilation generated, I'm sure no 2 mains exist:

<snip>

> /tmp/ccsVGl95.o(.text+0x0): In function `main':
> : multiple definition of `main'
> /tmp/ccSVKJyx.o(.text+0x0): first defined here
> collect2: ld returned 1 exit status
> make: *** [votei] Error 1

<snip>

The above message clearly shows that two different object files are
exporting main() and therefore the linker is unable to decide which one
to use.

I am guessing that there is some mistake somewhere in your makefile or
conditional compilation directives that is allowing this to happen.

Without more information and relevant code we really cannot say anything
further.

> why comp.lang.c faq hasn't covered compilation topic? Where should I
> go for more information?

The comp.lang.c FAQ does not cover "compilation" because the details are
inherently implementation specific and this group tries to restrict
itself to Standard C. There are simply too many compilers with too many
idiosyncrasies to deal with in a FAQ.

You should ask for in a group devoted to your platform or compiler.
GCC has several groups among which is <news:gnu.gcc.>.

a wrote:
> Don't know why this compilation generated, I'm sure no 2 mains exist:
>
> make votei
> gcc vote.c datamanager.c -o votei vote.c -L. -lhungarian

You have vote.c TWICE in the command line. Hence you define
main twice...



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

In article <5ef5451a-ba22-4654-a02a-e1873e3a16b1@b40g2000prf.googlegroups.com>,
<jameskuyper@verizon.net> wrote:
>a wrote:

>You may be sure of this fact, but gcc seems to disagree. It would be
>much easier to figure out whether you or gcc is right, if you had
>actually bothered to give us copies of your code.

Actually, he gave us all the information we need, as Jacob spotted.

-- Richard


--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

Richard Tobin wrote:
> In article <5ef5451a-ba22-4654-a02a-e1873e3a16b1@b40g2000prf.googlegroups.com>,
> <jameskuyper@verizon.net> wrote:
> >a wrote:
>
> >You may be sure of this fact, but gcc seems to disagree. It would be
> >much easier to figure out whether you or gcc is right, if you had
> >actually bothered to give us copies of your code.
>
> Actually, he gave us all the information we need, as Jacob spotted.

You're right - I should have read more carefully.

Still, he should have provided source code, just in case the problem
was in the code itself, and not on the command line.

Yes you are right. It is nothing dealt with the codes...

jacob navia wrote:
> a wrote:
>> Don't know why this compilation generated, I'm sure no 2 mains exist:
>>
>> make votei
>> gcc vote.c datamanager.c -o votei vote.c -L. -lhungarian
>
> You have vote.c TWICE in the command line. Hence you define
> main twice...

Well spotted.

a wrote:
>
> Yes you are right. It is nothing dealt with the codes...

Meaningless. See below.

--
If you want to post a followup via groups.google.com, ensure
you quote enough for the article to make sense. Google is only
an interface to Usenet; it's not Usenet itself. Don't assume
your readers can, or ever will, see any previous articles.
More details at: <http://cfaj.freeshell.org/google/>



--
Posted via a free Usenet account from http://www.teranews.com

On Nov 29, 12:18 am, Mark McIntyre <markmcint...@spamcop.net> wrote:
> jacob navia wrote:
> > a wrote:
> >> Don't know why this compilation generated, I'm sure no 2 mains exist:
>
> >> make votei
> >> gcc vote.c datamanager.c -o votei vote.c -L. -lhungarian
>
> > You have vote.c TWICE in the command line. Hence you define
> > main twice...
>
> Well spotted.

I suppose it's out of the question for gcc to detect duplicate source
filenames? (Comparing 2 filespecs is that trivial but for something as
sophisticated as gcc?..)

Bart

Bart wrote:
>
> On Nov 29, 12:18 am, Mark McIntyre <markmcint...@spamcop.net> wrote:
> > jacob navia wrote:
> > > a wrote:
> > >> Don't know why this compilation generated, I'm sure no 2 mains exist:
> >
> > >> make votei
> > >> gcc vote.c datamanager.c -o votei vote.c -L. -lhungarian
> >
> > > You have vote.c TWICE in the command line. Hence you define
> > > main twice...
> >
> > Well spotted.
>
> I suppose it's out of the question for gcc to detect duplicate source
> filenames? (Comparing 2 filespecs is that trivial but for something as
> sophisticated as gcc?..)

While this is OT here, what happens with something like:

gcc file.c -DSOMETHING file.c

Perhaps file.c will compile differently in the second case, due to
SOMETHING now being defined. (Not that I'm advocating this to be
good practice in a real-world environment, mind you.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:ThisIsASpamTrap@gmail.com>

In article <474EF153.8242C62F@spamcop.net>,
Kenneth Brody <kenbrody@spamcop.net> wrote:
>Bart wrote:
>>
>> On Nov 29, 12:18 am, Mark McIntyre <markmcint...@spamcop.net> wrote:
>> > jacob navia wrote:
>> > > a wrote:
>> > >> Don't know why this compilation generated, I'm sure no 2 mains exist:
>> >
>> > >> make votei
>> > >> gcc vote.c datamanager.c -o votei vote.c -L. -lhungarian
>> >
>> > > You have vote.c TWICE in the command line. Hence you define
>> > > main twice...
>> >
>> > Well spotted.
>>
>> I suppose it's out of the question for gcc to detect duplicate source
>> filenames? (Comparing 2 filespecs is that trivial but for something as
>> sophisticated as gcc?..)
>
>While this is OT here, what happens with something like:
>
> gcc file.c -DSOMETHING file.c
>
>Perhaps file.c will compile differently in the second case, due to
>SOMETHING now being defined. (Not that I'm advocating this to be
>good practice in a real-world environment, mind you.)

Right - that's the counter-example. It is certainly possible to create
a fully conforming situation where something would be broken if the
compiler refused to do what it is told.

In article <fin5gv$8e8$1@news.xmission.com>,
Kenny McCormack <gazelle@xmission.xmission.com> wrote:

>>While this is OT here, what happens with something like:
>>
>> gcc file.c -DSOMETHING file.c
>>
>>Perhaps file.c will compile differently in the second case, due to
>>SOMETHING now being defined. (Not that I'm advocating this to be
>>good practice in a real-world environment, mind you.)

>Right - that's the counter-example.

It *would* be the counter-example if gcc treated the order of -D
arguments and filenames as significant, but it doesn't.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.