Re: [lmi] Build fails with 'build_type=safestdlib'

[Greg Chicares]

On 2007-04-19 12:24Z, Evgeniy Tarassov wrote:
> 
> Let me do an upside-down analysis of the root cause down to the observed
> error:

Let me try to summarize. The linker diagnostics all refer to
  AxisMaxBoundAdjusterBase or
  MultiDimAxisAnyChoice
which both derive from wxChoice. Somehow that's incompatible with
libstdc++'s debug mode. That's the only incompatibility AFAIK.
Apparently it's because wxChoice has two base classes, and that
results in dll thunks having different mangled names.

It sounds like we have these choices:

0) Never use libstdc++'s debug mode: that's not attractive
because debug mode is too useful on rare occasions.

1) Build wx with libstdc++'s debug mode:

> The correct solution would be to compile both wx and lmi with the same
> set of flags (to make a safestdlib build for wx too and to link to
> it).

Well, it's not incorrect, but it's also not convenient. IIRC,
you have something like fifteen custom wx builds already. We
have only one ourselves, and one is nicer than two. I'd like
to evaluate other ideas.

2) Don't subclass wxChoice. Let's consider whether that's a
feasible option. What purpose is served by subclassing it?
I guess it's so that we can write these functions:

  class MultiDimAxisAnyChoice :public wxChoice
    void SelectionChanged();
    void UponSelectionChange(wxCommandEvent& event);
    void PopulateChoiceList();

  class AxisMaxBoundAdjusterBase :public wxChoice
    virtual void DoUponChange() = 0;
    void UponChange(wxCommandEvent&);

Could those be handled at the dialog level? I hesitate to draw
your attention to MvcController::ConditionallyEnableItems(),
which does similar things without subclassing, because it has
two kinds of issues:
  (a) overall quality of implementation--it needs rewriting
  (b) the switch-on-type approach is generally considered harmful
and I don't want to get distracted by (a). But (b) is just a
technique that, like inheritance, or multiple inheritance,
shouldn't be overused. If switch-on-type is the least bad answer
to a real problem, then we should use it, documenting why other
alternatives were rejected.

I don't have as much insight into the design rationale as you do,
so let me ask how much violence it would do to the design.

3) This seems unattractive:

> As a workaround we could try to avoid using STL containers as
> class-base and as data-members, to ensure that a class size does not
> change. For example the m_children data member (mentioned above) could
> be declared as a pointer to wxWindowList. But the problem will persist
> because even if we manage to link (I have tested it -- lmi-safestdlib
> links with wx if m_children is held as a pointer), lmi will still be
> calculating wx classes size incorrectly -- for example for
> wxWindowList, which could lead to a crash or an undefined behavior in
> runtime).

It sounds like that requires deep changes to wx itself, and may
not even work, so I haven't really tried to understand it. Let
me know if I'm missing something, but my guess is that you've
presented this just to document why it's not an option.

> I wonder what if in some other library used by lmi (libxml2 or
> libxslt) there is a multiple-inheritance class that uses STL
> containers -- will the build fail with errors, or will it fail instead
> during the runtime?

Those are C libraries, so they wouldn't have a problem with
multiple inheritance themselves, but xmlwrapp and xsltwrapp
might--but I don't think they do. I know I've used libstdc++'s
debug mode (though I can't say how recently), and it didn't
fail at runtime except when it found an error in my code.