Hello Pascal,
So that in debug mode,
it produces some functions for the .cpp you were mentioning, and they are
optimized out in the release build. Why the linker would see these
is unclear to me, because on Linux, it would produce a private symbol in the
object file, hence not visible to other compilation units. On Windows, maybe
there is no 'private' symbol, so the linker sees it, but then only in debug
mode.
Just to comment here: The behaviour I saw was _identical_ on Linux and
Windows (you seem to think otherwise, I just thought I'd make that
clear). In other words, on both platforms, the code compiled and
linked in debug mode, and in release (or at least, when NDEBUG was
defined) the linker complained that those two methods, which were
defined as inline but not declared as such, were not found.
I haven't experimented with other compilation options (I didn't even
check to see whether defining NDEBUG in a debug build would reproduce
the behaviour, and I don't have the code with me right now). But
anyways, the problem is solved, and I won't make that mistake anymore
(see below). And since this is a build tool's mailing list, and not a
compiler mailing list, I think that's the important thing. I may
experiment more later.
Anyway, the declaration and definition of these methods are not
consistent, so
that is the real source of the trouble and should be fixed, if you own the
code.
Indeed it was, and indeed I have.
Thanks,
J-S
--
______________________________________________________
Jean-Sebastien Guay [EMAIL PROTECTED]
http://whitestar02.webhop.org/
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
