|
From: | Rik |
Subject: | Re: visibility attributes |
Date: | Fri, 26 Feb 2016 09:36:44 -0800 |
On 02/25/2016 01:30 PM, John W. Eaton
wrote:
On 02/24/2016 12:24 PM, Rik wrote: Yes, making things static where they can be is the obvious first choice.
Yes, I think that is the savings we are looking at. We have many classes which contain a subclass that is the actual implementation, i.e., maintains a reference count, etc. I assume that even if the subclass is protected the I/F will be exported. At any rate, I'm sure I don't have enough time to solve this, but I started down that path. I posted a minimal patch to the patch tracker at https://savannah.gnu.org/patch/?8919. The description is: By using visibility attributes a programmer can control which functions are exported into the symbol table of a shared object. By reducing the number of symbols the linker can run faster and the generated shared object is smaller. For an explanation of the benefits and the approach see: https://gcc.gnu.org/wiki/Visibility. Octave already has support mostly in place for this. Steps: 1) make maintainer-clean 2) Apply visibility.patch from this issue report 3) change CFLAGS and CXXFLAGS to include "-fvisibility=hidden" 4) bootstrap 5) configure 6) make The build currently fails because liboctinterp is looking for symbols that have not been exported from liboctave. This requires finding the necessary functions and decorating them with OCTAVE_API so they are exported into the symbol table of liboctave. This is where things stand today (2/26/2016). --Rik |
[Prev in Thread] | Current Thread | [Next in Thread] |