Wireshark-dev: Re: [Wireshark-dev] Simpifying exporting DLL symbols
From: Bálint Réczey <balint@xxxxxxxxxxxxxxx>
Date: Sun, 3 Mar 2013 12:33:24 +0100
Hi All, I have committed the changes and all buildbots seem to be happy with them. >From now on exporting a symbol from the shared library needs only WS_DLL_PUBLIC to be prepended to the function declaration: WS_DLL_PUBLIC gint get_column_char_width(const gint format); Currently all symbols are exported in builds using cc and Solaris Studio. I tried to fix that using but did not succeed. If someone works with those tools please try to fix that properly. Cheers, Balint 2013/2/27 Bálint Réczey <balint@xxxxxxxxxxxxxxx>: > Hi Guy, > > 2013/2/27 Guy Harris <guy@xxxxxxxxxxxx>: >> >> On Feb 26, 2013, at 2:08 PM, Bálint Réczey <balint@xxxxxxxxxxxxxxx> wrote: >> >>> Exporting all symbols when using more exotic compilers should not be and issue, >>> because plugins used on such exotic systems are probably compiled with >>> GCC >= 4.0, LLVM >>> or Visual Studio too, and this ensures using exported APIs. >> >> Does it ensure that plugins use only exported APIs on, for example: >> >> HP-UX, if Wireshark itself is compiled with aCC (as would be the case if the user got Wireshark from the HP-UX Porting and Archive Centre); >> >> AIX, if Wireshark itself is compiled with XLC? > I think plugin writers should care about proper API usage. > We offer them a broad range of systems where only the supported API > symbols are exported > thus they can test their plugins if they care about API changes. > With the Solaris Studio related changes we will hide obsolete symbols > on every platform we run > buildbot on. > >> >> Sun Studio 8 through Sun^WOracle Solaris Studio 12 appear to support __hidden as a way of saying "not visible outside the library", __global as a way of saying "visible outside the library and references from within the library could bind to code in the application if the application defines it", and "-xldscope=hidden" to make __hidden the default, so that __global overrides it. That sounds as if it'd be what we'd want. It requires us to tweak compiler options when building libraries, but, well, any build-and-configuration tools that can't handle that are toys.... > I have just sent an updated patch which allows easy customization of > such compiler parameters. > I haven't added the one you mentioned because I don't build on > Solaris, but adding it should now be really straightforward for anyone > having access to {Sun|Oracle} Solaris Studio. > > Cheers, > Balint
- Prev by Date: Re: [Wireshark-dev] new dissector - dynamic value string table?
- Next by Date: Re: [Wireshark-dev] new dissector - dynamic value string table?
- Previous by thread: Re: [Wireshark-dev] new dissector - dynamic value string table?
- Next by thread: [Wireshark-dev] wtap_dump_file_seek() and _tell()
- Index(es):
- Get Wireshark
- Download
- Code of Conduct