14

Why does the compiled and linked executable file contain paths of header files included in my source code? I am using the wxWidgets library and compile with Visual Studio 2013 and gcc. What are these header files used for? If it is a compiler option, how can I disable it to avoid this?

Build configuration: release, static linking.

Example

drescherjm
  • 10,365
  • 5
  • 44
  • 64
Gokhan Bora
  • 146
  • 1
  • 6
  • those are paths to libraries, not paths to header files. When compiled/linked for dynamic linking of libraries, the code needs to know where the library is located. 'static' linking will make the code much larger, but will remove those paths as they are no longer needed. – user3629249 May 09 '15 at 15:12

2 Answers2

15

There may be several explanations for such strings to appear in the executable file:

  • You may have debugging information bundled in the executable for the debugger to use. Use strip to remove that, or do not use the -g compile option. You should also compile with NDEBUG defined to disable debugging code and assertions. It is usually the case for the Release mode, but you may want to double check.
  • Some functions may use __FILE__ for tracing or logging purposes. __FILE__ expands to the source file name at the point of macro expansion, which may be a source or a header file. One such function is assert(): it is actually a macro that expands to a test and some error reporting code that includes the current filename.
  • Some sources may have static source ids in the form of static char arrays to keep track of source code versions. This approach is quite obsolete, but many old sources still have them.

Look for such things in the source files or header files whose name appear in the executable and fix the problems.

chqrlie
  • 131,814
  • 10
  • 121
  • 189
  • A single [`assert()`](http://www.cplusplus.com/reference/cassert/assert/) can be the cause (as per the first two itmes of chqrlie's list). Compiling with `NDEBUG` may get rid of many. – Hagen von Eitzen May 09 '15 at 13:04
  • I have tried strip and defining wxDEBUG_LEVEL as 0, they didn't work. – Gokhan Bora May 09 '15 at 13:55
  • @Gokhan Bora: Did you recompile everything? – chqrlie May 09 '15 at 14:12
  • yes, recompiled project, recompiled wxWidgets library. after define wxDEBUG_LEVEL, there are less strings in binary. but still, so many readable strings are in exe file. Thank you for help. – Gokhan Bora May 09 '15 at 14:40
  • Are these strings filenames? If so, the problem lies in each file whose name you find in the executable. – chqrlie May 09 '15 at 14:42
  • 1
    The strings shown in the screenshot definitely come from assert messages and shouldn't be present if `wxDEBUG_LEVEL` is set to 0. To find out where do the remaining strings come from you need to show them to us. – VZ. May 10 '15 at 16:05
6

wxwidgets has many asserts in its header files (e.g. in wx/string.h as you noticed), all using the wxASSERT macro defined in wx/debug.h In order to disable these, you can #define wxDEBUG_LEVEL 0 prior to including any wxwidget headers.

Hagen von Eitzen
  • 2,109
  • 21
  • 25