Re: Linking to library built with -D_GLIBCXX_DEBUG

[Paul Pluzhnikov]

mathieu <mathieu.malaterre@gmail.com> 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.