Re: [lmi] lmi tests under cygwin

[Greg Chicares]

On 2005-11-2 18:47 UTC, Vadim Zeitlin wrote:
> On Wed, 02 Nov 2005 18:39:13 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Let's address only this part of your message today, because it's
> GC> the worst problem. I agree that we should try to fix it at the
> GC> source: if it's a linker problem, then it doesn't depend on
> GC> autotools at all.
> 
>  BTW, it isn't cygwin-specific neither, the same happens under Linux.
> However I think I do understand why it didn't happen with your makefiles:
> you actually link in the alert.o (and the other files common to all tests)
> into each test whereas I compile them once into a librrary (.a) and then
> use it. So in this sense it is specific -- not to autotools but to my
> Makefile. I still think the problem should be fixed though because using a
> library should be better/faster than using individual object files
> normally.

Recently you proposed replacing 'callback.hpp' with boost::function.
I mentioned that 'callback.hpp' is an abstraction of a technique I
had used in 'alert*.?pp' and 'progress_meter*.?pp'. Those classes
should be rewritten to use either 'callback.hpp' or boost::function.

Now you have pointed out a new, concrete problem that's more urgent.
This is a general problem, and it's best to solve the general case.

In 'alert_cli.cpp', would this change help?
-    bool ensure_setup = set_alert_functions
+    volatile bool ensure_setup = set_alert_functions
Generally, what is volatile shouldn't be optimized away, but maybe
the as-if rule overcomes that--and linker behavior isn't defined
by the C++ standard anyway.

Here's another idea: in 'alert_cli.cpp',

[Move this thing out of the anonymouse namespace:]

- namespace
- {
      bool ensure_setup = set_alert_functions
          (status_alert
          ,warning_alert
          ,hobsons_choice_alert
          ,fatal_error_alert
          );
+ namespace
+ {

and then somewhere in 'alert.cpp', do something like

  extern bool ensure_setup;
  &ensure_setup;

to see whether that prevents the linker from discarding the first file.

Because I haven't tried to build with autotools yet (and don't know
what problems I might run into), could I ask you to spend a moment
trying those ideas, and let me know the outcome?

With regret, I'm looking for a quick workaround today. The general
problem should be solved; boost::function should be investigated,
too (do they have a solution to this linker issue?); and all
classes that need callbacks should use the same facility. I don't
want to spend a lot of time on workarounds while leaving these
other issues unaddressed, but right now I can't make the time to
address them all as they deserve to be addressed.