[Tyson Key <tyson.key@xxxxxxxxx>]

Hi Jeff,

I've also noticed that with a modern x86-64-based machine (with 3GB of RAM, and a triple-core AMD Phenom II CPU), and a recent-ish version of GCC running under *buntu. It certainly seems like a good stress test for any compiler/OS/machine combination.

With that in mind, just what is packet-parlay.c being used for, anyway? (And why is it so large?)

Apologies in advance for the stupid questions,

Tyson.

2012/6/5 Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>

Jeff Morriss wrote:

Anders Broman wrote:

Hi,
It should be possible to make the giop plugins built in dissectors now, is that something we'd want to do?

I'd be all for it mainly so/if we can put packet-parlay.c at the top of the list of dissectors so that my "make -j X" can start the 15 minutes it takes to compile that beast as early as possible!  (Okay, 15 minutes is probably an exaggeration, but it does take a *very* long time to compile.)

Haha, thought this was funny: today I did a build on Solaris 10/SPARC with GCC 4.6.3 and, after about 45(!) minutes (yeah, I know, SPARCs aren't fast), got this when compiling packet-parlay.c:

epan/dissectors/packet-parlay.c:96834:17: note: variable tracking size limit

> exceeded with -fvar-tracking-assignments, retrying without

I wonder if modern GCCs will have that problem or if it's just this version or (doubtful) the architecture.  It would be really nice if this file could be split up.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
           mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe

--
                                          Fight Internet Censorship! http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844