wireshark @1.6.4_0: Build problem with llvm-gcc-4.2

[raimue (Rainer Müller)]

wireshark @1.6.4_0 forces the use of llvm-gcc-4.2 instead of clang. I experienced a build problem with llvm-gcc-4.2, where the compiler seemed to enter and endless loop and started allocating more and more memory.

$ sudo port -v build wireshark build.jobs=1
...
libtool: compile:  ccache /Developer/usr/bin/llvm-gcc-4.2 -DHAVE_CONFIG_H -I. -I. -I../.. -I./../.. -I./.. -I/opt/local/include -I/opt/local/include -I/opt/local/include -I/opt/local/include -I/opt/local/include -DPLUGIN_DIR=\"/opt/local/lib/wireshark/plugins/1.6.4\" -no-cpp-precomp "-D_U_=__attribute__((unused))" -pipe -O2 -arch x86_64 -Wall -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wpointer-arith -Wno-pointer-sign -Wcast-align -Wformat-security -I/opt/local/include -D_REENTRANT -I/opt/local/include/gtk-2.0 -I/opt/local/lib/gtk-2.0/include -I/opt/local/include/atk-1.0 -I/opt/local/include/cairo -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/pango-1.0 -I/opt/local/include/gio-unix-2.0/ -I/opt/local/include -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/libpng14 -I/opt/local/include -I/opt/local/include -MT libdissectors_la-packet-rtmpt.lo -MD -MP -MF .deps/libdissectors_la-packet-rtmpt.Tpo -c packet-rtmpt.c  -fno-common -DPIC -o .libs/libdissectors_la-packet-rtmpt.o

It just hangs here and I see a cc1 process consuming lots of memory. I retried the build with clang instead, which works fine for me.

What was the reason to force the use of llvm-gcc-4.2? I suggest to reverse this change.

[ghosthound]

When built with clang, (from Xcode 4.2), wireshark fails to run (on Lion at least). What OS/rev are you using?

[ryandesign (Ryan Carsten Schmidt)]

Replying to raimue@…:

What was the reason to force the use of llvm-gcc-4.2?

To resolve the runtime crash reported in #31615. Note that further comments there say that clang would work if the optimization flag were removed. Maybe we should do that instead. And, if you're saying llvm-gcc-4.2 does not work, then we should have the port instead use clang whenever it would otherwise use llvm-gcc-4.2.

[raimue (Rainer Müller)]

Hm, my wireshark build with clang works. Although I have to admit I used an outdated version of Xcode 4.1 (Build version 4B110) for this installation. I will rebuild it again with the current Xcode 4.2.1 and report back. Sorry, I should have checked the Xcode version beforehand.

[raimue (Rainer Müller)]

With Xcode 4.2.1 (Build version 4D502), I still see the build problem with llvm-gcc-4.2; the build stalls at the same location as given in the report above. Switching to clang did not work, the resulting binary gives a segmentation fault as reported in #31615.

I was able to get a working wireshark with clang and optimizations disabled:

sudo port -v install wireshark configure.compiler=clang configure.optflags=-O0

[ghosthound]

Replying to raimue@…:

With Xcode 4.2.1 (Build version 4D502), I still see the build problem with llvm-gcc-4.2; the build stalls at the same location as given in the report above. Switching to clang did not work, the resulting binary gives a segmentation fault as reported in #31615.

I was able to get a working wireshark with clang and optimizations disabled:

sudo port -v install wireshark configure.compiler=clang configure.optflags=-O0

Can you post the build log with llvm-gcc-4.2, or otherwise get it to me?

[raimue (Rainer Müller)]

Here is a compressed log file of the build. I deliberately killed the cc1 process which consumed lots of memory, thus the log file contains the error about being killed by signal 15.

[neverpanic (Clemens Lang)]

The culprit apparently is -fvar-tracking, which is enabled automatically when compiling with debug info and optimization. I could successfully build wireshark 1.6.4 (and 1.7.0 for that matter) with Xcode 4.2.1's llvm-gcc-4.2 when I specified configure.cflags="-fno-var-tracking".

[glop@…]

I just hit this problem while trying to build Wireshark using Homebrew...

Strange thing though: It didn't happen again when I retried.

Same file: packet-rtmpt.c

Xcode 4.2.1, llvm-gcc -v: gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)

I wonder if this bug is related: ​http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371

[neverpanic (Clemens Lang)]

I have no idea why it doesn't happen to you on retry, it used to be reproducible always on MacPorts. I'm testing if it's still broken with wireshark 1.6.5 as we speak and will fix if it is.

The bug seems similar, but all the testcases mentioned in the bug report took quite long but finished eventually, whereas I had the wireshark compile running for about half an hour with extensive swapping and no progress (although I didn't look into debugging it). I however doubt the gcc guys will support llvm-gcc-4.2, so it's not really worth reporting.

[neverpanic (Clemens Lang)]

r89562.