problem with compilation

[foodic]

Hi all
I have a little bit of programming experience on windows 98 using C.
But this is my first attempt to compile a program on
Linux using gcc.I have two files s1.c and s1.h and while
compiling i am getting compilation problem,
here is the content of s1.c

#include <stdio.h>
#include <s1.h>
void hi();
int main(){
hi();
}
here is the content of s1.h
void hi(){
printf ("Hi all\n");
}

when i compile this program,

gcc s1.c
it gives error like,
s1.c:2:16: s1.h: No such file or directory


and also i have tried
gcc s1.h s1.c
it gives error like,

gcc: compilation of header file requested
s1.c:2:16: s1.h: No such file or directory

Please somebody explain how to compile it

thanks
divya

[Helmut Weber]

Re: problem with compilation

The include-statement is wrong. You have to
use

#include "s1.h"

instead of

#include <s1.h>

because s1.h is no system include file, but resides in your own
working directory.

Compile with: gcc s1.c

Regards
Helmut Weber

"foodic" <divya_oliva_fe rnadez@yahoo.co .in> schrieb im Newsbeitrag
news:47d335da.0 503200524.68242 ffb@posting.goo gle.com...[color=blue]
> Hi all
> I have a little bit of programming experience on windows 98 using C.
> But this is my first attempt to compile a program on
> Linux using gcc.I have two files s1.c and s1.h and while
> compiling i am getting compilation problem,
> here is the content of s1.c
>
> #include <stdio.h>
> #include <s1.h>
> void hi();
> int main(){
> hi();
> }
> here is the content of s1.h
> void hi(){
> printf ("Hi all\n");
> }
>
> when i compile this program,
>
> gcc s1.c
> it gives error like,
> s1.c:2:16: s1.h: No such file or directory
>
>
> and also i have tried
> gcc s1.h s1.c
> it gives error like,
>
> gcc: compilation of header file requested
> s1.c:2:16: s1.h: No such file or directory
>
> Please somebody explain how to compile it
>
> thanks
> divya[/color]

[Joe Wright]

Re: problem with compilation

foodic wrote:[color=blue]
> Hi all
> I have a little bit of programming experience on windows 98 using C.
> But this is my first attempt to compile a program on
> Linux using gcc.I have two files s1.c and s1.h and while
> compiling i am getting compilation problem,
> here is the content of s1.c
>
> #include <stdio.h>
> #include <s1.h>
> void hi();
> int main(){
> hi();
> }
> here is the content of s1.h
> void hi(){
> printf ("Hi all\n");
> }
>
> when i compile this program,
>
> gcc s1.c
> it gives error like,
> s1.c:2:16: s1.h: No such file or directory
>
>
> and also i have tried
> gcc s1.h s1.c
> it gives error like,
>
> gcc: compilation of header file requested
> s1.c:2:16: s1.h: No such file or directory
>
> Please somebody explain how to compile it
>
> thanks
> divya[/color]

You need a better C book. Headers should not contain function
definitions (or any other definitions). Headers are for declarations.
And yes, '#define FOO 10' is a declaration, not a definition. Hence s1.h
is useless and even an error. s1.c should look like..

#include <stdio.h>

void hi(void) {
printf("Hi all\n");
}

int main(void) {
hi();
return 0;
}

If you want to complicate it a little, arrange for hi() to be in s1.c
after main() and provide s1.h to declare the prototype. So s1.h looks like..

#ifndef S1_H
#define S1_H
void hi(void);
#endif

... and s1.c looks like ..

#include <stdio.h>
#include "s1.h"

int main(void) {
hi();
return 0;
}

void hi(void) {
printf("Hi all\n");
}

"The C Programming Language", Second Edition, Kernighan and Ritchie will
cost you about $40 and will be the best money you've spent (if you read
the book).
--
Joe Wright mailto:joewwrig ht@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[pete]

Parts of a C program, Re: problem with compilation

Joe Wright wrote:
[color=blue]
> You need a better C book. Headers should not contain function
> definitions (or any other definitions). Headers are for declarations.
> And yes, '#define FOO 10' is a declaration, not a definition.
> Hence s1.h is useless and even an error. s1.c should look like..[/color]

Definitions are also declarations, which is why CBFalconer
likes to put the definitions of other functions, above main.

#define FOO 10 is a preprocessor directive.

Each byte in a C program is one of 4 things:
1 part of a comment
2 part of a preprocessor directive
3 part of an external declaration
4 all other bytes in a C program are white space

Function definitions are unique among declarations in two ways:
1 they are not terminated by a semicolon ;
2 they are always external

--
pete

[Martin Ambuhl]

Re: problem with compilation

foodic wrote:[color=blue]
> Hi all
> I have a little bit of programming experience on windows 98 using C.
> But this is my first attempt to compile a program on
> Linux using gcc.I have two files s1.c and s1.h and while
> compiling i am getting compilation problem,
> here is the content of s1.c
>
> #include <stdio.h>
> #include <s1.h>[/color]
#include "s1.h"
and make sure the include path is correct. The way to do this is
covered in your documentation. If that documentation is insufficiently
clear, ask about it in a newsgroup like
gnu.gcc.help
or
linux.dev.gcc

[color=blue]
> void hi();[/color]

This should be in s1.h, so is unneeded here.
[...]
[color=blue]
> here is the content of s1.h
> void hi(){[/color]
Specifying no arguments, 'void ji(void)' is a good idea.
[color=blue]
> printf ("Hi all\n");
> }[/color]

headers are not the place to put definitions of functions or objects.
Put this is a separate compilation unit (*.c file); "s1.h" should have
simply
void hi(void);

[CBFalconer]

Re: Parts of a C program, Re: problem with compilation

pete wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> Function definitions are unique among declarations in two ways:
> 1 they are not terminated by a semicolon ;
> 2 they are always external[/color]

static int foo(...) {...} /* not exactly external */
static int bar(...); /* forward declaration, not external */

--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

[Joe Wright]

Re: Parts of a C program, Re: problem with compilation

pete wrote:[color=blue]
> Joe Wright wrote:
>
>[color=green]
>>You need a better C book. Headers should not contain function
>>definitions (or any other definitions). Headers are for declarations.
>>And yes, '#define FOO 10' is a declaration, not a definition.
>>Hence s1.h is useless and even an error. s1.c should look like..[/color]
>
>
> Definitions are also declarations, which is why CBFalconer
> likes to put the definitions of other functions, above main.
>[/color]

Like CBFalconer, I do that too, all the time. Nowhere do I say that a
definition is not a declaration.
[color=blue]
> #define FOO 10 is a preprocessor directive.
>[/color]

Of course it is. Declarations refer to variables and other objects. I
was making the point that #define doesn't indicate a definition of an
object and therefore create memory for it.
[color=blue]
> Each byte in a C program is one of 4 things:
> 1 part of a comment
> 2 part of a preprocessor directive
> 3 part of an external declaration
> 4 all other bytes in a C program are white space
>[/color]

Nonsense. I give you 1, 2 and 4 but your item 3 is too much. What part of ..

static int foo;

... is an external declaration?
[color=blue]
> Function definitions are unique among declarations in two ways:
> 1 they are not terminated by a semicolon ;[/color]

Yes.
[color=blue]
> 2 they are always external[/color]

Nonsense. They are external by default unless qualified 'static', in
which case they are not external.

--
Joe Wright mailto:joewwrig ht@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[CBFalconer]

Re: Parts of a C program, Re: problem with compilation

Joe Wright wrote:[color=blue]
> pete wrote:[color=green]
>>[/color][/color]
.... snip ...[color=blue][color=green]
>>
>> Definitions are also declarations, which is why CBFalconer
>> likes to put the definitions of other functions, above main.[/color]
>
> Like CBFalconer, I do that too, all the time. Nowhere do I say
> that a definition is not a declaration.[/color]

Which has a multitude of advantages. I never make a mistake in
matching the function header to its prototype, and it caters to
extreme laziness in that I never type something twice, or even have
to cut and paste a header. Whenever I am looking for the
definition of a function I know precisely in which direction in the
source to look. :-)

I also like to have a clear demarcation between the code for one
function and the header of the next. Marking the trailing '}' with
a comment indicating which function it ends is also handy when
rummaging about in the source. Thus:

} /* foo */

/* --------------- */

/* Do foo(lish) things in a bar */
static int bar(...)
{

--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

[Tim Rentsch]

Re: Parts of a C program, Re: problem with compilation

pete <pfiland@mindsp ring.com> writes:
[color=blue]
> Each byte in a C program is one of 4 things:
> 1 part of a comment
> 2 part of a preprocessor directive
> 3 part of an external declaration
> 4 all other bytes in a C program are white space[/color]

Mostly I agree with this (glossing over the discussions about 'static'
vs "external" and possible declaration/definition distinctions).

But, wouldn't you agree that \ NEWLINE aren't exactly like
other white space? (And they certainly don't fall into the
other three categories.) I feel a little bit uneasy referring
to \ NEWLINE as "white space".

[pete]

Re: Parts of a C program, Re: problem with compilation

Tim Rentsch wrote:[color=blue]
>
> pete <pfiland@mindsp ring.com> writes:
>[color=green]
> > Each byte in a C program is one of 4 things:
> > 1 part of a comment
> > 2 part of a preprocessor directive
> > 3 part of an external declaration
> > 4 all other bytes in a C program are white space[/color]
>
> Mostly I agree with this (glossing over the discussions about 'static'
> vs "external" and possible declaration/definition distinctions).
>
> But, wouldn't you agree that \ NEWLINE aren't exactly like
> other white space? (And they certainly don't fall into the
> other three categories.) I feel a little bit uneasy referring
> to \ NEWLINE as "white space".[/color]

N869
7.4.1.9 The isspace function
Description
[#2] The
standard white-space characters are the following: space
(' '), form feed ('\f'), new-line ('\n'), carriage return
('\r'), horizontal tab ('\t'), and vertical tab ('\v')

--
pete

[pete]

Re: Parts of a C program, Re: problem with compilation

Joe Wright wrote:[color=blue]
>
> pete wrote:[color=green]
> > Joe Wright wrote:
> >
> >[color=darkred]
> >>You need a better C book. Headers should not contain function
> >>definitions (or any other definitions). Headers are for declarations.
> >>And yes, '#define FOO 10' is a declaration, not a definition.
> >>Hence s1.h is useless and even an error. s1.c should look like..[/color]
> >
> >
> > Definitions are also declarations, which is why CBFalconer
> > likes to put the definitions of other functions, above main.
> >[/color]
>
> Like CBFalconer, I do that too, all the time. Nowhere do I say that a
> definition is not a declaration.
>[color=green]
> > #define FOO 10 is a preprocessor directive.
> >[/color]
>
> Of course it is. Declarations refer to variables and other objects. I
> was making the point that #define doesn't indicate a definition of an
> object and therefore create memory for it.
>[color=green]
> > Each byte in a C program is one of 4 things:
> > 1 part of a comment
> > 2 part of a preprocessor directive
> > 3 part of an external declaration
> > 4 all other bytes in a C program are white space
> >[/color]
>
> Nonsense. I give you 1, 2 and 4 but your item 3 is too much.
> What part of ..
>
> static int foo;
>
> .. is an external declaration?[/color]

K&R2 A10.2 External Declarations
The term "external" refers to their location outside functions,
and is not directly connected with the extern keyword;
the storage class for an externall-declared object may be
left empty, or it may be specified as extern or static.

N869
6.9 External definitions

[#4] As discussed in 5.1.1.1, the unit of program text after
preprocessing is a translation unit, which consists of a
sequence of external declarations. These are described as
``external'' because they appear outside any function (and
hence have file scope). As discussed in 6.7, a declaration
that also causes storage to be reserved for an object or a
function named by the identifier is a definition.

--
pete

[pete]

Re: Parts of a C program, Re: problem with compilation

Tim Rentsch wrote:[color=blue]
>
> pete <pfiland@mindsp ring.com> writes:
>[color=green]
> > Each byte in a C program is one of 4 things:
> > 1 part of a comment
> > 2 part of a preprocessor directive
> > 3 part of an external declaration
> > 4 all other bytes in a C program are white space[/color][/color]
[color=blue]
> possible declaration/definition distinctions[/color]

N869
6.9 External definitions
[#5] An external definition is an external declaration that
is also a definition of a function or an object.

--
pete

[pete]

Re: Parts of a C program, Re: problem with compilation

CBFalconer wrote:[color=blue]
>
> pete wrote:[color=green]
> >[/color]
> ... snip ...[color=green]
> >
> > Function definitions are unique among declarations in two ways:
> > 1 they are not terminated by a semicolon ;
> > 2 they are always external[/color]
>
> static int foo(...) {...} /* not exactly external */
> static int bar(...); /* forward declaration, not external */[/color]

"External" means something else in C.

--
pete

[CBFalconer]

Re: Parts of a C program, Re: problem with compilation

pete wrote:[color=blue]
> Joe Wright wrote:[color=green]
>>[/color][/color]
.... snip ...[color=blue][color=green]
>>
>> Nonsense. I give you 1, 2 and 4 but your item 3 is too much.
>> What part of ..
>>
>> static int foo;
>>
>> .. is an external declaration?[/color]
>[/color]
.... snip ...[color=blue]
>
> N869
> 6.9 External definitions[/color]

I just reared back and let fly on that, and ran into the same
quote. It does justify hia statement, weird though it may be.

I even deleted the reply containing the rearing! A useful subject
for trolling purposes in this group.

--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

[Stephen Sprunk]

Re: problem with compilation

"foodic" <divya_oliva_fe rnadez@yahoo.co .in> wrote in message
news:47d335da.0 503200524.68242 ffb@posting.goo gle.com...[color=blue]
> Hi all
> I have a little bit of programming experience on windows 98 using C.
> But this is my first attempt to compile a program on
> Linux using gcc.I have two files s1.c and s1.h and while
> compiling i am getting compilation problem,[/color]
....[color=blue]
> when i compile this program,
>
> gcc s1.c
> it gives error like,
> s1.c:2:16: s1.h: No such file or directory[/color]

That's because a non-system header file should be "file.h" instead of
<file.h>.
[color=blue]
> Please somebody explain how to compile it[/color]

The "normal" way to do what you want is:

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

int main() {
hi();
}

/*** s1.h ***/
void hi();

/*** s1.c ***/
#include <stdio.h>

void hi() {
printf ("Hi all\n");
}

<OT reason="impleme ntation-specific">

Then to compile, you do:

gcc -c main.c
gcc -c s1.c
gcc -o s1 main.o s1.o

This will give you an executable named "s1". If you get into projects much
larger than this, you'll want to learn how to build a Makefile, but for one
or two files it's simpler to do it by hand.

</OT>

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin