Re: [jamboost] Towards a patch for boost build under gcc 4.0, link=shared

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2005-08-26 11:52:28

On 8/26/05, Rene Rivera <grafik.list_at_[hidden]> wrote:
> Mat Marcus wrote:
> > I am working towards a patch for boost build (both versions) to allow
> > executables produced by boost-build to work when linked against shared
> > library versions of boost, under gcc 4.0. See for example:
> >
> > <http://article.gmane.org/gmane.comp.lib.boost.build/10072>
> 
> As far as I understand this is only a problem with the Apple version of
> GCC? I'm curious because the GCC documentation explicitly says that the
> default visibility is for all symbols to be public which is designed for
> backward compatibility, as in this case.

No, the problem is not mac only. See the bug report referred to in the
above article. Yes, the gcc documentation says that
-fvisibility=default is the default. And that does seem to be the case
for certain kinds of artifacts. But on at least to platforms it
appears that -fvisibility is not being set to default for exectuables.
That is the source of this bug.

> > Questions:
> > 1) What is the right way to make some flags dependent on compiler
> > version?
> 
> For BBv1, one way is to rely on the toolset name. Another is using the
> SHELL builtin as you did.

The SHELL builtin worked on one platform but not on another under
BBv2. Should it always be available?

> And yet another is to use the name of the GCC
> executable as it has the version number on some installations. And
> sometimes you can use the version of the OS as the compiler is available
> based on a release. v1/darwin-tools.jam uses a combination of those to
> account for the "-fcoalesce-templates" option.

Hmm. The SHELL technique seems best if I can learn how to make it work
across platforms.
 
> > 2) Does anyone dislike the idea of making <symbol-visibility> a feature?
> 
> Not really. But it's usually good to either consider if such a feature
> should be available for all toolsets (i.e. can it be implemented or
> faked for all compilers), or to limit it to one toolset and/or platform.
> 
> I think the important issue to figure out here is where this
> "-fvisibility=hidden" being the default is a problem and limit any fix
> to those contexts.

The problem is this: any artifact that doesn't expose the compiler
generated type info with default visibility will end up with separate
private copies of the type_info. When comparing types, to save time,
the RTTI mechanism doesn't actuallt compare strings--it compares
addresses of the type_info data structures. This is why RTTI fails
across shared library boundaries if the type info has hidden
visibility. Because it is difficult to identify and maintain a narrow
"export list" of mangled type info names (_ZTS*), this situation
translates in my mind into the unfortunate: "hidden visibility breaks
RTTI in gcc 4.0". Unfortunate because controlling exports is very
important to thise who try to maintain binary compatibility with a
shared library over time. Assuming my interpretation is correct, I
don't see how to limit the scope of the fix.

We may not need to go so far as to use -fvisibility=default.
-fvisibility-inlines-hidden is probably a better setting. It hides
only "outlined" inlines across shared library boundaries, often
yielding a minor size reduction.

- Mat