Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-09-01 02:27:13

On Friday 26 August 2005 19:15, Rene Rivera 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:
> >
> > <>
> 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.

Apparently, it's problem with all gcc version.

> > 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.

It's problem in all contexts. If you make build any library or executable with
-fvisibility=hidden, link to another library, need rtti for class defined in
that library, and headers of that library don't explicitly specify default
visibility for that class, your program/library won't work.
And even libstdc++ does not have proper declarations in its headers.

Mat gives an example where just using libstdc++ while building with
-fvisiblity=hidden results in crash.

The only 100% reliable solution appears to be to always put
-fvisibility=default in compiler options. Having feature
with default value of "default" is less reliable, but might be needed --
even if -fvisibility has the above defect, users will want to use it.

- Volodya

Vladimir Prus
Boost.Build V2:

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at