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

Wireshark-bugs: [Wireshark-bugs] [Bug 3722] New: Many symbols missing from libwireshark.def - An

Date: Mon, 13 Jul 2009 12:48:36 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3722

           Summary: Many symbols missing from libwireshark.def - An easier
                    way?
           Product: Wireshark
           Version: 1.2.0
          Platform: x86-64
        OS/Version: Windows Vista
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: dameiss@xxxxxxxxxx


Build Information:
Version 1.2.0 (SVN Rev 28753)

Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.14.7, with GLib 2.18.4, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, without libpcre, without SMI,
without c-ares, without ADNS, with Lua 5.1, without GnuTLS, without Gcrypt,
without Kerberos, without GeoIP, with PortAudio V19-devel (built Jun 15 2009),
without AirPcap.
NOTE: this build doesn't support the "matches" operator for Wireshark filter
syntax.

Running on Windows Vista, build 6000, with WinPcap version 4.1 beta5
(packet.dll
version 4.1.0.1452), based on libpcap version 1.0.0.

Built using Microsoft Visual C++ 9.0 build 30729

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
When building a plugin dissector, the symbol prefs_register_protocol_subtree
could not be found when loading the plugin DLL (on Windows, obviously). This is
because prefs_register_protocol_subtree is not listed in libwireshark.def,
which defines the libwireshark.dll symbols which are exported from the DLL.

This problem doesn't occur on Linux or Mac OSX (or most Unix-type OSs) which
use shared libraries, in which all symbols which are not file-static are
available in the shared library.

Rather than manually maintaining libwireshark.def (and missing some symbols), a
common approach is to declare symbols which should be exported from the DLL as
__declspec(dllexport) when building the library, and __declspec(dllimport) when
building against the library. This works for both function and data symbols.

The definition:
#ifdef _WIN32
  #ifdef WIRESHARK_EXPORT_SYMBOLS
    #define WSExpDLL __declspec(dllexport)
  #else
    #define WSExpDLL __declspec(dllimport)
  #endif
#else
  #define WSExpDLL
#endif

can be placed in an include file which is included by every module (not sure
offhand which would be good candidates). Function prototypes would be modified:
for example, 

extern module_t *prefs_register_protocol_subtree(const char *subtree, int id,
                                                 void (*apply_cb)(void));

would become

WSExpDLL extern module_t *prefs_register_protocol_subtree(const char *subtree,
int id,
                                                 void (*apply_cb)(void));

(not sure if __declspec() and extern are legal together - our software doesn't
use extern, as I believe that is the default).

When building libwireshark, pass -DWIRESHARK_EXPORT_SYMBOLS to the compiler.
When building *against* libwireshark (plugins, utilities, etc.), don't pass the
extra flag to the compiler.

Unless there is a reason I'm not aware of (which is entirely possible) why a
.def file is preferred....


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.