Opened 13 years ago

Closed 13 years ago

#32386 closed defect (fixed)

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

Reported by: raimue (Rainer Müller) Owned by: ghosthound
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: Cc: neverpanic (Clemens Lang)
Port: wireshark

Description

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.

Attachments (1)

main.log.bz2 (40.1 KB) - added by raimue (Rainer Müller) 13 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 13 years ago by ghosthound

Owner: changed from opendarwin.org@… to ricci@…
Status: newassigned

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

comment:2 in reply to:  description Changed 13 years ago by 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.

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by 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

comment:5 in reply to:  4 Changed 13 years ago by 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?

Changed 13 years ago by raimue (Rainer Müller)

Attachment: main.log.bz2 added

comment:6 Changed 13 years ago by 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.

comment:7 Changed 13 years ago by 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".

comment:8 Changed 13 years ago by 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

comment:9 Changed 13 years ago by 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.

comment:10 Changed 13 years ago by neverpanic (Clemens Lang)

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.