C++ APIs are never used with shared libraries due to the name mangling issues. So the .def file only includes C APIs.
From: Othman, Ossama [mailto:[email protected]] Sent: Tuesday, April 4, 2017 11:06 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, Do you use the *.def files for the IoTivity C++ API, too? Wouldn't the mangled C++ names be a problem? In any case, if the GCC based symbol visibility isn't viable, we could also use the VERSION command in a linker script<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceware.org%2Fbinutils%2Fdocs%2Fld%2FVERSION.html%23VERSION&data=02%7C01%7Cdthaler%40microsoft.com%7Ca2190f7658ac45f02d1a08d47b8550ea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636269259892279606&sdata=U6anUZ3hZMO1f%2FGUgbx56VV4kO%2FKb83A2pr8GRvlh7M%3D&reserved=0> to mark symbols as exported ("global") or hidden ("local"). However, I don't have much experience with linker scripts so I don't know how well they scale or how maintainable they are. On the other hand, my experience with GCC symbol visibility on large C++ libraries that already used Windows style _declspec(dllexport) based macros was quite positive, especially since it allowed the compiler to generate better binaries in some cases than the linker script based approach. I'm certainly interested in understanding why _declspec(dllexport) doesn't scale well. Should we take that discussion to a separate thread? Thanks, -Ossama On Tue, Apr 4, 2017 at 10:32 AM, Daniel Mihai <Daniel.Mihai at microsoft.com<mailto:Daniel.Mihai at microsoft.com>> wrote: 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:ossama.othman at intel.com<mailto:[email protected]>] Sent: Tuesday, April 4, 2017 10:09 AM To: Daniel Mihai <Daniel.Mihai at microsoft.com<mailto:Daniel.Mihai at microsoft.com>> Cc: Wouter van der Beek (wovander) <wovander at cisco.com<mailto:wovander at cisco.com>>; uzchoi at samsung.com<mailto:uzchoi at samsung.com>; Mats Wichmann <mats at wichmann.us<mailto:mats at wichmann.us>>; Dave Thaler <dthaler at microsoft.com<mailto:dthaler at microsoft.com>>; C.J. Collier <cjcollier at linuxfoundation.org<mailto:cjcollier at linuxfoundation.org>>; iotivity-dev at lists.iotivity.org<mailto: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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fwiki%2FVisibility&data=02%7C01%7Cdthaler%40microsoft.com%7Ca2190f7658ac45f02d1a08d47b8550ea%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636269259892279606&sdata=%2FtS%2Bg%2FL0J4ljdPCOmqDVT8CnxRLL%2FlUEXVhtaqqPAbg%3D&reserved=0> 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/d553bc76/attachment.html>
