GNOME v. KDE, December 2005 edition

GNOME v. KDE, December 2005 edition

Posted Dec 18, 2005 2:25 UTC (Sun) by pynm0001 (subscriber, #18379)
In reply to: GNOME v. KDE, December 2005 edition by dhess
Parent article: GNOME v. KDE, December 2005 edition

> Are you talking about gcc 4.0's support for symbol exports?

That's a part of it. The feature is called visibility. I regret to say
that it is still only 90% baked, as it's hard to use visibility correctly
in certain times when using C++ libraries that don't support it. For
example, using it with Qt 3 brings issues of its own for KDE 3.5. And
the STL implementation in gcc 4.0.x is buggy when using the pooled
allocator and visibility.

However, for the most part it is a great advancement, and when code is
updated to use it properly can substantially reduce the symbol count of a
C++ program or library, which greatly reduces linking time.

Another benefit of visibility is that it seems to make more optimizations
potentially possible. I forget the exact explanation though.

You can read about visibility here:
http://www.nedprod.com/programs/gccvisibility.html

> In the case of my employer's large C++ app, gcc 4.0's symbol exporting
> doesn't help us much because we throw exceptions, and as far as I can
> tell, that means we need to export any symbols across which exceptions
> can be thrown

AFAICT that isn't the case. You do need to export with default
visibility the definition of the class which you are throwing. I'd need
to ask around before saying that what you describe is definitely untrue
but I've never heard anything like that.

One other thing I want to describe is the prelink tool, which as it may
imply, will perform much of the work of the dynamic linker, and cache the
result, which will result in much less work loading the binary later.
It's useful all-around, but especially useful for C++ binaries.

This is what I was talking about with Windows, where for some reason
their C++ ABI seems to not suffer as much loading times as the ELF/Linux
ABI. But then again, I've heard of some useful C++ constructs which we
actually use in KDE that break with the Win32 mechanism.

Regards,
- Michael Pyne

---

(Log in to post comments)