[Wireshark-dev] Error while installing wireshark 1.10.3
Hello, I have compiled the source code of Wireshark version 1.10.3. Everything worked fine. But after the rpm was created, I tried to install it and got the following error. error: unpacking of archive failed on file /install/bin/dumpcap: cpio: cap_set_file failed - Operation not supported I tried to search it but to no avail. Can somebody help with the issue? Output of uname -a is: Linux 2.6.32-220.el6.x86_64 #1 SMP EST 2011 x86_64 x86_64 x86_64 GNU/Linux Thanks and Regards Vishnu Bhatt === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. === ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows build setup - Concept required
On 12/4/13 12:27 PM, Joerg Mayer wrote: > Hello, > > as Graham and I are working on getting the Windows build process to > a) work at all and b) be on par with the current nmake build process > we currently rely on the setup infrastructure of the nmake build. I > really don't like porting the "nmake -f Makefile.nmake setup" to cmake. > Not because it is hard to do but because the current setup has various > shortcomings > 1) zlib is installed as source only > 2) portaudio is installed as source only I know there are historical reasons for this but are they still valid? Zlib packages are available from the OpenSUSE Build Service (linked against msvcrt.dll) and Nuget (linked against multiple runtimes). Portaudio is also available from OBS. > 3) Every package is installed into its own subdirectory, sometimes with >its own structure CoApp has a standardized directory layout for libraries and include files called "Pivots": http://coapp.org/reference/autopackage-ref.html#Pivots "Pivot" is a nicer name than "deep explodey directory tree" but it seems sensible and worth adopting IMHO. > 4) glib2 contains zlib headers that break windows builds > 5) glib3 contains zlib headers that break windows builds This should be reported as a bug at https://build.opensuse.org/package/show/windows:mingw:win64/mingw64-zlib I'm sure patches are welcome. > 6) krb5 contains includes that export krb5-build internal flags and >thus cause warnings during compiles Is there a better library we can use for Kerberos? MIT, Secure Endpoints, and Heimdal all seem to provide packages that almost-but-not-quite meet our needs. I tried cross-compiling MIT Kerberos and Heimdal using MingW in the past but didn't have much luck. > 6) Except for gtk3 no packages provide compile (includes, cflags) or >linking (libs, ldflags) information. > 7) glib3 contains pkg-config files, but they contain a wrong paths >and unuseable compiler (gcc) flags The existence of the .pc files depends on my packaging scripts and the OBS .spec files for OBS-sourced packages. Adding them shouldn't be too difficult. The tricky part is getting them to point to the correct location on Windows. I'm not sure if we can use or modify the stock .pc files or if we'd have to create our own. > 8) The current setup process does not install QT I've been hesitant to switch this on since it's such a large download and I'm not sure which "Qt" should be installed. The Qt project provides official 32- and 64-bit installers for VS 2012 and a 32-bit installer for VS 2010. We provide 32- and 64-bit packages for VS 2010. We sign the EXEs and DLLs in our packages but the Qt project doesn't. I don't know if anyone provides VS 2013 packages. > 9) To build qtshark without wireshark still requires the installation >of gtk2 or gtk3 for glib, gmodule, gthread I think we should switch from the separate wireshark-gtk2 and wireshark-qt-release directories to a common deployment directory, e.g. "wireshark-deploy" or "wireshark-stage". This would presumably help to unify our build targets. (I'd also like to get rid of ui/qt/QtShark.pro at some point in favor of CMake. Qt Creator supports CMake projects well enough, and having to maintain QtShark.pro for different platforms is a pain.) > 10) The setup process does not allow for the simultanous installation >of gtk2 and gtk3 Does GTK3 work well enough on Windows to drop GTK2? This would simplify things quite a bit. > 11) The installation of some build tools (python, cmake, cygwin-stuff like > cat, bash) might be automated - depending on the setup script language > maybe not all of them. > > So maybe something more similar to the macosx setup is wanted. Not maybe > the compile-it-yourself approach but an installation into a standard > directory structure. > > So what I'd like to have is a script (.bat or maybe Powershell) that works > similar to the macosx-setup.sh script: > > - Contain a list of packages and their versions > - Download missing packages > - Download missing tools > - Install not-yet-installed packages (includes, libs) into a standard > directory structure > > Feedback, ideas, details anyone? Sounds good to me. I like Graham's suggestion of using Chocolatey/Nuget since they're currently the best option for package management under Windows. I'd be willing to convert our current Windows libraries to Nuget packages, and have them conform to Coapp's directory layout[1]. If we could find or create Chocolatey packages for Bison and Flex that would go a long way toward dropping the requirement for Cygwin. [1] The end goal being that someone else take over maintenance of the packages. Some men dream of the heavens. I dream of no longer having to create third-party Windows development libraries. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wires
Re: [Wireshark-dev] Windows build setup - Concept required
Re: creating/using a standard package directory structure on Windows
It sounds like you're suggesting that we take the
packages as distribited and move things
around to a standard structure. This sounds to me like the
effort to do this it might be crazy-making ...
Also: A few questions/comments: see inline:
> 1) zlib is installed as source only
As opposed to installing DLL's from a package ?
My understanding is that we need to build the zlib DLL
ourselves due to ensure that the right C runtime is used.
("cross C-runtime memory allocation issues").
2) portaudio is installed as source only
(As in 1) above ?)
3) Every package is installed into its own subdirectory, sometimes with
its own structure
4) glib2 contains zlib headers that break windows builds
right: it appears that the gtk2/includes dir is never
used as an include dir so that (fortunately) the correct
zlib includes are used. Ditto for the zlib DLL.
(It seems that the zlib DLL & includes distribdted
with our current GTK/GLib package are for
zlib v1.27 while we're actually building/using zlib v1.25)
In any case, as noted, we need to build our own ...
5) glib3 contains zlib headers that break windows builds
ditto
6) krb5 contains includes that export krb5-build internal flags and
thus cause warnings during compiles
When building how ?
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows build setup - Concept required
On 12/5/2013 3:02 PM, Bill Meier wrote: I like Gerald's answers much better than mine :) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows build setup - Concept required
2013/12/5 Gerald Combs > > 10) The setup process does not allow for the simultanous installation > >of gtk2 and gtk3 > > Does GTK3 work well enough on Windows to drop GTK2? This would simplify > things quite a bit. > Personally I find the GTK2 GUI much more polished than GTK3 on Windows (maybe just a matter of taste...). Regards, Pascal. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53683: /trunk/tools/ /trunk/tools/: make-dissector-reg.py
On 12/1/13 9:21 AM, Graham Bloice wrote: > > BTW, why is OSX using such an ancient version of Python. I believe only > 2.7 and 3.3 are supported by the Python folks. As I recall, Buildbot on each of the OS X builders was installed using the version of Python that shipped with each system. Both the PPC and 32-bit Intel builders were running OS X 10.5, which shipped with Python 2.5. I think the 64-bit Intel builder was running OS X 10.6 so it should be using Python 2.6, but it appears to be using 2.7. Various Python environment variables (PYTHONPATH, VERSIONER_PYTHON_PREFER_32_BIT, and VERSIONER_PYTHON_VERSION) are passed down to each build step, which determines the default version and library path. Unfortunately Buildbot doesn't have a way of un-setting them. It also appends to PYTHONPATH no matter what. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows build setup - Concept required
+1 -Original Message- From: Pascal Quantin To: Developer support list for Wireshark Sent: Thu, Dec 5, 2013 3:33 pm Subject: Re: [Wireshark-dev] Windows build setup - Concept required Personally I find the GTK2 GUI much more polished than GTK3 on Windows (maybe just a matter of taste...). Regards, Pascal. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53683: /trunk/tools/ /trunk/tools/: make-dissector-reg.py
On Dec 5, 2013, at 12:27 PM, Gerald Combs wrote: > On 12/1/13 9:21 AM, Graham Bloice wrote: >> >> BTW, why is OSX using such an ancient version of Python. I believe only >> 2.7 and 3.3 are supported by the Python folks. > > As I recall, Buildbot on each of the OS X builders was installed using > the version of Python that shipped with each system. Both the PPC and > 32-bit Intel builders were running OS X 10.5, which shipped with Python > 2.5. I think the 32-bit Intel builder is now running 10.6 (and building for 10.5-and-later). > I think the 64-bit Intel builder was running OS X 10.6 so it should > be using Python 2.6, but it appears to be using 2.7. I think it's now running 10.7 (and building for 10.6-and-later). ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows build setup - Concept required
writes: > +1 > > -Original Message- > From: Pascal Quantin > To: Developer support list for Wireshark > Sent: Thu, Dec 5, 2013 3:33 pm > Subject: Re: [Wireshark-dev] Windows build setup - Concept required > > Personally I find the GTK2 GUI much more polished than GTK3 on Windows (maybe just a matter of taste...). > > > Regards, > Pascal. +2 I find GTK3 hideous on Windows. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows build setup - Concept required
2013/12/5 Christopher Maynard > writes: > > > +1 > > > > -Original Message- > > From: Pascal Quantin > > To: Developer support list for Wireshark > > > Sent: Thu, Dec 5, 2013 3:33 pm > > Subject: Re: [Wireshark-dev] Windows build setup - Concept required > > > > Personally I find the GTK2 GUI much more polished than GTK3 on Windows > (maybe just a matter of taste...). > > > > > > Regards, > > Pascal. > > +2 > > I find GTK3 hideous on Windows. > I'm happy to see that I'm not alone :) As the idea is to avoid spending much effort in GTK UI, and unless someone knows how to easily fix this ugliness (template missing?), what about switching back to GTK2? :p Pascal. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53683: /trunk/tools/ /trunk/tools/: make-dissector-reg.py
On Dec 5, 2013, at 9:42 PM, Guy Harris wrote: > > On Dec 5, 2013, at 12:27 PM, Gerald Combs wrote: > >> On 12/1/13 9:21 AM, Graham Bloice wrote: >>> >>> BTW, why is OSX using such an ancient version of Python. I believe only >>> 2.7 and 3.3 are supported by the Python folks. >> >> As I recall, Buildbot on each of the OS X builders was installed using >> the version of Python that shipped with each system. Both the PPC and >> 32-bit Intel builders were running OS X 10.5, which shipped with Python >> 2.5. > > I think the 32-bit Intel builder is now running 10.6 (and building for > 10.5-and-later). Correct. > >> I think the 64-bit Intel builder was running OS X 10.6 so it should >> be using Python 2.6, but it appears to be using 2.7. > > I think it's now running 10.7 (and building for 10.6-and-later). Correct. Best regards Michael > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status Cmake Win32 support
> > > > > I still have the issue with GTK3, in that I have to comment out the > path > > > > "corrections" in FindGTK3.cmake. > > > > > > Hmm, can you please explain the problems you are encountering - I'd > like to > > > fix them. In case it involves rewriting the results from pkg-config, > can > > > you > > > please include the .pc file? > > > > In FindGTK3.cmake there is some code that modifies the paths found by > > pkg-config only on Windows. Doing this totally messed up the paths for > me, > > I commented out the block of code and everything just worked. Note that > > I'm using pkg-config from the gtk2 bundle not the Cygwin one. > > I can't find a pkg-config.exe in the gtk2 bundle. Where can I find it > (version, arch)? Do I need to do something special in the "nmake ... setup" > phase to get it? > > My eyes must have been crossed the other day. The pkg-config.exe in my wireshark-win32-libs\gtk2\bin dir is from the gtk2 bundle downloaded by the name setup. It reports itself as version 0.25, and has dependencies on intl.dll and libglib-2.0-0.dll. I did look around elsewhere and found pkg-configlite (http://sourceforge.net/projects/pkgconfiglite/) that includes the dependencies, so I copied that to my build dir and it worked as well (version 0.28). I have no idea how it does work, but the odd paths in the gtk3 .pc files are magically transformed into usable output by pkg-config\CMake without the path fiddling hacks currently in FindGTK3.cmake: GTK3_FOUND -- GTK3 includes: e:/Wireshark/wireshark-win32-libs/gtk3/include;e:/Wireshark/wireshark-win32-libs/gtk3/include/gtk-3.0;e:/Wireshark/wireshark-win32-libs/gtk3/include/cairo;e:/Wireshark/wireshark-win32-libs/gtk3/include/pango-1.0;e:/Wireshark/wireshark-win32-libs/gtk3/include/atk-1.0;e:/Wireshark/wireshark-win32-libs/gtk3/include/cairo;e:/Wireshark/wireshark-win32-libs/gtk3/include/pixman-1;e:/Wireshark/wireshark-win32-libs/gtk3/include;e:/Wireshark/wireshark-win32-libs/gtk3/include/freetype2;e:/Wireshark/wireshark-win32-libs/gtk3/include;e:/Wireshark/wireshark-win32-libs/gtk3/include/libpng15;e:/Wireshark/wireshark-win32-libs/gtk3/include/gdk-pixbuf-2.0;e:/Wireshark/wireshark-win32-libs/gtk3/include/libpng15;e:/Wireshark/wireshark-win32-libs/gtk3/include/glib-2.0;e:/Wireshark/wireshark-win32-libs/gtk3/lib/glib-2.0/include -- GTK3 libs: e:/Wireshark/wireshark-win32-libs/gtk3/lib/gtk-3.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/gtk-3.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/gdk-3.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/pangowin32-1.0.lib;C:/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/Lib/Gdi32.Lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/pangocairo-1.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/pango-1.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/atk-1.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/cairo.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/gdk_pixbuf-2.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/gio-2.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/gobject-2.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/glib-2.0.lib -- GTK3 definitions: -mms-bitfields ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status Cmake Win32 support
On 5 December 2013 21:49, Graham Bloice wrote: > > > > I still have the issue with GTK3, in that I have to comment out the >> path >> > > > "corrections" in FindGTK3.cmake. >> > > >> > > Hmm, can you please explain the problems you are encountering - I'd >> like to >> > > fix them. In case it involves rewriting the results from pkg-config, >> can >> > > you >> > > please include the .pc file? >> > >> > In FindGTK3.cmake there is some code that modifies the paths found by >> > pkg-config only on Windows. Doing this totally messed up the paths for >> me, >> > I commented out the block of code and everything just worked. Note that >> > I'm using pkg-config from the gtk2 bundle not the Cygwin one. >> >> I can't find a pkg-config.exe in the gtk2 bundle. Where can I find it >> (version, arch)? Do I need to do something special in the "nmake ... >> setup" >> phase to get it? >> >> > My eyes must have been crossed the other day. The pkg-config.exe in my > wireshark-win32-libs\gtk2\bin dir is from the gtk2 bundle downloaded by the > name setup. It reports itself as version 0.25, and has dependencies on > intl.dll and libglib-2.0-0.dll. I did look around elsewhere and found > pkg-configlite (http://sourceforge.net/projects/pkgconfiglite/) that > includes the dependencies, so I copied that to my build dir and it worked > as well (version 0.28). > > I have no idea how it does work, but the odd paths in the gtk3 .pc files > are magically transformed into usable output by pkg-config\CMake without > the path fiddling hacks currently in FindGTK3.cmake: > > GTK3_FOUND > -- GTK3 includes: > e:/Wireshark/wireshark-win32-libs/gtk3/include;e:/Wireshark/wireshark-win32-libs/gtk3/include/gtk-3.0;e:/Wireshark/wireshark-win32-libs/gtk3/include/cairo;e:/Wireshark/wireshark-win32-libs/gtk3/include/pango-1.0;e:/Wireshark/wireshark-win32-libs/gtk3/include/atk-1.0;e:/Wireshark/wireshark-win32-libs/gtk3/include/cairo;e:/Wireshark/wireshark-win32-libs/gtk3/include/pixman-1;e:/Wireshark/wireshark-win32-libs/gtk3/include;e:/Wireshark/wireshark-win32-libs/gtk3/include/freetype2;e:/Wireshark/wireshark-win32-libs/gtk3/include;e:/Wireshark/wireshark-win32-libs/gtk3/include/libpng15;e:/Wireshark/wireshark-win32-libs/gtk3/include/gdk-pixbuf-2.0;e:/Wireshark/wireshark-win32-libs/gtk3/include/libpng15;e:/Wireshark/wireshark-win32-libs/gtk3/include/glib-2.0;e:/Wireshark/wireshark-win32-libs/gtk3/lib/glib-2.0/include > -- GTK3 libs: > e:/Wireshark/wireshark-win32-libs/gtk3/lib/gtk-3.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/gtk-3.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/gdk-3.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/pangowin32-1.0.lib;C:/Program > Files (x86)/Microsoft > SDKs/Windows/v7.0A/Lib/Gdi32.Lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/pangocairo-1.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/pango-1.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/atk-1.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/cairo.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/gdk_pixbuf-2.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/gio-2.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/gobject-2.0.lib;e:/Wireshark/wireshark-win32-libs/gtk3/lib/glib-2.0.lib > -- GTK3 definitions: -mms-bitfields > > And for reference my gtk2 bundle is: gtk+-bundle_2.22.1-20101227_win32.zip ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status Cmake Win32 support
On 2 December 2013 16:14, Joerg Mayer wrote: > On Mon, Dec 02, 2013 at 02:28:43PM +, Graham Bloice wrote: > > On 2 December 2013 13:49, Joerg Mayer wrote: > > > > > > > > 8. Fix build of plugins. > > > > > > > > > > They build on my system (cmake with nmake and msbuild). > > > > > > > > > > > > > When building wireshark, I don't see any attempt to build them, maybe > > > > there's a missing dependency in CMakeLists. I haven't tried building > > > them > > > > explicitly. > > > > > > They are built automagically, i.e. right now I do out of tree builds > > > on 32 bit arch: > > > cmake ..\..\trunk 2>&1 | tee cmake.log > > > cmake --build . 2>&1 | tee build.log > > > With default cmakeoptions and default config.nmake files (OK, I > modified > > > config.nmake temporarily to pull in gtk2 as well in order to have both > > > gtk versions to test with). > > > > > > > On my cmake test env, using the VS201 generator and msbuild, building > > wireshark or tshark is successful without any plugins being built. > > Perhaps see below. > > > Just updated to r53798 and an msbuild of wireshark using the VS2010 solution (msbuild Wireshark.sln /maxcpucount /p:Configuration=Release /t:Executables\wireshark) still doesn't build any plugins. I can build a plugin by specifying them directly, e.g. msbuild Wireshark.sln /maxcpucount /p:Configuration=Release /t:Plugins\mate Better news is that all the executables now build except for text2pcap. I get some warnings for qtshark: E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : The name 'layoutWidget' (QWidget) is already in use, defaulting to 'layoutWidget1'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : The name 'layoutWidget' (QWidget) is already in use, defaulting to 'layoutWidget2'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : The name 'layoutWidget' (QWidget) is already in use, defaulting to 'layoutWidget3'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : The name 'layoutWidget' (QWidget) is already in use, defaulting to 'layoutWidget4'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : The name 'layoutWidget' (QWidget) is already in use, defaulting to 'layoutWidget5'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] RCC : warning : No resources in 'E:/Wireshark/trunk/ui/qt/welcome.qrc'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows build setup - Concept required
On 5 December 2013 21:06, Pascal Quantin wrote: > 2013/12/5 Christopher Maynard > >> writes: >> >> > +1 >> > >> > -Original Message- >> > From: Pascal Quantin >> > To: Developer support list for Wireshark >> >> > Sent: Thu, Dec 5, 2013 3:33 pm >> > Subject: Re: [Wireshark-dev] Windows build setup - Concept required >> > >> > Personally I find the GTK2 GUI much more polished than GTK3 on Windows >> (maybe just a matter of taste...). >> > >> > >> > Regards, >> > Pascal. >> >> +2 >> >> I find GTK3 hideous on Windows. >> > > I'm happy to see that I'm not alone :) > As the idea is to avoid spending much effort in GTK UI, and unless someone > knows how to easily fix this ugliness (template missing?), what about > switching back to GTK2? :p > > > The GTK3 haters thread is over there --> ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows build setup - Concept required
On 5 December 2013 19:59, Gerald Combs wrote: > On 12/4/13 12:27 PM, Joerg Mayer wrote: > > Hello, > > > > as Graham and I are working on getting the Windows build process to > > a) work at all and b) be on par with the current nmake build process > > we currently rely on the setup infrastructure of the nmake build. I > > really don't like porting the "nmake -f Makefile.nmake setup" to cmake. > > Not because it is hard to do but because the current setup has various > > shortcomings > > > 1) zlib is installed as source only > > 2) portaudio is installed as source only > > I know there are historical reasons for this but are they still valid? > Zlib packages are available from the OpenSUSE Build Service (linked > against msvcrt.dll) and Nuget (linked against multiple runtimes). > Portaudio is also available from OBS. > I could try them out. > > > 3) Every package is installed into its own subdirectory, sometimes with > >its own structure > > CoApp has a standardized directory layout for libraries and include > files called "Pivots": > > http://coapp.org/reference/autopackage-ref.html#Pivots > > "Pivot" is a nicer name than "deep explodey directory tree" but it seems > sensible and worth adopting IMHO. > I still haven't looked into CoApp. How does it play with Chocolatey? > > > 4) glib2 contains zlib headers that break windows builds > > 5) glib3 contains zlib headers that break windows builds > > This should be reported as a bug at > https://build.opensuse.org/package/show/windows:mingw:win64/mingw64-zlib > I'm sure patches are welcome. > I shall try to do this. > > > 6) krb5 contains includes that export krb5-build internal flags and > >thus cause warnings during compiles > > Is there a better library we can use for Kerberos? MIT, Secure > Endpoints, and Heimdal all seem to provide packages that > almost-but-not-quite meet our needs. I tried cross-compiling MIT > Kerberos and Heimdal using MingW in the past but didn't have much luck. > > > 6) Except for gtk3 no packages provide compile (includes, cflags) or > >linking (libs, ldflags) information. > > 7) glib3 contains pkg-config files, but they contain a wrong paths > >and unuseable compiler (gcc) flags > > The existence of the .pc files depends on my packaging scripts and the > OBS .spec files for OBS-sourced packages. Adding them shouldn't be too > difficult. The tricky part is getting them to point to the correct > location on Windows. I'm not sure if we can use or modify the stock .pc > files or if we'd have to create our own. > My experiments with pkg-config from the gtk2 bundle and from pkg-configlite and the gtk3 bundle .pc files shows that "it just works". The bundle .pc files have odd *nixy type paths in them but pkg-config and CMake sort all that out (with my modified FindGTK3.cmake) > > > 8) The current setup process does not install QT > > I've been hesitant to switch this on since it's such a large download > and I'm not sure which "Qt" should be installed. The Qt project provides > official 32- and 64-bit installers for VS 2012 and a 32-bit installer > for VS 2010. We provide 32- and 64-bit packages for VS 2010. We sign the > EXEs and DLLs in our packages but the Qt project doesn't. I don't know > if anyone provides VS 2013 packages. > Folks only have to download it as often as it changes! Or is the issue server resources? > > 9) To build qtshark without wireshark still requires the installation > >of gtk2 or gtk3 for glib, gmodule, gthread > > I think we should switch from the separate wireshark-gtk2 and > wireshark-qt-release directories to a common deployment directory, e.g. > "wireshark-deploy" or "wireshark-stage". This would presumably help to > unify our build targets. > Ack > (I'd also like to get rid of ui/qt/QtShark.pro at some point in favor of > CMake. Qt Creator supports CMake projects well enough, and having to > maintain QtShark.pro for different platforms is a pain.) > > > 10) The setup process does not allow for the simultanous installation > >of gtk2 and gtk3 > > Does GTK3 work well enough on Windows to drop GTK2? This would simplify > things quite a bit. > It's OK for me but there are some folks complaining about it from the cheap seats :-) > > > 11) The installation of some build tools (python, cmake, cygwin-stuff > like > > cat, bash) might be automated - depending on the setup script > language > > maybe not all of them. > > > > So maybe something more similar to the macosx setup is wanted. Not maybe > > the compile-it-yourself approach but an installation into a standard > > directory structure. > > > > So what I'd like to have is a script (.bat or maybe Powershell) that > works > > similar to the macosx-setup.sh script: > > > > - Contain a list of packages and their versions > > - Download missing packages > > - Download missing tools > > - Install not-yet-installed packages (includes, libs) into a standard > > directory structure > > > > Feedback, ideas, details
Re: [Wireshark-dev] Windows build setup - Concept required
Before replying to some of the points, I want to clarify something: This is about problems I have encountered in a current setup (no "old" libs package, current source, clean out of tree setup and build). Also, when I mentioned setup-macosx.sh I didn't take into account that some people who are not interested in OS X may not know what it does (or at least not all the details): - At the beginning it has a section that defines the package versions (similar to config.nmake but only once, as there is no need to differentiate between 32bit and 64bit). - These source(!) packages are downloaded, unpacked, patches from the Wireshark sources (macosx-support-lib-patches/) are applied if necessary, they are compiled and then installed into a common tree. On Thu, Dec 05, 2013 at 10:20:58PM +, Graham Bloice wrote: > On 5 December 2013 19:59, Gerald Combs wrote: > > > On 12/4/13 12:27 PM, Joerg Mayer wrote: > > > as Graham and I are working on getting the Windows build process to > > > a) work at all and b) be on par with the current nmake build process > > > we currently rely on the setup infrastructure of the nmake build. I > > > really don't like porting the "nmake -f Makefile.nmake setup" to cmake. > > > Not because it is hard to do but because the current setup has various > > > shortcomings > > > > > 1) zlib is installed as source only > > > 2) portaudio is installed as source only > > > > I know there are historical reasons for this but are they still valid? > > Zlib packages are available from the OpenSUSE Build Service (linked > > against msvcrt.dll) and Nuget (linked against multiple runtimes). > > Portaudio is also available from OBS. My complaint is a different one: Why don't we compile these two packages at setup time? At least for zlib it seems simple enough if you have cmake installed (see README.cmake). > I could try them out. > > > > > > 3) Every package is installed into its own subdirectory, sometimes with > > >its own structure > > > > CoApp has a standardized directory layout for libraries and include > > files called "Pivots": > > > > http://coapp.org/reference/autopackage-ref.html#Pivots > > > > "Pivot" is a nicer name than "deep explodey directory tree" but it seems > > sensible and worth adopting IMHO. > > > > I still haven't looked into CoApp. How does it play with Chocolatey? I have no problem with individual install dirs for each package and arch, as long as all packages follow the same schema. > > > 4) glib2 contains zlib headers that break windows builds > > > 5) glib3 contains zlib headers that break windows builds > > > > This should be reported as a bug at > > https://build.opensuse.org/package/show/windows:mingw:win64/mingw64-zlib > > I'm sure patches are welcome. > > > > I shall try to do this. My complaint is not about these problems but about the fact that the install process doesn't fix it. Because of this we have to work around it in the toplevel CMakeLists.txt > > > 6) krb5 contains includes that export krb5-build internal flags and > > >thus cause warnings during compiles > > > > Is there a better library we can use for Kerberos? MIT, Secure > > Endpoints, and Heimdal all seem to provide packages that > > almost-but-not-quite meet our needs. I tried cross-compiling MIT > > Kerberos and Heimdal using MingW in the past but didn't have much luck. My complaint is not about these problems but about the fact that the install process doesn't fix it - instead we work around this in the source (packet-kerberos.c) > > > 6) Except for gtk3 no packages provide compile (includes, cflags) or > > >linking (libs, ldflags) information. > > > 7) glib3 contains pkg-config files, but they contain a wrong paths > > >and unuseable compiler (gcc) flags > > > > The existence of the .pc files depends on my packaging scripts and the > > OBS .spec files for OBS-sourced packages. Adding them shouldn't be too > > difficult. The tricky part is getting them to point to the correct > > location on Windows. I'm not sure if we can use or modify the stock .pc > > files or if we'd have to create our own. > > > > My experiments with pkg-config from the gtk2 bundle and from pkg-configlite > and the gtk3 bundle .pc files shows that "it just works". The bundle .pc > files have odd *nixy type paths in them but pkg-config and CMake sort all > that out (with my modified FindGTK3.cmake) And with the version number I could now identify that ancient ;-) install and reproduce it. They probably do something similar to what I do in cmake. I'Ve checked in a fix to no longer convert windows paths. > > > 8) The current setup process does not install QT > > > > I've been hesitant to switch this on since it's such a large download > > and I'm not sure which "Qt" should be installed. The Qt project provides > > official 32- and 64-bit installers for VS 2012 and a 32-bit installer > > for VS 2010. We provide 32- and 64-bit packages for VS 2010. We sign the > > EXEs and DLLs in our package
Re: [Wireshark-dev] Status Cmake Win32 support
On Thu, Dec 05, 2013 at 10:04:36PM +, Graham Bloice wrote: > > > > They are built automagically, i.e. right now I do out of tree builds > > > > on 32 bit arch: > > > > cmake ..\..\trunk 2>&1 | tee cmake.log > > > > cmake --build . 2>&1 | tee build.log > > > > With default cmakeoptions and default config.nmake files (OK, I > > modified > > > > config.nmake temporarily to pull in gtk2 as well in order to have both > > > > gtk versions to test with). > > > > > > > > > > On my cmake test env, using the VS201 generator and msbuild, building > > > wireshark or tshark is successful without any plugins being built. > > > > Perhaps see below. > > > > > > > Just updated to r53798 and an msbuild of wireshark using the VS2010 > solution (msbuild Wireshark.sln /maxcpucount /p:Configuration=Release > /t:Executables\wireshark) still doesn't build any plugins. > > I can build a plugin by specifying them directly, e.g. msbuild > Wireshark.sln /maxcpucount /p:Configuration=Release /t:Plugins\mate Ah, after looking up the meaning of the /t: switch I think I understand what is going on here: In cmake there is no dependency of *shark and dftest on the existence of the plugins. My command line builds everything. This should be the same on all operating systems. I'll look into that next week if I remember it. > Better news is that all the executables now build except for text2pcap. How does the build fail? > I get some warnings for qtshark: > > E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : > The name 'layoutWidget' (QWidget) is already in use, defaulting to > 'layoutWidget1'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] > E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : > The name 'layoutWidget' (QWidget) is already in use, defaulting to > 'layoutWidget2'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] > E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : > The name 'layoutWidget' (QWidget) is already in use, defaulting to > 'layoutWidget3'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] > E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : > The name 'layoutWidget' (QWidget) is already in use, defaulting to > 'layoutWidget4'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] > E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : > The name 'layoutWidget' (QWidget) is already in use, defaulting to > 'layoutWidget5'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] > RCC : warning : No resources in > 'E:/Wireshark/trunk/ui/qt/welcome.qrc'. > [E:\Wireshark\build\ui\qt\qtui.vcxproj] I get them as well, they are "mistakes" in the code and are not Win specific. I don't remember whether the messages are Win only, but the mistakes are not. Ciao Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Status Cmake Win32 support
On Dec 5, 2013, at 3:39 PM, Joerg Mayer wrote: > On Thu, Dec 05, 2013 at 10:04:36PM +, Graham Bloice wrote: > >> I get some warnings for qtshark: >> >> E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : >> The name 'layoutWidget' (QWidget) is already in use, defaulting to >> 'layoutWidget1'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] >> E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : >> The name 'layoutWidget' (QWidget) is already in use, defaulting to >> 'layoutWidget2'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] >> E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : >> The name 'layoutWidget' (QWidget) is already in use, defaulting to >> 'layoutWidget3'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] >> E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : >> The name 'layoutWidget' (QWidget) is already in use, defaulting to >> 'layoutWidget4'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] >> E:\Wireshark\trunk\ui\qt\capture_interfaces_dialog.ui : warning : >> The name 'layoutWidget' (QWidget) is already in use, defaulting to >> 'layoutWidget5'. [E:\Wireshark\build\ui\qt\qtui.vcxproj] >> RCC : warning : No resources in >> 'E:/Wireshark/trunk/ui/qt/welcome.qrc'. >> [E:\Wireshark\build\ui\qt\qtui.vcxproj] > > I get them as well, they are "mistakes" in the code and are not Win specific. > I don't remember whether the messages are Win only, They're not Windows-only. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
