Re: Visual Studio 2013/2015/2017 compatibility and libraries

[Graham Bloice <graham.bloice () trihedral com>]

On 24 April 2017 at 16:59, Peter Wu <peter () lekensteyn nl> wrote:

> On Mon, Apr 24, 2017 at 04:41:27PM +0100, Graham Bloice wrote:
> > On 24 April 2017 at 15:28, Pascal Quantin <pascal.quantin () gmail com>
> wrote:
> > > 2017-04-24 16:25 GMT+02:00 Graham Bloice <graham.bloice () trihedral com
> > :
> > > > On 24 April 2017 at 14:56, Pascal Quantin <pascal.quantin () gmail com>
> > > > wrote:
> > > >
> > > > > Hi Peter
> > > > >
> > > > > 2017-04-24 15:43 GMT+02:00 Peter Wu <peter () lekensteyn nl>:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Are there possible issues to be aware of when using the libraries
> (built
> > > > > > with mingw/msvc2013) with the Wireshark binaries built with VS2017?
> > > > > > When trying it with a friend, it seems to build and run with no
> issues.
> > > > > > I thought that there can be problems with combining different MSVC
> > > > > > runtime versions in one binary? Looking through the libraries, it
> seems
> > > > > > that there is a combination of at least MingW (GeoIP?) and MSVC
> (Lua).
> > > > > > (And apparently VS2015 (14.0) and VS2017 (14.1) are binary
> compatible.)
> > > > > >
> > > > >
> > > > > Just a side note: most of our 3rd party libraries are compiled with
> > > > > MinGW(32|64) except zlib (that we compile from scratch if I remember
> > > > > properly, cannot check right now), Lua for 2.0.X and 2.2.X and Qt.
> > > > > Historically we were using a MinGW Lua build but that was triggering
> a
> > > > > specific MinGW bug and we switched to MSVC based Lua library to work
> around
> > > > > this. But it required us to package Lua for every supported MSVC
> variants
> > > > > (as you need to have the corresponding C runtime installed on your
> PC while
> > > > > Wireshark installer packages the C runtime of the version you used to
> > > > > compile), which was painful. That's also why it is highly suggested
> to
> > > > > install the Qt package matching the MSVC version you intend to use
> for
> > > > > compilation.
> > > > > Since the MinGW bug was fixed, so master branch is again using the
> MinGW
> > > > > based Lua library. The only pre-compiled 3rd party package built
> with MSVC
> > > > > I can think to right now is Qt. As of today they offer MSVC2013 and
> > > > > MSVC2015 flavors (there is also a MinGW build but for 32 bits only).
> It
> > > > > looks like Qt 5.9 will provide a MSVC2017 version according to
> > > > > http://lists.qt-project.org/pipermail/development/2016-Decem
> > > > > ber/028159.html
> > > > >
> > > > > I think Graham proposed to discuss which MSVC to use (for 2.5 I
> guess)
> > > > > during Sharkfest US.
> > > > The major issue with using DLL's that are compiled with a different C
> > > > runtime (CRT) from the main application is the issue of different
> heaps for
> > > > each CRT and mallocing from one and freeing from a piece of code using
> > > > another leads to bad things happening.  If the malloc\free is all
> done from
> > > > within code that uses the same CRT then you should be OK.
> > >
> > > This is exactly the issue we faced with our GeoIP library (bug 13578)
> and
> > > why I added a GeoIP_free symbol.
> > >
> > >
> > > > The reason why the CRT changed with each version of Visual Studio was
> > > > that this was the only way for MS to service the CRT with bug fixes
> as it
> > > > couldn't be upgraded with Windows Updates as that might break various
> > > > applications (that used the ill-advised static linking to the CRT).
> > > >
> > > > The Universal CRT was introduced with Windows 10\VS 2015 to allow
> Windows
> > > > Updates to service a portion of the runtime [1].  The part of the CRT
> that
> > > > deals with heaps is now serviced by the OS, so theoretically apps
> built
> > > > with VS2015 or later (with the Windows 10 SDK) can now use DLL's
> compiled
> > > > with VS2015 or later.
> > >
> > > > [1]: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/intr
> > > > oducing-the-universal-crt/
> > >
> > > Nice. But do you know if practice is working as good as theory ?
> >
> > I don't.  This [1] earlier MS blog entry goes into a little more detail
> > about the split and says that the VS part contains process start-up and
> > exception handling stuff.
> >
> > I do note however that vcpkg doesn't appear to build VS specific versions
> > of libraries and is available for VS 2015 update 3 or later.
>
> I doubt that they will make it available for pre-2015 versions, but
> according to a vcpkg developer, there might be version suffixes in the
> future:
> https://www.reddit.com/r/cpp/comments/5ud9sr/if_youre_
> doing_windows_dev_and_not_using_vcpkg/
>
>     | | vcpkg install rapidjson:x64-windows
>     | And what compiler/version is this for?
>
>     We use a system of triplets that each define an entire, consistent
>     toolchain and build target. We only support targets of VS2015/2017
>     today (they're binary-interchangeable).
>
>     So, in the case of :x64-windows, this is built using the v140/v141
>     ABI against Windows Desktop amd64. In the future, we look forward to
>     adding :x64-win-vXYZ and beyond to ensure you never mix ABIs!
Who knows what will be in the next Visual Studio.  I haven't seen any
announcements, but as VS 2017 was only released just over a month ago I
don't expect any public announcements yet.

It's possible that future C++ language changes may force them to change the
ABI.

-- 
Graham Bloice

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe