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

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-08-26 14:39:59

Mat Marcus wrote:
> 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.

OK, got it. Guess we are forced to fix it globally.

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

It's only available when "HAVE_POPEN" is defined when compiling bjam. 
Currently it's defined for all compilers and platforms except when 
building with the Metrowerks Standard Library, which doesn't have a 
popen call implemented. And of course you have to have a 3.1.11 or later 
version of bjam :-)

What problems did you have with it? Did it not work? Did it complain it 
wasn't around? Did the program it ran fail?

> Hmm. The SHELL technique seems best if I can learn how to make it work
> across platforms.

Yes. The most likely problems are going to be related to path handling, 
at least that's what it's been historically when invoking programs.

Feel free to ignore stuff below... I'm just commenting because it's a 
topic I happen to be very familiar with ;-)

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

Yep, a common problem and not always possible to prevent. For example 
when using different compilers together. I've always not assumed that 
RTTI is usable outside the code module (exe, shared, whatever) it's used 
in. There are some compilers, like CW, that try to make things 
compatible with other compiler, i.e. VC, but it's not usually worth the 
hassle. But sometimes one just has to make it work, like for GCC.

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

That's not the only reason. RTTI also happens to have external linkage 
with GCC on ELF platforms. Which means that if it's not around when 
loading it will fail because it can't find vtables and RTTI.

> Because it is difficult to identify and maintain a narrow
> "export list" of mangled type info names (_ZTS*),

That is something I've managed to do in the equivalent to the 
-fvisibility I had to implement before that option was around.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org