|
From: Bart V. A. <bar...@gm...> - 2009-12-31 13:58:15
|
On Thu, Dec 31, 2009 at 1:38 PM, Julian Seward <js...@ac...> wrote: > > I must say I don't think this is a good idea. For one thing > it now requires us to #include config.h everywhere we need it, > whereas before, inclusion of pub_tool_basics.h was enough. > This for example causes Memcheck to not start up on openSUSE > 11.0 x86_64, since the GLIBC_2_x symbols are no longer visible > in m_redir.c. > > More seriously, it means that the installation tree (still) > lacks a config.h which matches/describes how the installed > libraries and executables were built. Perhaps a better solution > would be to revert this and to install config.h too. Sorry Julian, but I disagree completely with the above. Not including the header file "config.h" when symbols defined in that header file are necessary is a bad programming practice in my opinion. Also, including "config.h" from a public header file like pub_tool_basics.h is completely wrong because this makes it impossible for external projects that include the Valgrind public header files to have a header file with the same name, namely "config.h". Furthermore, exposing all symbols defined in Valgrind's "config.h" to external projects would create a high probability of symbol collisions / redefinitions, e.g. the HAVE_* macro's. If we really have to expose some of the symbols defined during Valgrind's configure process, we should do like Stefan Kost proposed and let the configure process transform a file valgrind_config.h.in to valgrind_config.h. That would allow us to export a minimum set of symbols from Valgrind to external projects instead of all symbols defined during the configure step. Bart. |