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> ?