["Geoff Lee" <geoff.lee99@xxxxxxxxx>]

Posting this to report success !!!!

The `ninja -j1` suggestion made the difference.  While it ran visibly slower than the simple `ninja` command which defaults to parallel builds, `ninja -j1` just kept working away steadily and finished all the remaining 294 steps without any hesitation.  I now have wireshark 2.6.4, successfully compiled on my Raspberry Pi for an armv7 processor.

In a separate build directory (and running at a separate time, ie not in competition with this build) I managed to compile `tshark` and `dumpcap` (and one or two of the other command line utilities, but explicitly excluding gui components like wireshark) using `ninja` parallel builds with only one "internal compile error" failure along the way.

I did look into submitting a bug report about the "internal compiler error", but the instructions are very firm (and rightly so) about including a minimal reproducible example of code which causes the error, about checking that it still occurs in the latest version of the compiler, and about making sure it is not a hardware issue.  My most recent experience suggests the problem happens only when ninja is using multiple cores, so reproducing the error reliably could be quite challenging; moreover it is not impossible that my CPU itself is not part of the problem (for eg this is quite possibly the most intensive and sustained work it has ever done, so maybe it is overheating or something ???).  So for now I call time while I'm ahead, and say a final heartfelt 

THANK YOU

for your help

Regards

Geoff

-----Original Message-----
From: Wireshark-dev [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
Sent: 13 September, 2018 10:48 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Pointers needed for building Wireshark 2.6.3 on a Raspberry Pi model 3B (armv7 processor?)

On Sep 12, 2018, at 5:07 PM, Geoff Lee <geoff.lee99@xxxxxxxxx> wrote:

> As explained in Guy Harris's most recent and very illuminating post,
> (almost) all of the "error" messages were in fact part of the CMake process,
> for probing my gcc compiler to see what features and options it supports.

Probing the compiler *and* the libraries/developer header files.

> I have now managed to track down the cause of my (CMake) problem. The final
> on screen error message was
> 
>> fatal: Not a git repository (or any of the parent directories): .git
>> CMake Error at CMakeLists.txt:3082 (string):
>>  string begin index: 1 is out of range 0 - 0
> 
> Looking at the CMakelists.txt file around line 3082, I found a comment in
> line 3042 which said
> 
>> # This will fail if we're not building from a git checkout.
> 
> Since I had downloaded and unzipped / untarred the wireshark code (ie I
> wasn't using a git checkout!), I suspected this might be the cause of my
> problem, so I created a new directory and cloned a copy of the code directly
> from the Github repository, via :
> 
> `git clone -b master-2.6 --single-branch
> https://github.com/wireshark/wireshark.git`
> 
> Executing (from a build directory parallel to the cloned git directory)
> `cmake -G Ninja ../wireshark` ran successfully, first time :-) , and
> produced a build.ninja file.  So now I am able to run `ninja` and see many
> compilations happening on my Raspberry Pi.  
> 
> I'm not really sure why the downloaded untarred unzipped version wouldn't
> pass cmake safely,

Because the CMakeLists.txt file is buggy; it's making an inappropriate assumption.

The 2.6 version of the top-level CMakeLists.txt appears to (implicitly) assume that, on a system with rpmbuild and git, you're doing a build from a cloned git directory, as per the comment.

The master branch version doesn't; perhaps we should backport the changes involved to 2.6, or otherwise not assume "git describe" will work unless there's a .git subdirectory of the current directory.

> but since the cloned git version does

...because you *are* doing it from a git checkout.

> Unfortunately I haven't succeeded yet to get to the end of the complete
> wireshark compilation process.  `ninja` runs for quite a while (several
> hours) than fails with a message about a gcc or c++ internal compiler bug.
> Restarting ninja picks up from where it fell over, and gets a bit further
> down the track before failing again. If I am interpreting the ninja messages
> correctly, I began with around 3000 compilation steps required; my first
> attempt managed about 1500 of these before failing; my second completed
> another 300 or so;  I'm currently down to only 262 left - but am only
> managing about 10 to 20 steps per ninja attempt before the compiler
> collapses.

If you restart it after it fails, it might not start out trying to compile the file on which it failed, especially if you're using the -j flag to do parallel builds, so it may make *some* progress.

However, I suspect you're eventually going to get to a point where the only files left to compile are the ones where the compiler crashes, and repeating the build will not make any further progress.

In that case, you'll need to file a bug against the compiler.

> I rather fear this is a limitation of my Raspberry Pi hardware
> (memory limit maybe, causing the compiler to choke on larger and more
> complex parts of the wireshark project??),

Possibly, but one would hope that a memory allocation failure in the compiler would be reported as a memory allocation failure, not an internal compiler bug. (I would argue that if it's *not* reported as a memory allocation failure, that, in and of itself, is an internal compiler bug - it should be catching memory allocation failures and reporting them as such.)
___________________________________________________________________________
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@xxxxxxxxxxxxx?subject=unsubscribe