mathieu <[EMAIL PROTECTED]> writes: > I cannot find documentation for the gcc flag: _GLIBCXX_DEBUG.
The closest I found is this: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch30s04.html > I was > experiencing some very bizarre behavior when running my executable > until I realize that the exe was not build using -D_GLIBCXX_DEBUG, > adding that compile flag to match the flag used to build the library > did solve my issue. Under conditions you've described, the link was supposed to fail. Here is a trivial example: $ cat main.cc #include <vector> using namespace std; extern int foo(const vector<int> &); int main() { return foo(vector<int>()); } $ cat foo.cc #include <vector> using namespace std; int foo(const vector<int> &v) { return 0; } $ /usr/local/gcc-4.3.0/bin/g++ -g -D_GLIBCXX_DEBUG -c foo.cc $ /usr/local/gcc-4.3.0/bin/g++ -g main.cc foo.o /tmp/ccGj8mXl.o(.text+0x25): In function `main': /usr/local/gcc-4.3.0/include/c++/4.3.0/bits/stl_construct.h:129: undefined reference to `foo(std::vector<int, std::allocator<int> > const&)' collect2: ld returned 1 exit status > Is there a way to detect that the shared library I am linking to, > was build with such flag ? The design was supposed to force link errors on you. Either this didn't work (which is somewhat unlikely), or your bizarre behavior was only superficially fixed by rebuilding with -D_GLIBCXX_DEBUG, and the bug is still there; just hiding better. Try to construct a simple test case that mimics what the app and the library do and that shows the same problem. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
