Hi Francisco, That looks to me that the Wireshark splash image isn’t properly packed. There are two version of it, one standard (called wssplash.png) which is used in the released versions, and one development (called wssplash_dev.png) which is used in the development versions. Somehow the applicable graphic is not available. Someone with knowledge of the macOS packaging might have a clue.
In the mean time, this shouldn’t really hold you back improving your change, as it can be reviewed/tested in Wireshark (Qt). Are you still pursuing this? Thanks, Jaap > On 20 Oct 2016, at 20:17, Francisco Javier Sanchez-Roselly > <franciscojavier.sanchezrose...@ujaen.es> wrote: > > hi Me (All): > >> On 13 Oct 2016, at 22:49, Francisco Javier Sanchez-Roselly >> <franciscojavier.sanchezrose...@ujaen.es> wrote: >> >> hi All, >> >> i have been following the thread as it was impossible for me to install >> Wireshark from the sources in Sierra -the previous El Capitan installation >> worked nicely-. >> >> i have tried the steps described in README.macos, afterwards i have >> installed the ‘required' ports but my install hangs because of an error on >> ‘uic-qt5’. finally i did configure successfully disabling qt, but >> wireshark-gtk stops because of a missed image file. > > after a week and several compilations on OS X Sierra, i can asses > wireshark-gtk execution hangs on this error: > > (process:90095): GLib-GObject-WARNING **: gsignal.c:2475: signal `realize' is > invalid for instance `0x7fc36b00f060' of type `(null)' > ** > ERROR:gui_utils.c:2076:GdkPixbuf *ws_gdk_pixbuf_new_from_resource(const char > *): assertion failed (err == NULL): El recurso en > «/org/wireshark/image/wssplash_dev.png» no existe ((null), 0) > Abort trap: 6 > > you can build and run using Qt from qt.io -impossible for me using MacPorts-. > > regards. > >> i please ask for any guidance on my journey. sorry if my problem is a >> trivial one. >> >> thanks, regards. >> >> pd.- i can post the specific errors if required. >> >>> On 12 Oct 2016, at 22:08, Graham Bloice <graham.blo...@trihedral.com> wrote: >>> >>> >>> >>> On 12 October 2016 at 20:15, Evan Huus <eapa...@gmail.com> wrote: >>> On Wed, Oct 12, 2016 at 3:04 PM, Guy Harris <g...@alum.mit.edu> wrote: >>> > On Oct 12, 2016, at 11:41 AM, Jeff Morriss <jeff.morriss...@gmail.com> >>> > wrote: >>> > >>> >> Just for fun I did a quick search for that Usage output (minus the >>> >> "Wireshark" prefix which is clearly $0) and found this program which has >>> >> that exact output: >>> >> >>> >> https://github.com/the-tcpdump-group/libpcap/blob/master/tests/capturetest.c >>> > >>> > Yeah, that's one of a pile of test programs I wrote to test various >>> > libpcap features. >>> > >>> > The binary is *not* part of a libpcap installation, so there shouldn't be >>> > an executable for it unless the test programs were built. >>> > >>> > Evan, what happens if you remove the build directory entirely, re-create >>> > it, do a cmake in it, and then redo the build? >>> >>> Completely blowing away the build directory and starting again seems >>> to have fixed it. That was really weird, especially since (to my >>> knowledge) I don't even have a source build of libpcap on this >>> machine. >>> >>> Anywho, thanks everyone for the help! >>> >>> >>> CMake standard repair #1 :-) >>> >>> -- >>> 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
