Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #24768 > unrolled thread

regarding header files

Back to article view | Back to comp.lang.c

Contents

  regarding header files Varun Tewari <tewari.varun@gmail.com> - 2012-08-23 10:43 -0700
    Re: regarding header files Les Cargill <lcargill99@comcast.com> - 2012-08-23 12:50 -0500
      Re: regarding header files Varun Tewari <tewari.varun@gmail.com> - 2012-08-27 09:44 -0700
    Re: regarding header files James Kuyper <jameskuyper@verizon.net> - 2012-08-23 14:10 -0400
      Re: regarding header files Varun Tewari <tewari.varun@gmail.com> - 2012-08-25 06:32 -0700
    Re: regarding header files Lucas Pesenti <lucas-pesenti@hotmail.fr> - 2012-08-28 17:58 +0200

#24768 — regarding header files

Hello people,
Hope you are all doing good.

I was eager to know, if there's a way to tell gcc to display the full path of header file that's getting included while compiling a code.
I mean, suppose we are building a relatively big codebase, and you hitting multiple declaration error. U are able to figure out which files are causing this, but if you want to figure how these files are getting included in your code, even tough you have been careful enough to ensure such things doesn't happen, still?

Any inputs?

[toc] | [next] | [standalone]

#24770

Varun Tewari wrote:
> Hello people,
> Hope you are all doing good.
>
> I was eager to know, if there's a way to tell gcc to display the full path of header file that's getting included while compiling a code.
> I mean, suppose we are building a relatively big codebase, and you hitting multiple declaration error. U are able to figure out which files are causing this, but if you want to figure how these files are getting included in your code, even tough you have been careful enough to ensure such things doesn't happen, still?
>
> Any inputs?
>


Look to the -M option for most toolchains.

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#25108

Thnx. This helped.

[toc] | [prev] | [next] | [standalone]

#24772

On 08/23/2012 01:43 PM, Varun Tewari wrote:
> Hello people,
> Hope you are all doing good.
> 
> I was eager to know, if there's a way to tell gcc to display the full path of header file that's getting included while compiling a code.
> I mean, suppose we are building a relatively big codebase, and you hitting multiple declaration error. U are able to figure out which files are causing this, but if you want to figure how these files are getting included in your code, even tough you have been careful enough to ensure such things doesn't happen, still?

If you use the -E option, gcc will create a pre-processed file
containing #line directives indicating where each section of
pre-processed code came from. Tracing backwards from the point where the
problem occurred, you can determine precisely how it got #included.


However, in my recent experience, I haven't found that necessary - gcc
usually includes the needed information in the warning message itself.
This may be a side-effect of one of the warning options I have turned on
- I normally use:-std=c99 -pedantic -Wall -Wpointer-arith -Wcast-align
-Wstrict-prototypes -Wmissing-prototypes.

Here's an example:

In file included from
/MODAPSint/SDPToolkit/SDPTK5.2.16v1.00_f90/include/CUC/odldef.h:462,
                 from
/MODAPSint/SDPToolkit/SDPTK5.2.16v1.00_f90/include/PGS_MET_Prototypes.h:32,
                 from
/MODAPSint/SDPToolkit/SDPTK5.2.16v1.00_f90/include/PGS_MET.h:619,
                 from /L1A/COMMON/MAPI/h/mapi.h:57,
                 from GEO_product.h:96,
                 from GEO_parameters.h:5,
                 from GEO_earth.h:106,
                 from GEO_write_input_metadata.c:2:
/MODAPSint/SDPToolkit/SDPTK5.2.16v1.00_f90/include/CUC/odldef_prototypes.h:36:
warning: function declaration isn’t a prototype

[toc] | [prev] | [next] | [standalone]

#24908

ok, i will try this.Thnx

[toc] | [prev] | [next] | [standalone]

#25254

On 23/08/2012 19:43, Varun Tewari wrote:
 > Hello people,
 > Hope you are all doing good.
 >
 > I was eager to know, if there's a way to tell gcc to display the full 
path
 > of header file that's getting included while compiling a code.
 > I mean, suppose we are building a relatively big codebase, and you 
hitting
 > multiple declaration error. U are able to figure out which files are 
causing
 > this, but if you want to figure how these files are getting included 
in your
 > code, even tough you have been careful enough to ensure such things 
doesn't
 > happen, still?
 >
 > Any inputs?

If you want to have the dependencies of the main source file, you should
indeed use the "-M" option of gcc. Here is an output example (gcc -M main.c
  f.c > a.txt), for the following program.

/* main.c */
#include "f.h"
int main(void) { return f(); }

/* f.c */
#include <stdlib.h>
int f(void) { return EXIT_SUCCESS }

/* f.h */
int f(void);

/* a.txt */
main.o: main.c f.h
f.o: f.c /usr/include/stdlib.h /usr/include/features.h \
  /usr/include/bits/predefs.h /usr/include/sys/cdefs.h \
  /usr/include/bits/wordsize.h /usr/include/gnu/stubs.h \
  /usr/include/gnu/stubs-32.h \
  /usr/lib/gcc/i686-linux-gnu/4.4.5/include/stddef.h \
  /usr/include/bits/waitflags.h /usr/include/bits/waitstatus.h \
  /usr/include/endian.h /usr/include/bits/endian.h \
  /usr/include/bits/byteswap.h /usr/include/sys/types.h \
  /usr/include/bits/types.h /usr/include/bits/typesizes.h \
  /usr/include/time.h /usr/include/sys/select.h /usr/include/bits/select.h \
  /usr/include/bits/sigset.h /usr/include/bits/time.h \
  /usr/include/sys/sysmacros.h /usr/include/bits/pthreadtypes.h \
  /usr/include/alloca.h

There are some variants, such as "-MM" (do not mention header files that are
found in system header directories). Besides, you can consider to set an
environment variable, "DEPENDENCIES_OUTPUT", which is equal to the 
combination
  of the options "-MM" and "-MF".

Look at the "Preprocessor options" from the GCC documentation to have more
information.

Hope this helps.
L.P.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web