Wireshark-dev: Re: [Wireshark-dev] packet-lorawan.c compile error because of stuff added yester

From: Erik de Jong <erikdejong@xxxxxxxxx>
Date: Thu, 15 Jun 2017 07:21:50 +0200


On Thu, Jun 15, 2017 at 3:09 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
On Jun 13, 2017, at 1:54 PM, Erik de Jong <erikdejong@xxxxxxxxx> wrote:

> Is it possible to have a petridish build for OSX as well? That's where the issue came from originally and why it got into the master branch.

That might be a good idea, but don't rely on it to catch problems with older versions of libraries that don't come with the OS; we provide our own libgcrypt in macOS, and we may - and probably *should* - upgrade to a newer version so as to make functionality that depends on newer libgcrypt available in the binary releases.

Adding something in tools/checkAPIs.pl that will warn when certain symbols are used might be an idea. That would mean 'blacklisting' a symbol with a certain preprocessor define for latest unsupported version and feeding each checked file though the preprocessor and looking for the symbol. Could be hard to get the environment correct to preprocess the code in the form it's actually getting compiled though as well as making that portable.
 

I might vote for *also* adding a 32-bit CentOS 6 buildbot, because

        1) it provides a non-Debian-derived Linux buildbot;

        2) I think CentOS 6 comes with a prehistoric version of Wireshark, and people often want to build something more modern on it;

        3) it might have old enough versions of various libraries to test for those versions;

        4) a 32-bit buildbot will have a UN*X test, as well as the existing Windows test, for code that assumes 64-bit pointers.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe