2017-04-16 16:11 GMT+02:00 Pascal Quantin <[email protected]>:
> Hi Graham, > > > Le 16 avr. 2017 15:35, "Graham Bloice" <[email protected]> a > écrit : > > Has there been any progress on building and testing libxml2 using OpenSUSE? > > > No as I was waiting for a confirmation that we would follow this path and > decide to add the dependency on the library. > I updated https://code.wireshark.org/review/#/c/20912 Pascal. > > On 5 April 2017 at 17:52, Graham Bloice <[email protected]> > wrote: > >> >> >> On 5 April 2017 at 14:48, Pascal Quantin <[email protected]> >> wrote: >> >>> Hi Ahmad and Graham, >>> >>> 2017-04-05 15:38 GMT+02:00 Graham Bloice <[email protected]>: >>> >>>> >>>> >>>> On 5 April 2017 at 14:11, Ahmad Fatoum <[email protected]> wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> I was advised on Gerrit to post this issue here as to garner wider >>>>> input. >>>>> >>>>> This concerns proposed Change-Id I13c0a2f408fb5c21bad7ab3d7971e >>>>> 0fa8ed7d783 [1] intending to add libxml2 as optional dependency to >>>>> Wireshark. >>>>> >>>>> I am currently preparing to submit upstream, changes I did to the EPL >>>>> v2 dissector (packet-epl.c). >>>>> >>>>> A significant change is the ability to optionally read in >>>>> user-supplied XML device descriptions and to extract >>>>> type/description/mapping information for aiding the dissection. See this >>>>> previous submission of mine to the mailing list: >>>>> https://www.wireshark.org/lists/wireshark-dev/201701/msg00154.html >>>>> >>>>> >>>>> Seeing as there also has been interest for libxml2 support in >>>>> dissectors in the past: >>>>> >>>>> https://www.wireshark.org/lists/wireshark-dev/201005/msg00108.html >>>>> >>>>> https://ask.wireshark.org/questions/36063/using-libxml2-in-m >>>>> y-own-dissector >>>>> >>>>> >>>>> I think, it would be a good idea to have this as optional dependency >>>>> as Glib's GMarkup may be inadequate or inconvenient for parsing actual >>>>> XML. >>>>> >>>>> >>>>> Looking forward to your feedback. >>>>> >>>>> Best regards, >>>>> Ahmad Fatoum >>>>> >>>>> [1] https://code.wireshark.org/review/#/c/20912/ >>>>> >>>> Thanks for the post, >>>> >>>> 1. Where will the Windows binaries come from and are these supported >>>> long term? The libXml2 downloads page indicates another site provides >>>> Windows binaries [1]. The binaries at that site in the 64 bit directory >>>> seem to be the most recent and are labelled as libXml2-2.9.3 [2]. The >>>> current release of libXml2 is 2.9.4 which has a number of security fixes >>>> among other bug fixes and enhancements [3] so it would appear that the >>>> Windows binaries are not being maintained. >>>> >>> >>> I suggest to use the binaries provided by openSUSE: they provide win32 >>> and win64 variants for libxml2 2.9.0 and we are already using their >>> packages for several third party libraries. If it is really required to >>> take the latest version, I can probbly give it a try (I already did this in >>> the past to package a newer version than the one from openSUSE). >>> >> >> That sounds good, I think for a new package we should use the latest >> available to ensure we pick up all known security issues. LibXml2 2.9.4 was >> released in May last year and 2.9.0 in Sep 2012. I realise I'm attempting >> to volunteer you for this task Pacal ;-) >> >> >>> >>>> 2. According to the diagram at [1], libXml2 depends on iconv and >>>> zlib. We currently build our own zlib, will that be suitable for the >>>> libXml2 dependency? What will be the source of the iconv binary >>>> (iconv-1.14 is available in the same download area as libXml2 [2])? >>>> >>> >>> Same thing: we can use the ones provided by openSUSE (we already have >>> those dependencies for other packages). >>> >> >> iconv doesn't seem to be in the latest Wireshark builds (2.3.x). I think >> iconv was required for GTK, regardless it seems that libXml2 requires it. >> We will need to check that the OpenSUSE libXml2 is happy with our >> built-from-source zlib. >> >> >>> >>>> >>>> 3. The readme.txt in the download area ([2]) has some "interesting" >>>> text: >>>> >>>> These are experimental 64bit binaries. For completeness, 32bit binaries >>>> built using the same method are also included. >>>> >>>> The libraries in these packages are made using GCC (MinGW) toolchain. It is >>>> presently not possible to use these libraries with any recent version of >>>> the >>>> Microsoft Visual C compiler because of conflicting C-runtimes. To help you >>>> resist the temptation, the import libraries (.LIB) are not provided at all. >>>> If you need these libraries in an environment which mandates the use of the >>>> Microsoft toolchain, you will have to build them from source yourself. >>>> >>>> and inspection of the download shows this is true, so it appears that >>>> we'll need to rebuild to obtain the import .lib file. >>>> >>> >>> As part of the process of integrating openSUSE libraries, we are >>> generating the .lib file and adding it in the package we upload on our >>> server, so it should be OK. >>> >>> >>>> 4. Microsoft have a Visual Studio porting effort underway called vcpkg >>>> [4], that does include libXml2, but unfortunately is only for VS2015 or >>>> later. If we move to VS2015 for main releases (post 2.4 release) then this >>>> may be a viable source for libXml2 and other packages we use. It might be >>>> possible to use this to build VS2013 libXml2. >>>> >>>> 5. Are there any manufacturers or tools that produce XML device >>>> description files for the EPL dissector such that choosing XML as the input >>>> format is the most sensible choice, or would another format be just as >>>> applicable? >>>> >>> >>> I agree XML can be painful, so this is a good question ;) >>> >>> >>>> >>>> >>>> [1]: https://www.zlatkovic.com/libxml.en.html >>>> [2]: ftp://ftp.zlatkovic.com/libxml/64bit/ >>>> [3]: http://xmlsoft.org/news.html >>>> [4]: https://github.com/Microsoft/vcpkg >>>> >>>> -- >>>> Graham Bloice >>>> >>>> >> >> -- >> Graham Bloice >> > > > > -- > Graham Bloice > Software Developer > Trihedral UK Limited > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscr > ibe > > >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
