g++34 std::locale::id seems to be different under debug mode?

[Pep]

I have a weird problem with a source tree that I have finally tracked
down to being the difference between a debug and non-debug build of a
library.

Each time I have performed this test I have started off by cleaning the
source tree before running make and the results are consistent.

I have 2 source trees, one is the actual application source tree and
the other is a helper library source tree. For the purpose of this
test, it makes no difference whether the application source tree is
built under debug or not, as the results are always the same.

If I compile the help library source tree in non-debug mode then I get
a error when linking against it regarding a undefined
std::locale::id::id()

If I compile the help library source tree in debug mode then everything
is fine when linking against it.

The complaint about the undefined std::locale::id::id() comes from a
routine in the helper library source tree not from within the
application source tree.

This is only happening with g++ 3.4.6 and I cannot give you a small
piece of example code as I simply do not know how to reproduce it,
apart from building the > 100,000 lines of source code.

At no place in the source code is there a reference to
std::locale::id::id() or anything even remotely close.

Anyone come across this before and if so how do I handle it?

TIA,
Pep.

[Paul Pluzhnikov]

"Pep" <pepalt...@yahoo.co.uk> writes:

> If I compile the help library source tree in non-debug mode then I get
> a error when linking against it regarding a undefined
> std::locale::id::id()

Begin by posting the *exact* error message.

> The complaint about the undefined std::locale::id::id() comes from a
> routine in the helper library source tree

So you know what routine is "causing the problem".

Take the source file in which that routine is defined, compile that
source in debug and non-debug mode, and run:

nm -C debug.o | grep 'std::locale::id::id'
nm -C nondebug.o | grep 'std::locale::id::id'

against the resulting object. You should observe an unresolved ('U')
reference in nondebug.o.

Now remove all routines, except the one "causing problem", and
repeat the experiment again. The result should be the same.

Finally, remove all unnecessary '#include's, and you'll have a
small test case (do tell us what command line you used to compile it).

> This is only happening with g++ 3.4.6

What is the output from 'g++ -v' (this will tell us what platform
you are using and how this g++ was configured).

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.