On 24 April 2017 at 16:59, Peter Wu <pe...@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.quan...@gmail.com> > wrote: > > > > > > > > > > > 2017-04-24 16:25 GMT+02:00 Graham Bloice <graham.blo...@trihedral.com > >: > > > > > >> > > >> > > >> On 24 April 2017 at 14:56, Pascal Quantin <pascal.quan...@gmail.com> > > >> wrote: > > >> > > >>> Hi Peter > > >>> > > >>> 2017-04-24 15:43 GMT+02:00 Peter Wu <pe...@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-requ...@wireshark.org?subject=unsubscribe
