[Top][All Lists]

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

Re: Avoid exporting of internal symbols

From: Satz Klauer
Subject: Re: Avoid exporting of internal symbols
Date: Tue, 5 Mar 2013 18:53:37 +0100

That's what I'm doing now:

libtool --mode=compile g++ -Wall -fPIC -shared -Wno-unused
-Wno-unused-result -fvisibility=hidden
libtool --mode=link g++ -fvisibility=hidden -export-symbols-regex
'mylib_' -shared -rpath /usr/lib $(LFLAGS)

Beside of that all functions to be exported are declared as

__attribute__ ((visibility ("default")))

Now the resulting library is a bit shorter but I still can see many symbols...

On Mon, Mar 4, 2013 at 8:31 AM, David <address@hidden> wrote:
> I cant remember now the syntax, but maybe the gcc hidden visibility
> attribute is what you are looking for.
> El 04/03/2013 08:06, "Satz Klauer" <address@hidden> escribió:
>> I'm creating a shared library using libtool:
>> libtool --mode=compile g++ -Wall -fPIC -shared -Wno-unused
>> -Wno-unused-result $(CFLAGS) $(LFLAGS)
>> libtool --mode=link g++ -shared -export-symbols-regex mylib_ -rpath
>> /usr/lib $(LFLAGS)
>> (That's a snipped only, there of course is the part that causes
>> compilation of sources).
>> As far as I understood it, the statement "-export-symbols-regex
>> mylib_" should ensure only functions starting with "mylib_" should be
>> exported by the resulting library. But when I check the resulting
>> .so-file it contains all symbols and names that are used within the
>> sources. Independent if the symbols are private or internal-only, if
>> they are whole class-names or simple functions, I can see all of them
>> within the library. The same happens when I use "-export-symbols"
>> together with a symbol file instead, it seems like the symbol
>> definitions are ignored completely.
>> So my question: how can I avoid that? How can I strip the library
>> completely to have only these functions exported and visible that are
>> really allowed to be called by programs that make use of my library?
>> That's important for two reasons: I want to save binary code size and
>> (even more important) avoid users are calling functions/using objects
>> that are not intended for external usage.
>> Thanks!
>> _______________________________________________

reply via email to

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