On Fri, Jun 14, 2013 at 05:23:13PM +0200, Martin Kaiser wrote:
> Thus wrote Joerg Mayer (jma...@loplof.de):
>
> > I'm receiving coverity reports via email. Unfortunately I don't really have
> > the time to look at them most of the time.
> > What I might do if there is interest in it: I could open
On Tue, Jun 18, 2013 at 12:34:08PM -0700, Dirk Jagdmann wrote:
> I'm studying cmake rules in the plugin/ directory. I can not find
> out, how cmake knows how to build the plugin.c file for each of the
> plugins. Where is this defined?
register_dissector_files(plugin.c
plugin
${DISS
for WANT_PACKET_EDITOR:
In file included from /home/jmayer/work/wireshark/svn/trunk/wiretap/wtap.h:32:0,
from /home/jmayer/work/wireshark/svn/trunk/epan/nstime.h:30,
from
/home/jmayer/work/wireshark/svn/trunk/epan/frame_data.h:30,
from /home/jmay
Probably the simplest fix is to add -fno-strict-aliasing to the build flags on
FreeBSD.
On 2013-06-18, at 4:14 PM, Stephen Fisher
wrote:
> When trying to compile Wireshark (SVN trunk) on FreeBSD for the first time in
> a long time, I ran across a familiar error:
>
> dfilter-macro.c: In f
What should the fix ultimately be if one way breaks FreeBSD/gcc 4.2.1 compiles
and if it introduces C++ compatibility issues (which I'm not familiar with
since I haven't been following development for a while lately).
maybe "&((void*)macros)" helps?
--
When trying to compile Wireshark (SVN trunk) on FreeBSD for the first time in a
long time, I ran across a familiar error:
dfilter-macro.c: In function 'dfilter_macro_init':
dfilter-macro.c:614: warning: dereferencing type-punned pointer will break
strict-aliasing rules
However, line 614
The script doesn't work on Leopard *now*, and didn't work on Leopard even
*before* your changes, because the versions of support libraries we download
either don't configure or don't build on Leopard; I spent some time trying to
make it work, but it looked as if it'd just be too much effort, so
I've created https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8821
with my suggestion. We can continue to discuss there if/what/how we'd
like to determine the optimum number of parallel make jobs.
--
---> Dirk Jagdmann
> http://cubic.org/~doj
-> http://llg.cubic.org
_
As per the subject, as of revision 50020.
If I've missed an API somewhere please let me know, but as far as I
can tell every function defined in emem.h has a wmem equivalent.
This means that unless there are any objections, emem is now
deprecated. New code should only use wmem.
Most of the APIs
On Jun 18, 2013, at 12:01 PM, Dirk Jagdmann wrote:
> - do we want to make a smart decision on the number of parallel make jobs,
> possibly derived from the number of cores?
>
> My personal opinion is yes. On OsX using the sysctl mentioned by Guy is
> probably a good starting point. Adding my
I'm studying cmake rules in the plugin/ directory. I can not find out,
how cmake knows how to build the plugin.c file for each of the plugins.
Where is this defined?
--
---> Dirk Jagdmann
> http://cubic.org/~doj
-> http://llg.cubic.org
___
On 6/18/13 12:01 PM, Dirk Jagdmann wrote:
>> How many processor cores does your machine have, and are they
>> multi-threaded?
>>
>> I have a 4-dual-threaded-core machine (and a solid-state disk and a
>> lot of memory), and "-j 8" seems to run the CPU at about 100%. I
>> don't know whether "number
How many processor cores does your machine have, and are they multi-threaded?
I have a 4-dual-threaded-core machine (and a solid-state disk and a lot of memory), and "-j
8" seems to run the CPU at about 100%. I don't know whether "number of threads"
would be a good default in all cases - what
On Jun 18, 2013, at 9:39 AM, Dirk Jagdmann wrote:
>> Very nice indeed! The only thing that should be done outside the script
>> is setting -j 3: On some systems it is too much, on others it is too
>> little. It should be set in the command line, not the script.
>
> I could change it to somethin
> Very nice indeed! The only thing that should be done outside the script
> is setting -j 3: On some systems it is too much, on others it is too
> little. It should be set in the command line, not the script.
I could change it to something like:
if [ -z "$MAKE_BUILD_OPT" ] ; then
MAKE_BUILD_OPT
On Mon, Jun 17, 2013 at 06:15:06PM -0700, Evan Huus wrote:
> Lemon isn't our code, and is only used as an intermediate in the build
> process. It should probably be in the non-fatal (dirty) group in
> automake and cmake.
We have modified lemon in the past and will probably do that in the
future as
> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=49995
> Date: 2013/06/17 04:30 PM
>
> Log:
> From Dirk Jagdmann via bug 7525: macosx-setup.sh improvements.
Very nice indeed! The only thing that should be done outside the script
is setting -j 3: On some systems it is too much,
17 matches
Mail list logo
