C compilation error on RHEL3

[thuang2]

Hi,

Myfile.c include a "Otherfile. h" and this file is under different
directory. When I compile Myfile.c, the compiler says "Otherfile. h: No
such file or directory" I include the path to "Otherfile. h" in PATH
environment variable. It still does not compile. Is there anything else
that I should do in this case? BTW, this linux (Red Hat linux) Thanks.

[Robert Gamble]

thua...@hotmail .com wrote:

Hi,

Myfile.c include a "Otherfile. h" and this file is under different
directory. When I compile Myfile.c, the compiler says "Otherfile. h: No
such file or directory" I include the path to "Otherfile. h" in PATH
environment variable. It still does not compile. Is there anything else
that I should do in this case? BTW, this linux (Red Hat linux) Thanks.

The name of the include file is seached in an implementation defined
way, check your documentation for the details. Many implementations
allow you to specify the full pathname of the file or add directories
to be seached using a command-line option. For example, if you are
using gcc, check out the -I option.

Robert Gamble

[Vladimir S. Oka]

th*****@hotmail .com wrote:

Myfile.c include a "Otherfile. h" and this file is under
different
directory. When I compile Myfile.c, the compiler says
"Otherfile.h : No
such file or directory" I include the path to "Otherfile. h" in
PATH
environment variable. It still does not compile. Is there
anything else
that I should do in this case?

Changing PATH will not do. Try:

#include "path/Otherfile.h"

[void * clvrmnky()]

th*****@hotmail .com wrote:

Myfile.c include a "Otherfile. h" and this file is under different
directory. When I compile Myfile.c, the compiler says "Otherfile. h: No
such file or directory" I include the path to "Otherfile. h" in PATH
environment variable. It still does not compile. Is there anything else
that I should do in this case? BTW, this linux (Red Hat linux) Thanks.

1. This query is not specific to ANSI C, and this group is quite strict
about off-topic posts. Check your system documentation.

2. If you checked your documentation you will find references to
something called the "include path". This is the key to your problem.

[Richard Heathfield]

Vladimir S. Oka said:

th*****@hotmail .com wrote:

Myfile.c include a "Otherfile. h" and this file is under
different
directory. When I compile Myfile.c, the compiler says
"Otherfile. h: No
such file or directory" I include the path to "Otherfile. h" in
PATH
environment variable. It still does not compile. Is there
anything else
that I should do in this case?

Changing PATH will not do. Try:

#include "path/Otherfile.h"

Bad idea. Sorry, Vladimir, but that's a surefire way to make the code
non-portable.

Better: use the compiler's include path switch (e.g. in gcc it's -I) to
specify where to look for headers.

Better still: shove the headers in a place the compiler always looks in
anyway (e.g. /usr/local/include is common on Linux systems).
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Default User]

th*****@hotmail .com wrote:

Hi,

Myfile.c include a "Otherfile. h" and this file is under different
directory. When I compile Myfile.c, the compiler says "Otherfile. h: No
such file or directory" I include the path to "Otherfile. h" in PATH
environment variable. It still does not compile. Is there anything
else that I should do in this case? BTW, this linux (Red Hat linux)

Most compilers have a method to set additional include paths. Check
your documentation, find a newsgroup or forum for your compiler, or
search the web for those words.

Brian

[Ben C]

On 2006-04-19, Richard Heathfield <in*****@invali d.invalid> wrote:

Vladimir S. Oka said:

th*****@hotmail .com wrote:

Myfile.c include a "Otherfile. h" and this file is under
different
directory. When I compile Myfile.c, the compiler says
"Otherfile.h : No
such file or directory" I include the path to "Otherfile. h" in
PATH
environmen t variable. It still does not compile. Is there
anything else
that I should do in this case?
Changing PATH will not do. Try:

#include "path/Otherfile.h"

Bad idea. Sorry, Vladimir, but that's a surefire way to make the code
non-portable.

Why is it non-portable? The / will always work (even if the development
system uses a different directory separator), and so long as you stick
to relative paths (relative to the include directories for the build). I
always thought this should be all right.
[...]
Better still: shove the headers in a place the compiler always looks in
anyway (e.g. /usr/local/include is common on Linux systems).

<OT>

This might not be the best way to organize the headers in every case
though. It's a UNIX convention to put all the headers from all packages
in one place, all the executables from all packages in another place,
and all the libs in another. But on other systems things are organized
differently, for example the headers, executables and libs may all go
beneath different subdirectories for each package. On Windows for
example you see dirs called things like "C:\Program Files\My Favorite
Program\Include \" which is where the headers for "My Favorite Program"
go.

Also, thuang2 may not have write access to /usr/local/include.

</OT>

[Keith Thompson]

Ben C <sp******@spam. eggs> writes:

On 2006-04-19, Richard Heathfield <in*****@invali d.invalid> wrote:

Vladimir S. Oka said:

th*****@hotmail .com wrote:

Myfile.c include a "Otherfile. h" and this file is under
different
directory . When I compile Myfile.c, the compiler says
"Otherfile. h: No
such file or directory" I include the path to "Otherfile. h" in
PATH
environme nt variable. It still does not compile. Is there
anything else
that I should do in this case?

Changing PATH will not do. Try:

#include "path/Otherfile.h"

Bad idea. Sorry, Vladimir, but that's a surefire way to make the code
non-portable.

Why is it non-portable? The / will always work (even if the development
system uses a different directory separator), and so long as you stick
to relative paths (relative to the include directories for the build). I
always thought this should be all right.

What makes you think the / will always work? The standard makes no
such guarantee.

It happens to be interpreted as a directory delimiter on most modern
systems used for development (Unix-like systems, MS DOS and Windows),
and if you don't care about portability beyond such systems you can
use it. Things like "#include <sys/foobar.h>" are common on Unix-like
systems.

Otherwise, your best bet is to use just the name of the header file
and use some compiler-specific method to tell the compiler where to
look.

[...]
Better still: shove the headers in a place the compiler always looks in
anyway (e.g. /usr/local/include is common on Linux systems).

<OT>

This might not be the best way to organize the headers in every case
though. It's a UNIX convention to put all the headers from all packages
in one place, all the executables from all packages in another place,
and all the libs in another. But on other systems things are organized
differently, for example the headers, executables and libs may all go
beneath different subdirectories for each package. On Windows for
example you see dirs called things like "C:\Program Files\My Favorite
Program\Include \" which is where the headers for "My Favorite Program"
go.

Also, thuang2 may not have write access to /usr/local/include.

</OT>

Putting the headers for one particular project in a system-wide
directory is ok if and only if you want to make those headers
available system-wide. If they're local to one project, you probably
want to keep them in the directory (or directory tree) for that
project.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Vladimir S. Oka]

Richard Heathfield opined:

Vladimir S. Oka said:

#include "path/Otherfile.h"

Bad idea. Sorry, Vladimir, but that's a surefire way to make the code
non-portable.

You are, of course, absolutely right.

<OT type="excuse">
I should have refrained from testing Usenet access from my PDA on c.l.c
(in the header of the offending post you'll find: "User-Agent:
Yanoff-/3.2 (Palm)"). I actually thought I cancelled the post, but pen
based input on a tiny screen got the better of me.
</OT>

Anyway, I won't do it again...

--
Peace was the way.
-- Kirk, "The City on the Edge of Forever", stardate unknown

<http://clc-wiki.net/wiki/Introduction_to _comp.lang.c>

[Ben C]

On 2006-04-19, Keith Thompson <ks***@mib.or g> wrote:

Ben C <sp******@spam. eggs> writes:

On 2006-04-19, Richard Heathfield <in*****@invali d.invalid> wrote:

Vladimir S. Oka said:
[snip]
#include "path/Otherfile.h" Bad idea. Sorry, Vladimir, but that's a surefire way to make the code
non-portable.

Why is it non-portable? The / will always work (even if the development
system uses a different directory separator), and so long as you stick
to relative paths (relative to the include directories for the build). I
always thought this should be all right.

What makes you think the / will always work? The standard makes no
such guarantee.
I drew the wrong conclusion from the fact that it usually does work.
It happens to be interpreted as a directory delimiter on most modern
systems used for development (Unix-like systems, MS DOS and Windows),

MS DOS (and some versions of Windows?) use \ in the shell, but you can
often use either \ or / in your #include directives.

As you say, though, this isn't standard, it's just the particular
preprocessor doing you a favour.

Thanks for putting me right on this one.