[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linking to library built with -D_GLIBCXX_DEBUG
From: |
mathieu |
Subject: |
Re: Linking to library built with -D_GLIBCXX_DEBUG |
Date: |
Sat, 24 May 2008 08:42:40 -0700 (PDT) |
User-agent: |
G2/1.0 |
On May 23, 5:07 pm, Paul Pluzhnikov <ppluzhnikov-...@gmail.com> wrote:
> mathieu <mathieu.malate...@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.
Indeed I saw that ealier, this is a very good thing. I was hitting the
issue when linking a shared lib (built with _GLIBCXX_DEBUG) and then
linking an exe to that lib. Everything is nicely PIMPLized so I did
not see no explicit linking issue.
> 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.
Will do.
On a personal note, thanks paul, you have been answering pretty much
all of my latest issues. Thanks for your time, this is very much
appreciated !
-Mathieu