Re: [lmi] Mystic fix for so-attributes linker error

[Greg Chicares]

On 2017-03-09 15:40, Vadim Zeitlin wrote:
> On Thu, 9 Mar 2017 14:59:45 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> That's a useful idea to keep in mind, but this one may be even better,
> GC> if only because I can do it too (without accepting an unacceptable EULA
> GC> that IIRC forbids using that proprietary compiler with free software).
> 
>  I really don't think this could possibly be true considering the amount of
> free software that is regularly built with MSVC.

I keep an open mind. Let's take a fresh look.

  https://code.visualstudio.com/license

I don't notice their old ban on free software, so that seems to be an 
improvement.

| The software may collect information about you and your use of the software,
| and send that to Microsoft.

I refuse.

| The software may install automatic updates. By using the software, you agree 
to
| receive automatic updates without any additional notice, and permit Microsoft 
to
| download and install them for you.

No. The last time I allowed this company to do that was the "WGA" fiasco.
They installed some "antipiracy" junk, representing it as a "security upgrade";
it decided that my licensed copy of the OS wasn't "genuine" because I had
upgraded too much of my hardware. (It's a _server_.) I had to waste hours
working around this. Never again.

| You will not give feedback that is subject to a license that requires 
Microsoft
| to license its software or documentation to third parties because we include
| your feedback in them.

I hereby give that company such feedback. Anyone receiving such feedback
from me hereby agrees to stop using EULAs.

| You may not
|   work around any technical limitations in the software;
|   reverse engineer, decompile or disassemble the software
|   share, publish, or lend the software

Then I guess I mustn't debug errors in their software.

There's more I could comment on, but the case is conclusive.

> GC> >  AFAICS the problem is that mc_enum_base is DLL-exported but mc_enum<>
> GC> > itself is not. If we want to encapsulate all the methods above in
> GC> > liblmi.dll, then we shouldn't export mc_enum_base from it neither. But
> GC> > currently virtual methods such as all_strings(), declared with LMI_SO in
> GC> > the base class, but defined without it in the derived one, seem to 
> create
> GC> > problems.
> GC> 
> GC> That's deliberate, and I tested it successfully with mingw.org's gcc
> GC> (probably most versions from 2.95 through 3.4.5) and also with comeau
> GC> and borland.
> GC> 
> GC> The idea is that (virtual) base::foo() is externally visible, while
> GC> (overriding) derived::foo() is not: then the external world can call
> GC> into the shared library through the base class, and the shared library
> GC> dispatches the call internally to the override.
> 
>  This does mean that the vtbl of the derived class must be exported from
> the DLL and I don't know how to make this happen with gcc attributes other
> than by using LMI_SO on the entire class.

Wow--really? Yet it did work with three different compilers a decade ago.

> GC> >  Why don't we use USE_SO_ATTRIBUTES=1 (and, ideally, 
> --disable-auto-import)
> GC> > by default?
> GC> 
> GC> IIRC, the reason for this decision was that the mingw.org toolchain
> GC> worked much better this way around the turn of the century.
> 
>  Yes, there were performance problems with building libraries with a lot of
> exported functions with gcc 4.[56], see

[I was talking about gcc-2.95 or an early gcc-3.x . But that doesn't
change the conclusion below: it's worth retesting in this decade.]

> https://github.com/wxWidgets/wxWidgets/blob/v3.1.0/include/wx/dlimpexp.h#L38
> 
> and the comment preceding it. But this is not the case any more since gcc
> 4.7 and I think it could be well worth testing this again.
> 
>  BTW, on a tangentially related note: could we remove (i.e. can I make a
> patch removing) gcc version checks, at least with all versions < 4.8? As
> the code uses C++11 now and the gcc versions until 4.8 didn't have support
> for it (well, 4.6 and 4.7 did have beginnings of it with -std=c++0x, but it
> was insufficient anyhow), current code won't compile with them anyhow, so
> it bothers me to see checks like "LMI_GCC_VERSION < 30404" which can't
> possibly be true. Please let me know if I can get rid of them.

I removed two of those conditional blocks, and I want to do something
different with the 'wx_new' code that will remove some more. I'm still
reluctant to remove the others: they don't cost much to retain, and
the oddities they document might arise again with newer tools someday.

OTOH, I also removed lots and lots of wx conditionals. We haven't
materially changed them for five years. Around the wx-2.5.4 era, I had
the impression that some things like std::string conversions were not
necessarily stable, and I didn't want to remove a workaround that might
become necessary again later; but there's no reason to believe that now.
Besides, I never have been able to read wxCHECK_VERSION conditionals
fluently--something like
  #if wxVERSION < 3.1.0
would be much easier for me to parse--so today, as always in the past,
I found a simple one that I could understand:

#if !wxCHECK_VERSION(3,1,0)
#   error wxWidgets 3.1.0 or later is required for the test suite.
#endif

and copied that into my working notes with the annotation:

so...
  if !  marks obsolete code
  if    marks good code

and then I tried to remove virtually all instances...however, I have
little confidence that I got everything right, so would you mind
reviewing that changeset carefully?