Re: [lmi] Forcing linking of the library modules (again)

[Greg Chicares]

On 2014-08-15 20:47Z, Vadim Zeitlin wrote:
[...]
>  The comment added by the patch basically explains what is going on: when
> building lmi_wx.exe using MSVC, the file progress_meter_wx.cpp, which is
> part of the skeleton library, is simply not linked in at all because the
> main program doesn't reference any of its symbols and Microsoft linker
> completely discards all the object files which it considers to be unneeded.
> This results in set_progress_meter_creator() being never called, as the
> global "ensure_setup" variable in this file is never initialized because
> it's simply not present in the final binary.

I'm willing to apply such a patch if you can include every translation
unit that's likely to have this problem (see below). Only a few lines of
code change, the code doesn't become significantly uglier or harder to
understand and maintain, and I can't imagine any problem this might cause.

Still, I have to ask: how can this linker not be considered broken?
It sounds like this "optimization" generally produces a benefit that
we can surely live without, but sometimes introduces a ghastly problem.
Isn't that the same cost-benefit profile as thalidomide?

>  So would you be willing to apply the patch adding these macros to all the
> affected files (once I find all of them...)?

To help you find all of them...this should suffice:
  grep 'volatile bool\|ensure_setup' *.?pp

The code associated with this problem in 'progress_meter_wx.cpp' is:

volatile bool ensure_setup = set_progress_meter_creator
    (concrete_progress_meter_creator
    );

Both 'progress_meter_cgi.cpp' and 'progress_meter_cli.cpp' contain
copies of that same code. While we don't distribute CGI binaries or
run a CGI server today, the CLI binaries really are actively used.
I'm not going to introduce a wxCore library dependency for the sake
of two simple macros; instead, I've cloned this code:
  http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/include/wx/link.h?view=co
to provide lmi-specific macros in new header 'force_linking.hpp'.
For uniformity, it seems better to use that in preference to
<wx/link.h> in the lmi repository.

Exactly where must wxFORCE_LINK_MODULE be written? Given that the
issue is quite global, I'd rather write it in as few places as
possible. But it can't be written in one place only: we need
  wxFORCE_LINK_MODULE(progress_meter_wx)  // for wx builds
  wxFORCE_LINK_MODULE(progress_meter_cli) // for cli builds
  wxFORCE_LINK_MODULE(progress_meter_cgi) // (for completeness)
and those beasts must be kept in separate cages. I guess the right
place really is 'main_wx.cpp' (etc.) as in your patch--and similarly
for 'alert_*' and 'file_command_*'. But 'system_command_non_wx.cpp'
seems like it should be handled in 'main_common_non_wx.cpp'.