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]

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]

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()]

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:

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

 

[Default User]

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]

Vladimir S. Oka said:


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]

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.

 

[Vladimir S. Oka]

Richard Heathfield opined:

Vladimir S. Oka said:


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

 

[Ben C]

[snip]

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.

 

[Ingo Menger]

Ben C schrieb:

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

Indeed, "/" should always be fine on DOS and successors, while "\\"
will never work on UN*X.

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

Do you think the preprocessor interprets the character string between
".." or <...> in any way other than to pass it straight to fopen()?

 

[Mark McIntyre]

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

to a small extent. The "path/to/there/.h" syntax works on pretty much
all Osen I've worked with, including, surprisingly, VMS.

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

Absolutely. Thats what the switch is for.

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

Absolutely NOT. Do not clutter your local include dir with app
headers. :-(
Mark McIntyre

 

[Ben C]

Ben C schrieb:



Indeed, "/" should always be fine on DOS and successors, while "\\"
will never work on UN*X.

Yes, which is why it's usually better to use the '/', and also to
use the upper and lower case that the filenames actually have, because
this works on more platforms.

Do you think the preprocessor interprets the character string between
".." or <...> in any way other than to pass it straight to fopen()?

I wondered about this, and then whether there's anything in any standard
about directory separators in paths passed into fopen, but couldn't find
anything.

Presumably then fopen with '/' as a directory separator works on MS DOS
etc.? The C standard doesn't of course require that #include be
implemented with fopen.

 

[Richard Heathfield]

Mark McIntyre said:

Absolutely NOT. Do not clutter your local include dir with app
headers. :-(

I use it for library headers. App headers are what the cwd is for.

You might deduce from this that I don't split app source up into separate
directories. If it makes sense to split off a bunch of code into a separate
directory, chances are good that it's a useful bunch of code that will be
happier in a library.

 

[Roberto Waltman]

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

<off-topic>
The PATH environment variable sets the directory list that the shell
will search for executable files. It has no connection whatsoever with
the search list used by the C compiler/preprocessor for included
files.
For gcc you must specify it with a -Ipath_to_included_file in the
command line.
</off-topic>

This is a platform specific question, as opposed to a C language
question. Next time please use a RedHat, gcc or Linux forum.

 

[Kenneth Brody]

<off-topic>
The PATH environment variable sets the directory list that the shell
will search for executable files. It has no connection whatsoever with
the search list used by the C compiler/preprocessor for included
files.
For gcc you must specify it with a -Ipath_to_included_file in the
command line.

Some compilers use an environment variable similar to PATH, which is
used to list the #include directories, and is useful in that you don't
have to change scripts/makefiles/whatever you use to compile multiple
sets of files.

Again, however, this is dependent on your particular compiler.

</off-topic>

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

 

[Mark McIntyre]

Mark McIntyre said:


I use it for library headers. App headers are what the cwd is for.

You might deduce from this that I don't split app source up into separate
directories. If it makes sense to split off a bunch of code into a separate
directory, chances are good that it's a useful bunch of code that will be
happier in a library.

I tend to distinguish quite carefully between a library thats private
to the current app, and a library thats shared amongst several apps.
Mark McIntyre

 

[Richard Heathfield]

Mark McIntyre said:

I tend to distinguish quite carefully between a library thats private
to the current app, and a library thats shared amongst several apps.

If it's only ever going to be used by the current app, I generally won't
bother librarising it at all. I just pile it all into the app directory. If
that results in an unmanageable amount of source in that directory, it
almost certainly means I've missed an opportunity to factor out some
functionality that could be useful in other programs too.

 

[Ingo Menger]

I wondered about this, and then whether there's anything in any standard
about directory separators in paths passed into fopen, but couldn't find
anything.

Presumably then fopen with '/' as a directory separator works on MS DOS
etc.?

Yes it does. Some MS-DOS commands interpret the "/" in the commandline
as indicator for options, though. But this is a different story.

The C standard doesn't of course require that #include be
implemented with fopen.

Sure, but generally it does not make sense to parse a path name in an
application. It makes more sense to let the OS figure that out. The
reason why nothing is mentioned about directory separators (or, for
that matter, also drive letters) is most likely that the preprocessor
does not need to know anything about file systems, disk drives, mount
points, etc. It just needs a method to map a string (file name) to a
stream of bytes (file content).

 

[Keith Thompson]

I wondered about this, and then whether there's anything in any standard
about directory separators in paths passed into fopen, but couldn't find
anything.

The standard says nothing about directories. As far as the C standard
is concerned, the file name passed to fopen() is just a string, to be
interpreted in some system-specific manner.