Wireshark · Wireshark-dev: Re: [Wireshark-dev] Building 0.99.4 under MacOS X (fixes)

[Guy Harris <guy@xxxxxxxxxxxx>]

Andreas Fink wrote:

> Here is how I configure
>
> export PATH="/usr/X11R6/bin:/usr/bin:/bin:/usr/local/bin:/sbin:/usr/ 
> sbin:/usr/local/sbin"
> export LDFLAGS="-lz -L/usr/local/lib -Wl,-search_paths_first -Wl,- 
> single_module"

So why is the "-lz" necessary?  The configure script should add that for 
you.

> export CFLAGS="-arch ppc -arch i386 -g -Os -fno-omit-frame-pointer - 
> Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -I/usr/local/include/ 
> cairo"

I assume the -I/usr/local/include/cairo is for building GTK+, not for 
building Wireshark.

Are the -Os and -fno-omit-frame-pointer just preferences for your build, 
or are they necessary?

> export CPPFLAGS=""
> export CXXFLAGS="-arch ppc -arch i386 -g -Os fno-omit-frame-pointer - 
> fno-exceptions -fno-rtti -Wl,-syslibroot,/Developer/SDKs/ 
> MacOSX10.4u.sdk -I/usr/local/include/cairo"

Is that for the libraries being built along with Wireshark?  (There's 
currently no C++ code in Wireshark, unless I've missed something.)

> ./configure --mandir=/usr/share/man --with-ssl --enable-threads -- 
> enable-usr-local --with-lua --enable-adns --disable-dependency-tracking

Should the man pages be installed in /usr/share/man, or 
/usr/local/share/man?

> Problem #1: LDFLAGS make ./configure fail.
>
> I would need to add -Wl,-single_module to LDFLAGS (otherwise we get  
> errors speaking about multi module)

The page at

	http://developer.apple.com/releasenotes/DeveloperTools/RN-dyld/index.html

says

	The static linker ld(1) supports building dylibs as either 
-multi_module or -single_module. Conceptually, a multi-module dylib is 
like a group of smaller dylibs - one per source file. The extra 
meta-data in a multi-module dylib allowed (pre-10.4) dyld to delay 
binding and running initializers on the individual modules. In Mac OS X 
10.4 dyld ignores all multi-module meta-data and completely binds and 
runs all initializers the same as if it were built single-module. In 
general, building dylibs -single_module is preferred. The one case where 
multi-module is still useful is it allows internal functions of a dylib 
to be interposable. For instance, libSystem.dylib is built multi_module 
so that malloc() can be overridden and all uses of malloc in libSystem 
(e.g. strdup) would be redirected to use the overridden version.

so it appears that it's the right flag to use when building dylibs.

Unfortunately, it's *only* usable when building a dylib, which is why...

> I can not do this like above because ./configure not wanting to compile.

...that fails.  I'll look into whether there's a way to force it in 
libtool, as that's probably the right way to ensure that it's used when 
building only dylibs (although building plugins as bundles might have to 
leave it out).

> Problem #2: Missing LUA files
>
> The files wslua/dtd_gen.lua and wslua/console.lua seem to be missing  
> (Make looks for them)
> Copying them over from the previous install directory solves this.  
> Why are those missing?

Missing from SVN, or from the release tarball?  I assume it's the 
release tarball, as they're both in the epan/wslua directory; perhaps 
epan/wslua/Makefile.am has to put them in the right macro.

> Problem #3: IRDA plugin fails complaining about  
> _proto_reg_handoff_sir multiple defined.

	...

> fix: edit file packet-sir.c and rename the function  
> "proto_reg_handoff_sir to irda_proto_reg_handoff_sir

Or proto_reg_handoff_irsir(), to parallel proto_register_irsir().

> and the only  
> call to it in proto_register_irsir as well

I've checked in a change to do the aforementioned rename - and to get 
rid of the call in proto_register_irsir(), as handoff registration 
routines are supposed to be called after *all* registration routines are 
called.