Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 35145: /trunk/ /trunk/epan/: Makefil

From: Balint Reczey <balint.reczey@xxxxxxxxxxxx>
Date: Thu, 9 Dec 2010 00:59:07 +0100
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