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://sourceware.org/binutils/docs/ld/VERSION.html#VERSION> 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> 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] > *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> 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/edf195f1/attachment.html>
