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

[Vadim Zeitlin]

On Thu, 9 Mar 2017 23:36:45 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-03-09 15:40, Vadim Zeitlin wrote:
GC> > On Thu, 9 Mar 2017 14:59:45 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> That's a useful idea to keep in mind, but this one may be even better,
GC> > GC> if only because I can do it too (without accepting an unacceptable 
EULA
GC> > GC> that IIRC forbids using that proprietary compiler with free software).
GC> > 
GC> >  I really don't think this could possibly be true considering the amount 
of
GC> > free software that is regularly built with MSVC.
GC> 
GC> I keep an open mind. Let's take a fresh look.
GC> 
GC>   https://code.visualstudio.com/license
GC> 
GC> I don't notice their old ban on free software, so that seems to be an 
improvement.
GC> 
GC> | The software may collect information about you and your use of the 
software,
GC> | and send that to Microsoft.
GC> 
GC> I refuse.
GC> 
GC> | The software may install automatic updates. By using the software, you 
agree to
GC> | receive automatic updates without any additional notice, and permit 
Microsoft to
GC> | download and install them for you.
GC> 
GC> No. The last time I allowed this company to do that was the "WGA" fiasco.
GC> They installed some "antipiracy" junk, representing it as a "security 
upgrade";
GC> it decided that my licensed copy of the OS wasn't "genuine" because I had
GC> upgraded too much of my hardware. (It's a server.) I had to waste hours
GC> working around this. Never again.

 AFAIK you use Firefox which does exactly the same thing, Microsoft seems
to be just more straightforward about describing it. And, in practice, you
can configure the IDE to not send any telemetry and not install any updates
and the command line tools themselves, which is all we're really interested
in here, don't do neither in the first place anyhow. IMO you're reading too
much in what is just law boilerplate meant to prevent somebody from suing
Microsoft due to any of the actions described above. I'd worry much more
about the real malware not advertising its purpose or unintentional (and
hence not advertised neither...) security problems in the OS.

 But I agree that paranoid is probably better than pragmatic nowadays, so
if this still worries you, I'd recommend using MSVC in a VM without
Internet access. Whatever the EULA says, you can still do this.


GC> > GC> That's deliberate, and I tested it successfully with mingw.org's gcc
GC> > GC> (probably most versions from 2.95 through 3.4.5) and also with comeau
GC> > GC> and borland.
GC> > GC> 
GC> > GC> The idea is that (virtual) base::foo() is externally visible, while
GC> > GC> (overriding) derived::foo() is not: then the external world can call
GC> > GC> into the shared library through the base class, and the shared library
GC> > GC> dispatches the call internally to the override.
GC> > 
GC> >  This does mean that the vtbl of the derived class must be exported from
GC> > the DLL and I don't know how to make this happen with gcc attributes other
GC> > than by using LMI_SO on the entire class.
GC> 
GC> Wow--really? Yet it did work with three different compilers a decade ago.

 I don't know whether it's really so, but this is my understanding of how
things work: if the implementations of the derived class methods are in the
DLL itself and are not exported, the compiler simply can't construct a
vtbl, containing pointers to these methods, when compiling the code using
the DLL. So it has to be already present in the DLL itself and it has to be
exported from it. IOW I can't see how could it possibly be otherwise.

GC> I found a simple one that I could understand:
GC> 
GC> #if !wxCHECK_VERSION(3,1,0)
GC> #   error wxWidgets 3.1.0 or later is required for the test suite.
GC> #endif

 wxCHECK_VERSION() is the recommended way to check for wxWidgets version.

GC> and copied that into my working notes with the annotation:
GC> 
GC> so...
GC>   if !  marks obsolete code
GC>   if    marks good code
GC> 
GC> and then I tried to remove virtually all instances...however, I have
GC> little confidence that I got everything right, so would you mind
GC> reviewing that changeset carefully?

 I did reread the notification email and all the changes in it look correct
to me, thanks. I just wonder if we should remove the wxCHECK_VERSION() in
main_wx_test.cpp now that there is the same one in wx_checks.cpp anyhow?

VZ