octave-patch-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-patch-tracker] [patch #8919] Start of patch to enable visibility


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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]