gcc visibility support
Over in issue 2114 (https://svn.boost.org/trac/boost/ticket/2114), Jürgen has provided a patch to add gcc visiblity support to all separately compiled libraries. gcc visibility is a mechanism similar to dllexport on Windows, with the same benefits. I have tried to apply it, and rebuild program_options. The the size of release shared library went from 272K down to 224K. The number of relocations went from 972 to 872. Both changes seem to be good. It seems to be unlikely to get the authors of every compiled library to look at the patch, so it looks like an alternative approach is necessary. Does anybody have any objections to this approach? If not, I'll check this in somewhere before Jule 15 deadline, and will take care of checking regression results afterwards. - Volodya
Vladimir Prus wrote:
Over in issue 2114 (https://svn.boost.org/trac/boost/ticket/2114), Jürgen has provided a patch to add gcc visiblity support to all separately compiled libraries. gcc visibility is a mechanism similar to dllexport on Windows, with the same benefits.
I have tried to apply it, and rebuild program_options. The the size of release shared library went from 272K down to 224K. The number of relocations went from 972 to 872. Both changes seem to be good.
For the record, there was a discussion about visibility support and the patch: http://lists.boost.org/Archives/boost/2008/12/146068.php Last time I heard the patch broke program_options.
It seems to be unlikely to get the authors of every compiled library to look at the patch, so it looks like an alternative approach is necessary. Does anybody have any objections to this approach? If not, I'll check this in somewhere before Jule 15 deadline, and will take care of checking regression results afterwards.
Perhaps we could search for exception classes and mark them as exported right away? We could do this, e.g., by looking for throw_exception or throw expressions. A lot of work, I know, but it has to be done anyway. Maybe there are other procedures necessary to make sure it works. Boost.Exception comes to mind as a possible source of issues. It is related to both exceptions and dynamic_cast. I'm guessing, at least error_info should be exported, too.
Andrey Semashev wrote:
Vladimir Prus wrote:
Over in issue 2114 (https://svn.boost.org/trac/boost/ticket/2114), Jürgen has provided a patch to add gcc visiblity support to all separately compiled libraries. gcc visibility is a mechanism similar to dllexport on Windows, with the same benefits.
I have tried to apply it, and rebuild program_options. The the size of release shared library went from 272K down to 224K. The number of relocations went from 972 to 872. Both changes seem to be good.
For the record, there was a discussion about visibility support and the patch:
http://lists.boost.org/Archives/boost/2008/12/146068.php
Last time I heard the patch broke program_options.
It appears to work now, though. I suspect this is because every exception in boost/program_options/errors.hpp is already marked with BOOST_PROGRAM_OPTIONS_DECL.
It seems to be unlikely to get the authors of every compiled library to look at the patch, so it looks like an alternative approach is necessary. Does anybody have any objections to this approach? If not, I'll check this in somewhere before Jule 15 deadline, and will take care of checking regression results afterwards.
Perhaps we could search for exception classes and mark them as exported right away? We could do this, e.g., by looking for throw_exception or throw expressions. A lot of work, I know, but it has to be done anyway.
Hmm, isn't every exception class supposed to be marked with BOOST_XXX_DECL anyway?
Maybe there are other procedures necessary to make sure it works. Boost.Exception comes to mind as a possible source of issues. It is related to both exceptions and dynamic_cast. I'm guessing, at least error_info should be exported, too.
I am unsure why -- it is ever used where typeid matters? - Volodya
On Monday 08 June 2009 01:16:13 Vladimir Prus wrote:
Andrey Semashev wrote:
Last time I heard the patch broke program_options.
It appears to work now, though. I suspect this is because every exception in boost/program_options/errors.hpp is already marked with BOOST_PROGRAM_OPTIONS_DECL.
I guess, someone has already fixed it then. Splendid.
Perhaps we could search for exception classes and mark them as exported right away? We could do this, e.g., by looking for throw_exception or throw expressions. A lot of work, I know, but it has to be done anyway.
Hmm, isn't every exception class supposed to be marked with BOOST_XXX_DECL anyway?
No, if it's header-only. That's one of the problems with the patch: such exceptions should not be marked in any way for MSVC (and other compilers with the similar type_info support), but should always have default visibility for GCC on Linux.
Maybe there are other procedures necessary to make sure it works. Boost.Exception comes to mind as a possible source of issues. It is related to both exceptions and dynamic_cast. I'm guessing, at least error_info should be exported, too.
I am unsure why -- it is ever used where typeid matters?
Unless we're banning visibility=hidden, it may matter. IIRC, Boost.Exception uses type_info to acquire error_info at the catch site. If it isn't exported, the acquisition will fail, because type_infos will not match. Oh, and for the same reason boost::exception should be exported, too, as it can be used to catch exceptions or as a target type for dynamic_casts. However, I'm not that familiar with the library implementation to be absolutely sure. I hope that the library maintainer is reading this.
On Sun, Jun 7, 2009 at 6:17 PM, Vladimir Prus<ghost@cs.msu.su> wrote:
Over in issue 2114 (https://svn.boost.org/trac/boost/ticket/2114), Jürgen has provided a patch to add gcc visiblity support to all separately compiled libraries. gcc visibility is a mechanism similar to dllexport on Windows, with the same benefits.
I have tried to apply it, and rebuild program_options. The the size of release shared library went from 272K down to 224K. The number of relocations went from 972 to 872. Both changes seem to be good.
It seems to be unlikely to get the authors of every compiled library to look at the patch, so it looks like an alternative approach is necessary. Does anybody have any objections to this approach? If not, I'll check this in somewhere before Jule 15 deadline, and will take care of checking regression results afterwards.
- Volodya
Volodya, just for your information, some time ago I've also attached a boost-build patch to the 2114 ticket. It provides new composite feature - 'hide-symbols' with available values 'on', 'off', 'ms-compat', 'inlines-hidden'. So, one can simply build any library with hidden visibility using command: bjam /boost/libname hide-symbols=on. (It will work for gcc, darwin assuming that patch you are mentioning is applied). Comments and corrections on boost-build changes will be appreciated. Regards
Hi Alexander, On Tuesday 09 June 2009 09:40:30 Alexander Arhipenko wrote:
It provides new composite feature - 'hide-symbols' with available values 'on', 'off', 'ms-compat', 'inlines-hidden'.
Comments and corrections on boost-build changes will be appreciated.
Yes, I have seen your patch. I think we should focus on getting the config changes into trunk, let the tests cycle and then add support to bjam. That's one reason why I skipped this so far. The other one being I'm just to busy right now doing paid work... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
On Tue, Jun 9, 2009 at 11:17 AM, Juergen Hunold<juergen.hunold@ivembh.de> wrote:
Hi Alexander, Hi, Juergen,
[snip]
Yes, I have seen your patch. I think we should focus on getting the config changes into trunk, let the tests cycle and then add support to bjam. That's one reason why I skipped this so far. The other one being I'm just to busy right now doing paid work...
Yours,
Jürgen
Thanks for taking care on patch. I've also send 2 comments on #2114 ticket in separate thread (several minutes ago). You can find it useful. Regards
participants (5)
-
Alexander Arhipenko -
Andrey Semashev -
Juergen Hunold -
Vladimir Prus -
Vladimir Prus