|
From: | Markus Mützel |
Subject: | [Octave-patch-tracker] [patch #8919] Start of patch to enable visibility attributes for GCC in build system |
Date: | Tue, 22 Dec 2020 06:03:26 -0500 (EST) |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36 Edg/87.0.664.66 |
Follow-up Comment #6, patch #8919 (project octave): What would be the advantage of having separate API macros for each library? Would it only be to be able to selectively use "manual" visibility in some libraries but "automatic" visibility (i.e., export everything) in others? I'm not sure there is a use case that justifies the additional complexity that would have to be added for that. I also agree that all functions that are defined in public headers should also be exported. Which functions these should be is probably a good question for a different task. If the code can be simplified by applying the visibility attributes to a namespace, that could be an option as well. But IIUC, all of this visibility handling is compiler specific. Are there compilers that don't support visibility attributes on namespaces? GCC seems to support this since version 4.2 [1]. What about clang or other compiler we'd like to support? I'll try and compile MXE Octave with jwe's changes. That might tell us which exports are still missing - at least for the Octave Forge packages we build in MXE Octave. [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764 _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/patch/?8919> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
[Prev in Thread] | Current Thread | [Next in Thread] |