Re: [Wireshark-dev] Simpifying exporting DLL symbols
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 :
> Hi Guy,
>
> 2013/2/27 Guy Harris :
>>
>> On Feb 26, 2013, at 2:08 PM, Bálint Réczey 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
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
Hi Guy,
2013/2/27 Guy Harris :
>
> On Feb 26, 2013, at 2:08 PM, Bálint Réczey 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
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
2013/2/27 Dirk Jagdmann : >> I have tested it using autotools and CMake, but I could not give it a try >> on >> Windows or OS X. If you have some time and access to those platform >> please test the patch. > > > I tested on OsX and it seems to work. I could compile Wireshark and run it. Thanks! > I think it's useful to have such a change if it works for all platform we > care about. However we should also add a section to the developer README to > explain the new macros. Sure, I planned updating the README while converting the rest of the libs. Cheers, Balint ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
Hi Gisle, 2013/2/27 Gisle Vanem : > "Bálint Réczey" wrote: > >> I have created the attached patch to control symbol visibility using >> C defines instead of .def and .sym files. It is expected to work on every >> platform and every build system we support, but I did not want to >> commit it without discussing the direction. > > > Nice, but why not use nicer indenting to make it more readable? I think more indentation would look better, but starting #define-s at the beginning of the lines also has some value. If you don't mind I will leave indentation as it is now, but if we define coding guidelines covering this I won't stick to this style. :-) > > And what about foreign programs that would like to use e.g. libwireshark > code as a static lib? ws_symbol_export.h should IMHO account for this. > Something like: > > #if (defined (_WIN32) || defined (__CYGWIN__)) & !defined(WS_STATIC_LIB) > #ifdef WS_BUILD_DLL >#ifdef __GNUC__ > #define WS_DLL_PUBLIC __attribute__ ((dllexport)) >#else > #define WS_DLL_PUBLIC __declspec(dllexport) // Note: actually gcc seems > to also support this syntax. >#endif > .. Good point, I have updated the patch. AFAIK only MSVC compilers could have problems with the original #defines thus I fixed only that case. > > There is some interest out there to use libwireshark outside *shark > programs: > > http://stackoverflow.com/questions/10308127/using-libwireshark-to-get-wireshark-functionality-programatically > > The old Packetyzer 5.0 also uses ethereal libs. See: > http://sourceforge.net/projects/packetyzer/ There is also netexpect (http://netexpect.org) which is packaged in Debian. I usually collaborate with its author, Eloy, when I update packaged libraries in Debian. The new patch also covers Jakub's very valid concern about old (or other) compilers not supporting -fvisibility=hidden. Cheers, Balint 0001-Export-libwsutil-symbols-using-WS_DLL_PUBLIC-define.patch Description: Binary data ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
"Bálint Réczey" wrote: I have created the attached patch to control symbol visibility using C defines instead of .def and .sym files. It is expected to work on every platform and every build system we support, but I did not want to commit it without discussing the direction. Nice, but why not use nicer indenting to make it more readable? And what about foreign programs that would like to use e.g. libwireshark code as a static lib? ws_symbol_export.h should IMHO account for this. Something like: #if (defined (_WIN32) || defined (__CYGWIN__)) & !defined(WS_STATIC_LIB) #ifdef WS_BUILD_DLL #ifdef __GNUC__ #define WS_DLL_PUBLIC __attribute__ ((dllexport)) #else #define WS_DLL_PUBLIC __declspec(dllexport) // Note: actually gcc seems to also support this syntax. #endif .. There is some interest out there to use libwireshark outside *shark programs: http://stackoverflow.com/questions/10308127/using-libwireshark-to-get-wireshark-functionality-programatically The old Packetyzer 5.0 also uses ethereal libs. See: http://sourceforge.net/projects/packetyzer/ --gv ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
I have tested it using autotools and CMake, but I could not give it a try on Windows or OS X. If you have some time and access to those platform please test the patch. I tested on OsX and it seems to work. I could compile Wireshark and run it. I think it's useful to have such a change if it works for all platform we care about. However we should also add a section to the developer README to explain the new macros. -- ---> Dirk Jagdmann > http://cubic.org/~doj -> http://llg.cubic.org ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
On Feb 26, 2013, at 2:08 PM, Bálint Réczey 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? 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 ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
2013/2/26 Bill Meier : > On 2/26/2013 5:11 PM, Bálint Réczey wrote: >> >> 2013/2/26 Pascal Quantin : >> ... >>> >>> >> >> Thank you! If no one opposes I'll commit the patch on Thursday and >> then start converting the remaining libs. >> > > It sounds like the change is significant. > > if so, I suggest we consider if we should wait until after 1.10 is released > to make the change. It is significant in a way, but I think it would be better to have it in 1.10. It is the last change needed for CMake build system to make it good enough to generate official Debian packages. I got several requests to ship the Qt GUI in Debian and with CMake I can generate both GTK and Qt GUIs nicely not to mention that CMake builds are faster. 1.10.0 would be a perfect candidate to release a fully operational CMake build system for Linux and after 1.10 we could make CMake work on every platform. There is very little downside and if things go bad, we can still revert the changes easily way before the release. Cheers, Balint > > Bill ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
2013/2/26 Jakub Zawadzki : > On Tue, Feb 26, 2013 at 08:46:28PM +0100, Bálint Réczey wrote: >> If you have concerns or comments, please share them. :-) > > Some (older) compilers don't support -fvisibility=hidden can you add test > if this option is accepted by compiler? Sure, I'll add that before committing. Cheers, Balint ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
On 2/26/2013 5:11 PM, Bálint Réczey wrote: 2013/2/26 Pascal Quantin : ... Thank you! If no one opposes I'll commit the patch on Thursday and then start converting the remaining libs. It sounds like the change is significant. if so, I suggest we consider if we should wait until after 1.10 is released to make the change. Bill ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
On Tue, Feb 26, 2013 at 08:46:28PM +0100, Bálint Réczey wrote: > If you have concerns or comments, please share them. :-) Some (older) compilers don't support -fvisibility=hidden can you add test if this option is accepted by compiler? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
2013/2/26 Pascal Quantin : ... > > Hi Balint, > I just tried your patch on my Win32 box (MSVC2010) and it seems to be > working fine: symbols exported by libwsutil.dll are the same before and > after the patch. > > Regards, > Pascal. Hi Pascal, Thank you! If no one opposes I'll commit the patch on Thursday and then start converting the remaining libs. Cheers, Balint ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
Hi Guy, 2013/2/26 Guy Harris : > > On Feb 26, 2013, at 11:46 AM, Bálint Réczey wrote: > >> I have created the attached patch to control symbol visibility using >> C defines instead of .def and .sym files. > > You might want to use comments on #else and #endif to make it a bit easier to > figure out what #else is the opposite of and what #endif terminates. I have updated the patch with the suggested comments. > >> It is expected to work on every platform and every build system we support, > > "Work" as in "not fail to compile", or "work" as in "keep symbols from being > exported outside the library if not marked as being exported by the library"? I would target compiling on every platform first, but in thecases I have tested only the intended symbols got exported. :-) I also had to add more symbols to the list, because tshark did not compile without them. > > At least some UN*X compilers might support GCC-style > __attribute__(visibility(...)) options, but I don't know whether all the ones > that would be used to compile Wireshark, on platforms where the linker can > hide symbols, do. I suggest hiding the symbols where we can hide them by improving the WS_DLL_PUBLIC defines (i.e. where we can do it without relying on libtool). 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. Cheers, Balint ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
2013/2/26 Bálint Réczey > Hi, > > I have created the attached patch to control symbol visibility using > C defines instead of .def and .sym files. It is expected to work on every > platform and every build system we support, but I did not want to > commit it without discussing the direction. > > I have tested it using autotools and CMake, but I could not give it a try > on > Windows or OS X. If you have some time and access to those platform > please test the patch. > > The rationale behind making this change is simplifying the method we > maintain > the set of exported symbols and it is also needed by the CMake build. > AFAIK we can't use the .def and .sym files in CMake. > > If we agree to go this way I'll convert libwireshark and libwiretap, too. > If you have concerns or comments, please share them. :-) > > Hi Balint, I just tried your patch on my Win32 box (MSVC2010) and it seems to be working fine: symbols exported by libwsutil.dll are the same before and after the patch. Regards, Pascal. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Simpifying exporting DLL symbols
On Feb 26, 2013, at 11:46 AM, Bálint Réczey wrote: > I have created the attached patch to control symbol visibility using > C defines instead of .def and .sym files. You might want to use comments on #else and #endif to make it a bit easier to figure out what #else is the opposite of and what #endif terminates. > It is expected to work on every platform and every build system we support, "Work" as in "not fail to compile", or "work" as in "keep symbols from being exported outside the library if not marked as being exported by the library"? At least some UN*X compilers might support GCC-style __attribute__(visibility(...)) options, but I don't know whether all the ones that would be used to compile Wireshark, on platforms where the linker can hide symbols, do. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Simpifying exporting DLL symbols
Hi, I have created the attached patch to control symbol visibility using C defines instead of .def and .sym files. It is expected to work on every platform and every build system we support, but I did not want to commit it without discussing the direction. I have tested it using autotools and CMake, but I could not give it a try on Windows or OS X. If you have some time and access to those platform please test the patch. The rationale behind making this change is simplifying the method we maintain the set of exported symbols and it is also needed by the CMake build. AFAIK we can't use the .def and .sym files in CMake. If we agree to go this way I'll convert libwireshark and libwiretap, too. If you have concerns or comments, please share them. :-) Cheers, Balint 0001-Export-libwsutil-symbols-using-WS_DLL_PUBLIC-define.patch Description: Binary data ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
