[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: [lmi] Build fails with 'build_type=safestdlib'
From: |
Vadim Zeitlin |
Subject: |
Re[2]: [lmi] Build fails with 'build_type=safestdlib' |
Date: |
Thu, 19 Apr 2007 20:12:00 +0200 |
On Thu, 19 Apr 2007 18:02:49 +0000 Greg Chicares <address@hidden> wrote:
GC> It sounds like we have these choices:
GC>
GC> 0) Never use libstdc++'s debug mode: that's not attractive
GC> because debug mode is too useful on rare occasions.
GC>
GC> 1) Build wx with libstdc++'s debug mode:
Yes, and I think those are the only choices we have.
GC> > The correct solution would be to compile both wx and lmi with the same
GC> > set of flags (to make a safestdlib build for wx too and to link to
GC> > it).
GC>
GC> Well, it's not incorrect, but it's also not convenient. IIRC,
GC> you have something like fifteen custom wx builds already.
Yes, but LMI only uses one of them. As long as it doesn't use the stock
build of wx it doesn't matter which extra options are used for it AFAICS.
GC> have only one ourselves, and one is nicer than two. I'd like
GC> to evaluate other ideas.
I don't think this is the right approach. Even if we manage to solve this
particular problem with wxChoice, we still risk having other problems
because the STL classes compiled with and without debug mode defines are
binary incompatible. So using one version of them in the library and
another one in the application is just asking for trouble. Even if it does
work now, it can break whenever either wx or libstdc++ change.
To repeat, I'm pretty sure the only solution is to build wx with the same
STL version as LMI. In addition to being guaranteed safe it will also allow
to detect problems in use of STL classes in wxWidgets code (which might not
be wx bugs as if an iterator invalidated by LMI code is passed to wx, the
detected problem could also help to discover the bug in LMI -- ok, so this
is pretty theoretical, but still possible).
Regards,
VZ