It sounds like the GCC symbols visibility could reduce the differences between IoTivity on Windows and non-Windows. That?s a good thing, because it should reduce the IoTivity Test and Maintenance burden for all of us.
However, the __declspec(dllexport) mechanism on Windows doesn?t scale well to non-trivial projects (let me know in case you are curious about the details). So, I don?t think we should not go back to __declspec for Windows any time soon. IoTivity on Windows was using __declspec until a few months ago, when I replaced that with *.def files. I don?t know if GCC?s __attribute__ has similar problems to Windows?s __declspec. Dan From: Othman, Ossama [mailto:[email protected]] Sent: Tuesday, April 4, 2017 10:09 AM To: Daniel Mihai <Daniel.Mihai at microsoft.com> Cc: Wouter van der Beek (wovander) <wovander at cisco.com>; uzchoi at samsung.com; Mats Wichmann <mats at wichmann.us>; Dave Thaler <dthaler at microsoft.com>; C.J. Collier <cjcollier at linuxfoundation.org>; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Don't make breaking changes Hi Dan, On Tue, Apr 4, 2017 at 9:52 AM, Daniel Mihai via iotivity-dev <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> wrote: 2. Different OS?s/platforms seem to have different requirements. For example: a. If I understand correctly, non-static C functions in a Linux shared library can be called by anyone outside the shared library. b. On Windows, we need to identify those functions that can be called by anyone outside the shared library, and explicitly add them to the exports list, one by one. Does this mean that all of the functions from (a) and (b) are Public and cannot get breaking changes? That?s typically the approach on Windows, but it is not clear to me if is the proper approach on Linux too. On platforms that use GCC, including Linux, we can leverage GCC's symbol visibility feature<https://gcc.gnu.org/wiki/Visibility> to prevent functions, classes, etc, from being exported in a manner that is similar to Windows. The GCC Visibility wiki provides an example of how one could declare and use the import and export macros one sees in Windows libraries in manner that supports both Windows and GCC based builds. Library binaries that correctly leverage GCC symbol visibility often gain improved performance as well as a smaller footprint. It would be useful for IoTivity to leverage GCC symbol visibility if it isn't already doing so. HTH, -Ossama -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170404/4f291260/attachment.html>
