Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] master 43a81b6: Add some information on

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Fri, 01 Aug 2014 16:18:08 -0400
On 08/01/14 14:04, Evan Huus wrote:
On Fri, Aug 1, 2014 at 1:58 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx
<mailto:jeff.morriss.ws@xxxxxxxxx>> wrote:

    On 08/01/14 13:54, Guy Harris wrote:


        On Aug 1, 2014, at 2:00 AM, Peter Wu <peter@xxxxxxxxxxxxx
        <mailto:peter@xxxxxxxxxxxxx>> wrote:

            On Thursday 31 July 2014 16:40:53 Guy Harris wrote:

                On Jul 31, 2014, at 3:11 PM, Peter Wu
                <peter@xxxxxxxxxxxxx <mailto:peter@xxxxxxxxxxxxx>> wrote:

            [..]

                    Oh my, that filesystem.c code is really ugly and
                    relying on a lot of
                    assumptions. Why does it need to distinguish build
                    dirs from other dirs in
                    the first place?


                So that you can just type "./wireshark" or "./tshark"
                after you've done a
                build, and have it Just Work, rather than having to
                install Wireshark or
                TShark before you can run it.  Note that we run TShark
                to generate some man
                pages.


            The binaries themselves already Just Work(tm) without
            libtool because CMake
            sets RPATH.


        Presumably by "the binaries themselves already Just Work" you
        mean "the binaries are, at least, capable of finding the
        relevant shared libraries, even if the code *in* those binaries,
        and the shared libraries in question, fails to find the data
        files such as RADIUS dictionaries, DIAMETER dictionaries, FIX
        field description files, etc., and thus doesn't Just Work", as
        that's a more precise description of the situation.

        I.e., the problem has nothing to do with finding the *shared
        libraries*, it has to to with finding the *data files*.

        For autotools builds, the data files *are* found, without any
        need for the user to specify anything themselves, for in-tree
        builds; the code determines the location of those data files
        based on the location of the executable image, so that it picks
        up the data files from the source tree.

        For out-of-tree builds, however, that obviously doesn't work, as
        the executable isn't in the source tree.


    Actually out-of-tree builds can find the data files in out-of-tree
    builds due to another hack that I put in (bug 5664/r38070).


Well it's not finding all of them or the out-of-tree test suite would
work (right now it fails to find init.lua and the name-resolutions
settings, so those tests fail).

I posted fixes for the nameres failure (change 3334) and the wslua failure (change 3337). The wslua failure wasn't because init.lua wasn't being found (it was) it was because taps_wslua.c was empty in an out-of-source-tree build.