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.)