Question about multiple definition and undefined reference

[PCHOME]

Hi!

Would someone please help me thess C error(in gcc on Linux)?

The compiler continues to give me:
readLP.o: In function `Input_Problem':
readLP.o(.text+0x0): multiple definition of `Input_Problem'
main.o(.text+0x2f2): first defined here
/usr/bin/ld: Warning: size of symbol `Input_Problem' changed from 172
to 185 in
readLP.o
readLP.o: In function `Input_Problem':
readLP.o(.text+0x28): undefined reference to `max_no_row'
readLP.o(.text+0x2e): undefined reference to `max_no_col'
readLP.o(.text+0x74): undefined reference to `read_problem'
collect2: ld returned 1 exit status.
What happens?
Thank you so much!

I have 4 files in my code, they are:
main1.c, main1.h, readLP.c, and readLP.h.

/************************************************** *******************/
In main.c file:

#include "main1.h"
int max_no_col, max_no_row;
int read_problem(char *file); /* prototype */
extern int Input_Problem(void);

int main (int argc, char **argv)
{

max_no_col = MAX_NUMCOLS;
max_no_row = MAX_NUMROWS;
Input_Problem(); /* call sub-routine */
...
}

int read_problem(char *file) {
......
}
/************************************************** *******************/
/************************************************** *******************/
In readLP.c file:
#include "readLP.h"
int Input_Problem(void);
extern int read_problem(char *file); /* prototype */
extern int max_no_col, max_no_row;
extern double (*A)[ ];
.....
int Input_Problem( )
{

};
/************************************************** *******************/

/************************************************** *******************/
In main.h file:
#define MAX_NUMROWS 181010
#define MAX_NUMCOLS 201
double (*A)[MAX_NUMCOLS];
.....
/************************************************** *******************/

Thanks again!

[Joe Estock]

PCHOME wrote:

Hi!

Would someone please help me thess C error(in gcc on Linux)?

The compiler continues to give me:
readLP.o: In function `Input_Problem':
readLP.o(.text+0x0): multiple definition of `Input_Problem'
main.o(.text+0x2f2): first defined here
/usr/bin/ld: Warning: size of symbol `Input_Problem' changed from 172
to 185 in
readLP.o
readLP.o: In function `Input_Problem':
readLP.o(.text+0x28): undefined reference to `max_no_row'
readLP.o(.text+0x2e): undefined reference to `max_no_col'
readLP.o(.text+0x74): undefined reference to `read_problem'
collect2: ld returned 1 exit status.
What happens?
Thank you so much!

I have 4 files in my code, they are:
main1.c, main1.h, readLP.c, and readLP.h.

/************************************************** *******************/
In main.c file:

#include "main1.h"
int max_no_col, max_no_row;
int read_problem(char *file); /* prototype */
extern int Input_Problem(void);

int main (int argc, char **argv)
{

max_no_col = MAX_NUMCOLS;
max_no_row = MAX_NUMROWS;
Input_Problem(); /* call sub-routine */
...
}

int read_problem(char *file) {
.....
}
/************************************************** *******************/
/************************************************** *******************/
In readLP.c file:
#include "readLP.h"
int Input_Problem(void);
extern int read_problem(char *file); /* prototype */
extern int max_no_col, max_no_row;
extern double (*A)[ ];
....
int Input_Problem( )
{

};
/************************************************** *******************/

/************************************************** *******************/
In main.h file:
#define MAX_NUMROWS 181010
#define MAX_NUMCOLS 201
double (*A)[MAX_NUMCOLS];
....
/************************************************** *******************/

Thanks again!

Honestly you should structure your code better. This code is not layed
out well at all. Also, you are including "main1.h" in what is presumed
to be main.c, however you have shown us main.h and not main1.h. You are
declaring the prototype at the top of main.c, however you should have a
separate header file that goes along with your implementation file and
define it there. I think the problem is that you have a mess of code and
are trying to solve a problem that could easily be solved by writing
more manageable code.

Joe Estock

[Emmanuel Delahaye]

PCHOME wrote on 11/04/05 :

Would someone please help me thess C error(in gcc on Linux)?

The compiler continues to give me:
readLP.o: In function `Input_Problem':
readLP.o(.text+0x0): multiple definition of `Input_Problem'
main.o(.text+0x2f2): first defined here
/usr/bin/ld: Warning: size of symbol `Input_Problem' changed from 172
to 185 in
readLP.o
readLP.o: In function `Input_Problem':
readLP.o(.text+0x28): undefined reference to `max_no_row'
readLP.o(.text+0x2e): undefined reference to `max_no_col'
readLP.o(.text+0x74): undefined reference to `read_problem'
collect2: ld returned 1 exit status.
What happens?
Thank you so much!

I have 4 files in my code, they are:
main1.c, main1.h, readLP.c, and readLP.h.

You code organisation seems to be erratic and random...

The Good Way (c) rules are simple.

1 - The main() function is defined on a source file called 'main.c'. It
is the last function of the source file.

/* main.c */

/* ... */

int main (void)
{
/* ... */
return 0;
}

2 - the main() functions cal call local functions qualified 'static'
and defined before it.

/* main.c */

static void f (int x)
{
/* ... */
}

int main (void)
{
/* ... */

f (123);

return 0;
}

3 - the external functions are regrouped by functionnal affinities as a
'Functionnal Block' (E.g. : my_fb). The implementatation of the
function is placed into a my_fb.c file and the interfaces (prototypes
and all what is necessary) are placed into a header file (my_fb.h). The
header file is protected against multiple inclusions. It is included
into the implementation file and into the user's file when needed.

/* my_fb.h */
#ifndef H_MY_FB
#define H_MY_FB

/* prototypes */
void my_fb_f (int x);

/* ... */

#endif /* guard */

/* my_fb.c*/
#include "my_fb.c"

/* public functions */
void my_fb_f (int x)
{
/* ... */
}

/* main.c */
#include "my_fb.c"

static void f (int x)
{
/* ... */
}

int main (void)
{
/* ... */

f (123);

my_fb_f (456);

return 0;
}

5- Global variables should be avoided. If there is no choice, the
definition of the variable is placed into a source file (.c) and its
external declaration is placed into a header file (.h).

/* my_fb.h */
#ifndef H_MY_FB
#define H_MY_FB

/* prototypes */
void my_fb_f (int x);

/* public variables */

extern int my_fb_g;

#endif /* guard */

/* my_fb.c*/
#include "my_fb.c"

/* public functions */

void my_fb_f (int x)
{
my_fb_g += x;
}

/* public variables */

int my_fb_g;
/* main.c */
#include "my_fb.c"

static void f (int x)
{
my_fb_g /= x;
}

/* public functions */

int main (void)
{
/* ... */

my_fb_g = 789;

f (123);

my_fb_f (456);

return 0;
}

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

I once asked an expert COBOL programmer, how to
declare local variables in COBOL, the reply was:
"what is a local variable?"

[Joe Estock]

Emmanuel Delahaye wrote:
[snip 115 lines]

/* main.c */
#include "my_fb.c"
[snip 33 lines] /* my_fb.c*/
#include "my_fb.c"

[snip 35 lines]

Correct except that we do not include source files within other source
files, we include header files instead. The above should be:

/* main.c */
#include "my_fb.h"

/* my_fb.c */
#include "my_fb.h"

Header files should contain the prototypes and constants (and/or macros)
and nothing else (except for external references to variables when
necessary).

Joe Estock

[Walter Roberson]

In article <Hxz6e.6323$GJ.4833@attbi_s71>,
Joe Estock <je*****@NOSPAMnutextonline.com> wrote:

Correct except that we do not include source files within other source
files, we include header files instead. Header files should contain the prototypes and constants (and/or macros)
and nothing else (except for external references to variables when
necessary).

Sorry, Joe, that disagrees with the C89 standard. The description
of #include says clearly that it may be used for header -or- source
files. There is also nothing special about .h vs .c .

The C89 standard says that the implimentation shall define
a unique mapping for filenames (possibly case insensitive) of
up to 6 letters followed by a period followed by a single letter.
It does not give special meaning to .h other than with respect to
using .h in the names of the standard include files.
--
Walter Roberson is my name,
And Usenet is my nation.
Cyber space is my dwelling place,
And flames my destination.

[Gordon Burditt]

>>Correct except that we do not include source files within other source

files, we include header files instead.

Header files should contain the prototypes and constants (and/or macros)
and nothing else (except for external references to variables when
necessary).

Sorry, Joe, that disagrees with the C89 standard. The description

One of you is talking about coding style, and the other about what
the standard allows. C89 does not *REQUIRE* you to include source
files containing code (but it doesn't prohibit it either). On
occasion I have found a use for including a *generated* source
file inside another file, e.g.:

#include "structs.h"
struct TranslateTable[] = {
#include "translate.c"
};

where translate.c contains a bunch of computed numbers generated by
another program and as few program-specific things (like the
name of the struct or header file with its definition) as possible,
since the table generator is supposed to be relatively general.
This is fairly unusual, but it does have its uses.
of #include says clearly that it may be used for header -or- source
files. There is also nothing special about .h vs .c .

There are coding conventions about this - that's what is special.
Nowhere does C89 suggest that variable names should be shorter than
80 characters and consist of something other than underscore-separated
cusswords, but most code does this anyway. Nowhere does C89 suggest
that variable names should be meaningful, either.

Gordon L. Burditt

[Walter Roberson]

In article <11*************@corp.supernews.com>,
Gordon Burditt <go***********@burditt.org> wrote:

C89 does not *REQUIRE* you to include source
files containing code (but it doesn't prohibit it either).
Right.
On
occasion I have found a use for including a *generated* source
file inside another file, e.g.:

It is also sometimes useful to include source in header files
for portability reasons; e.g., if a particular function does not
happen to be defined in the compile environment, then define it.
One must, naturally, be careful with this as one does not wish to
end up defining the same function in multiple locations.

There just isn't a hard edge between "source" and "header" files;
there is a bit of blurryness at the boundary.
--
Studies show that the average reader ignores 106% of all statistics
they see in .signatures.

[Emmanuel Delahaye]

Joe Estock wrote on 11/04/05 :

Emmanuel Delahaye wrote:
[snip 115 lines]

/* main.c */
#include "my_fb.c"

[snip 33 lines]

/* my_fb.c*/
#include "my_fb.c"

Oops! Yeat another victim of copy and paste... Good catch.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair

[Gordon Burditt]

>>On

occasion I have found a use for including a *generated* source
file inside another file, e.g.:
It is also sometimes useful to include source in header files
for portability reasons; e.g., if a particular function does not
happen to be defined in the compile environment, then define it.
One must, naturally, be careful with this as one does not wish to
end up defining the same function in multiple locations.

I don't like this approach, for exactly the reason you mention: you
may end up defining the same function multiple times. At worst,
you get a "multiply defined symbol" error from the linker. At best,
you get several copies of the same function. If this function has
static variables (which you now have multiple independent instances
of), it may not work correctly. If it doesn't have static variables,
it should work but it's just bloat.

You should be able to include a header file (one that's part of the
code for whatever it is) in more than one source file without grief.
That's another style issue. Oh, yes, you should be able to include
it more than once in the same source file also (include guards).
There just isn't a hard edge between "source" and "header" files;
there is a bit of blurryness at the boundary.

If I have a copy of some function that may or may not be
present on a particular implementation, it will probably be
in a .c file:

#include "config.h"
#ifdef NEED_STRDUP
.... guts of strdup() function ...
#endif

and, assuming that it's generally agreed what the interface for
strdup() looks like, I can put a prototype for it in a header file
without conditionals. If the system strdup() happens to have the
prototype: double **strdup(FILE *, long *, ...) and I expect the
system-supplied one to have char *strdup(const char *), then hopefully
I'll get a compile-time error since using the system-supplied one
as though it mimicked the behavior of mine is obviously the wrong
thing to do.

config.h above may be set up manually for the particular system,
or it might be generated by something like GNU autoconf.

Gordon L. Burditt

[PCHOME]

Thanks for the help from all of you!

[Martin Ambuhl]

PCHOME wrote:

Hi!

Would someone please help me thess C error(in gcc on Linux)?
Toyr errors include claiming to have 4 files and actually having only 3
(no readLP.h), including the non-existant header readLP.h, claiming to
have a file main1.h, while actually having main.h, having erroneous
lines like ... having a prototype of int Input_Problem(void); while having a function definition of int Input_Problem( )
{

};

(which does not return the promised int).

Please post some actual code that demonstrates your problem.