: multiple definition of `main'

[a]

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?

 

[jameskuyper]

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.

 

[santosh]

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

/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 help in a group devoted to your platform or compiler.
GCC has several groups among which is <news:gnu.gcc.help>.

 

[jacob navia]

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

 

[Richard Tobin]

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

 

[jameskuyper]

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.

 

[a]

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

 

[Mark McIntyre]

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

Well spotted.

 

[CBFalconer]

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

 

[Bart]

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

 

[Kenneth Brody]

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:[email protected]>

 

[Kenny McCormack]

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.

 

[Richard Tobin]

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

[/QUOTE]

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