Re: [lmi] Re: To configure wx-2.6.2

[Greg Chicares]

On 2007-11-14 14:52Z, Vadim Zeitlin wrote:
> On Wed, 14 Nov 2007 04:41:03 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> > # Options that we might not require, but want anyway:
> GC> >  --enable-stl
> GC> >  --enable-std_iostreams
> GC> >  --enable-debug
> GC> 
> GC> Auditing this today, I find that we've been using
> GC>   --enable-debug_info
> GC> instead of
> GC>   --enable-debug
> GC> in production; I believe we should use the latter instead,
> GC> after careful testing.
> 
>  I'm not sure how appropriate this would be. The debug build of wxWidgets
> is meant for developers and not end users. Of course, LMI users are a more
> limited/closed group than usual so maybe it does make sense in this
> particular case but some adjustments still may need to be made. For
> example, I don't think it's really useful to show assert messages to them
> so you may want to override wxApp::OnAssertFailure().

On the other hand, we expect to add new users, many of whom will
be less tolerant of assertion-failure messages than today's. I'd
hope that any assertions would point out previously-unrecognized
lmi defects that we could fix, but we'll have to experiment with
wx debug mode in order to find out what sort of messages might
appear.

>  I also wonder if you need --enable-debug_info (--enable-debug is a
> superposition of --enable-debug_info and --enable-debug_flag and so
> includes it). This makes the library enormously bigger, especially when
> using gcc, without any benefits that I can see as the users, even LMI ones,
> are unlikely to be running it under gdb. So maybe you should be using just
> --enable-debug_flag (which enables asserts and other features controlled by
> __WXDEBUG__)?

That's another suggestion worth considering.

What's most important IMO is to make sure everyone who talks to
our end users regularly uses the same binaries we distribute.
On msw in particular, gcc's debug mode is known to mask problems
by zero-initializing memory whose contents are undefined by the
standard; on the MinGW or Cygwin mailing lists I often see claims
that the compiler is defective because an application that works
perfectly with '-ggdb', and works perfectly on GNU/Linux with or
without debugging on, crashes on msw when built without debug
support. It's okay if we occasionally use other special-purpose
builds for testing, but normally we should be eating exactly the
same food we're serving to customers.

I'm glad you raised the question, though, because I find I can't
give a really satisfactory reason for using any '-g' option. My
historical reasons have been:

 - GNU coding standards recommend it--but our end users wouldn't
   know how to run 'strip'; and rms certainly doesn't build C++
   programs on msw, else his recommendation might be different

 - I used to use gdb once in a while--but I rarely do these days,
   and I don't think anyone in our office ever does anymore

But now I think those reasons are outweighed by the practical
issues. The size of the binaries matters somewhat because it does
take time for end users to load them. For developers, the time
required to build wx is also important, along with the difficulty
of linking on msw, which uses the better part of a gigabyte of
RAM to create the '--enable-debug_info' dll; without that flag,
the linker doesn't seem to use more RAM than gcc. Here are some
statistics for my msw box; "elapsed" times are for a full build
of wx-2.8.6 from scratch:

* With '--enable-debug':

00:40:39 elapsed = 15:18:45 - 14:38:06
00:41:13 elapsed = 04:50:24 - 04:09:11

total time in link: 788.964000 [from LDFLAGS='-Wl,--stats']

dll: 89272469 bytes

* Without '--enable-debug':

00:27:34 elapsed = 03:57:10 - 03:29:36
00:27:41 elapsed = 05:29:46 - 05:02:05

total time in link: 10.109000 [from LDFLAGS='-Wl,--stats']

dll: 11896958 bytes

* With '--enable-debug_flag' only:

00:27:41 elapsed = 13:18:00 - 12:50:19

total time in link: 10.828000 [from LDFLAGS='-Wl,--stats']

dll: 12382565 bytes

The only assertion failure I was able to trigger in a few minutes
of experimentation elicits the following series of messageboxen:

wxWidgets Debug Alert
../src/msw/utilsexc.cpp(532): assert "!cmd.empty()" failed in wxExecute(): 
empty command in wxExecute
Do you want to stop the program?
You can also choose [Cancel] to suppress further warnings.
Yes   No   Cancel

[I chose "No"]

wxWidgets Debug Alert
../src/common/utilscmn.cpp(642): assert "is" failed in ReadAll(): NULL stream 
in wxExecute()?
Do you want to stop the program?
You can also choose [Cancel] to suppress further warnings.
Yes   No   Cancel

[I chose "No"; the same messagebox appeared again; I chose "No"]

Error
Command '' not recognized.

...and we really don't want to confront end users with all that.

> so you may want to override wxApp::OnAssertFailure().

That suggestion, along with '--enable-debug_flag', sounds best.
We won't adopt it immediately because we really ought to test how
it affects lmi, but I expect we'll do it next time we upgrade our
production version of wx.