Wireshark · Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 35145: /trunk/ /trunk/epan/: Makefile.am /trunk/: Makefi

[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

Balint Reczey wrote:
> On 12/09/2010 12:59 AM, Balint Reczey wrote:
> > On 12/08/2010 04:21 AM, Jeff Morriss wrote:
> > > On 12/07/2010 01:42 PM, Jeff Morriss wrote:
> > > > Balint Reczey wrote:
> > > > > On 12/07/2010 04:06 PM, Jeff Morriss wrote:
> > > > > > rbalint@xxxxxxxxxxxxx wrote:
> > > > > > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=35145 
> > > > > > >
> > > > > > >
> > > > > > > User: rbalint
> > > > > > > Date: 2010/12/07 05:38 AM
> > > > > > >
> > > > > > > Log:
> > > > > > > Make libtool export only symbols listed in *.def files
> > > > > > [...]
> > > > > > > Directory: /trunk/wsutil/
> > > > > > > Changes Path Action
> > > > > > > +6 -2 Makefile.am Modified
> > > > > > Hmmm, libwsutil holds the optional targets (e.g., inet_aton() for
> > > > > > systems that don't have it).
> > > > > >
> > > > > > At least on the MacOS 10.5 buildbots, nmedit complains if libtool 
> > > > > > asks
> > > > > > it to export a symbol that isn't present in the library. I'm not sure
> > > > > > of an easy way to fix that (hacking the .def or the .sym file 
> > > > > > depending
> > > > > > on which optional targets are being built doesn't sound fun). Any
> > > > > > ideas? Or should we export all symbols from libwsutil?
> > > > > I revert the change for /trunk/wsutil/ to make us able to build for
> > > > > all platforms.
> > > > >
> > > > > I will look into other possibilities of hiding some functions:
> > > > > http://www.gnu.org/software/hello/manual/gnulib/Exported-Symbols-of-Shared- 
> > > > >
> > > > >
> > > > > Libraries.html
> > > >
> > > > Oops, looks like I just beat you to it.
> > > >
> > > > As mentioned in the commit message, it may not be worth it for
> > > > libwsutil: on my system there are only 21 global symbols (including
> > > > things like _init, _end, etc.). Since this library's purpose is to
> > > > provide utility functions, I suppose we may be able to control what it
> > > > exports fairly easily (there hopefully won't be any cases of module A's
> > > > symbols being needed by module B where that symbol isn't also needed
> > > > outside of the library).
> > >
> > > There are also optional functions in libwireshark.  The Solaris buildbot
> > > doesn't have Lua installed so it's failing to link because it can't find
> > > wslua_plugin_list...  Ideas?  Maybe this behavior can only be enabled if
> > > the "right" versions of various tools are installed (which ones?)?
> > I committed a hack which will filter out wslua_plugin_list from the 
> > sym file to
> > keep the build successful.
> > I think this is not the right approach. I think the list of exported 
> > symbols
> > should not depend on configure parameters, because that way we could 
> > make two
> > libraries with the same so version but with different symbol lists.
> > In the wslua_plugin_list case we could export it and leave it as NULL.
> > I will send my patch after running a few tests.
> >
> > Cheers,
> > Balint
> Tests ran faster than expected.
> Will commit this tomorrow and revert my last commit if there are no 
> objections.
> The commit implementing filtering could be adapted to wsutil's several 
> optional symbols, if needed.

Looks like a good idea. :-)

One concern: what other optional symbols are out there?  Is there an 
easy way to systematically find them all (before users)?  Maybe have one 
of the (faster) buildbots do a compile --without-<everything> ?