gcc -fvisibility=hidden

gcc -fvisibility=hidden

[Elliot Leonard]

We tracked down a seg fault bug to the fact that the -fvisibility=hidden
options that we were compiling with did not seem to work. BlueIO
function calls were executing in their NGIO library counterparts,
which -fvisibility=hidden should have prevented.

Our programming model requires that each shared library operate inside
its own sandbox. The libraries are written in C++, and a given class,
eg. GPortRef, may be defined separately in both lib A and lib B.

Whenever code in lib A invokes the GPortRef class, it must only access
the version that is defined in lib A.
Whenever code in lib B invokes the GPortRef class, it must only access
the version that is defined in lib B.

The reason we demand this behaviour is that lib A and lib B evolve
independently, and may need to be modified independently. Over time
the implementations of GPortRef in each library may diverge, even if
they started out identical.
To accomplish this, we configure the compiler and linker with
-fvisibility=hidden and -fvisibility-inlines-hidden so that all
symbols inside a library are local to that library.
We decorate the public entry points to the library with
__attribute__ ((visibility("default"))) so that they are visible
outside the library. Note that public entry points to our libraries
employ only 'C' syntax so that they can be easily invoked from C
programs.

This is the way that shared libraries developed in Windows and the Mac
behave - only symbols explicitly exported are visible outside the
library. The libraries that we are having trouble with on Linux are
actually compiled and run successfully on both Mac and Windows.

However under Linux, when we invoke a member function of GPortRef in
lib A, we see printf's coming from the lib B version of GPortRef. Very
bad karma. We have seen this under Ubuntu when running gcc version 4.2.3.

We have a tentative workaround, but it involves embedding each
of our shared libraries in separate C++ namespaces, which requires
that lots of files be touched. Does anyone know how to solve this
without resorting to namespaces? Why doesn't -fvisibility=hidden work?
--Elliot Leonard

Re: gcc -fvisibility=hidden

[Ian Lance Taylor]

Elliot Leonard <elliotleonard97215@gmail.com> writes:

> However under Linux, when we invoke a member function of GPortRef in
> lib A, we see printf's coming from the lib B version of GPortRef. Very
> bad karma. We have seen this under Ubuntu when running gcc version 4.2.3.
>
> We have a tentative workaround, but it involves embedding each
> of our shared libraries in separate C++ namespaces, which requires
> that lots of files be touched. Does anyone know how to solve this
> without resorting to namespaces? Why doesn't -fvisibility=hidden work?

I don't know why it doesn't work.  I do know that several bugs in the
handling of visibility for things like C++ virtual tables and typeinfo
structures have been fixed since the gcc 4.2 release.  Also the version
of the GNU binutils is relevant.  But I don't know if that is the sort
of problem you are encountering.  You are going to have to give us more
information.  You can use readelf to determine whether you have any
relocations against non-hidden symbols.

Ian