I made a few changes to simplify code in the serialization library. This entailed eliminating support for borland compilers, workarounds for compilers which fail to support partial specialization of template function and some general clean up. In the course of this effort, I had occasion to simplify the code which supports Auto linking - and by extension visibility. Things seemed to go pretty well. Feeling frisky, I added the switch -fvisibility=hidden to the gcc compile of library. Now applications won't link for lack of certain symbols. Well, they link and run fin on my machine here at home- but fail in the test matrix. http://www.boost.org/development/tests/develop/developer/output/Debian-Sid-b... Funny thing is: doesn't seem to be a problem on my machine doesn't seem to occur with all exported symbols - only select ones - often but not always desctructors I can switch Jamfile back so it doesn't specify -fvisibility=hidden, but it seems that I'm really close to being able to generate a smaller, cleaner DLL which I would prefer to do. Any constructive suggestions would be appreciated. On a related note, it seems to me that http://www.boost.org/development/separate_compilation.html should be updated to explain BOOST_SYMBOL_EXPORT and BOOST_SYMBOL_IMPORT which are convenient for simplifying the auto-linking and visibility functionality. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/questions-regarding-GCC-visibility-tp4673... Sent from the Boost - Dev mailing list archive at Nabble.com.
On March 31, 2015 9:48:09 PM EDT, Robert Ramey
I made a few changes to simplify code in the serialization library. [snip] In the course of this effort, I had occasion to simplify the code which supports Auto linking - and by extension visibility. Things seemed to go pretty well. Feeling frisky, I added the switch -fvisibility=hidden to the gcc compile of library. Now applications won't link for lack of certain symbols. Well, they link and run fin on my machine here at home- but fail in the test matrix. [snip] Funny thing is: doesn't seem to be a problem on my machine doesn't seem to occur with all exported symbols - only select ones - often but not always desctructors [snip] Any constructive suggestions would be appreciated.
I haven't looked at the source, but I'll mention a few things that may be helpful. Default visibility can be set on an entire class or on individual member functions. Compiler generated special member functions will be hidden if the class is hidden. Types for which RTTI is needed should have default visibility, as should exception types. Does your local build succeed after cleaning all build artifacts? ___ Rob (Sent from my portable computation engine)
Rob Stewart wrote
Funny thing is: doesn't seem to be a problem on my machine doesn't seem to occur with all exported symbols - only select ones - often but not always desctructors [snip] Any constructive suggestions would be appreciated.
I haven't looked at the source, but I'll mention a few things that may be helpful. Default visibility can be set on an entire class or on individual member functions. Compiler generated special member functions will be hidden if the class is hidden. Types for which RTTI is needed should have default visibility, as should exception types.
Does your local build succeed after cleaning all build artifacts?
On my local system, I made the change to the Jamfile and rebuilt but nothing happened. I'm guessing that b2 doesn't consider the Jamfile itself as a dependency. So I then deleted all previous build files for the compiler in question - gcc 4.9. Then I rebuilt the library and ran all the tests. Everything looked good. Then I pushed the change to git hub and watched the development results - and they are starting to show failures. So that is how I got to where I am. I should note that the same attribute tags, macros, etc are used to export/import symbols for the windows system and this has been working well for many years. The only change in that was I that I used the more recent BOOST_SYMBOL_EXPORT/IMPORT macros to make things more readable. Since the windows tests seem to work well, I'm feel comfortable in concluding that this change hasn't had any ill effects. I'm guessing that are some subtle differences in the rules between the two platforms. The gcc documentation on the subject is suspiciously complicated compare to the windows explanation. I could restore the previous of the jamfile which comments out the visibility=hidden switch. But I feel that I'm pretty close to getting it right and I think that excluding extraneous stuff from the shared library objects make for a better product. So I'll spend a little more time on it before I give up. Thanks to all for the suggestions. Robert Ramey PS - one post mentioned the possibility of assigning a visibility attribute to a whole namespace. This looks interesting but I never saw it anywhere. It's also unclear whether or not it's portable -- View this message in context: http://boost.2283326.n4.nabble.com/questions-regarding-GCC-visibility-tp4673... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 1 Apr 2015 at 8:06, Robert Ramey wrote:
Everything looked good. Then I pushed the change to git hub and watched the development results - and they are starting to show failures. So that is how I got to where I am.
Force a purge in your Jamfile using the SHELL command. Push that. You need to purge on the test machines, not your own. One quick way of verifying this is to add Travis support. It's always a clean build no matter what.
I should note that the same attribute tags, macros, etc are used to export/import symbols for the windows system and this has been working well for many years. The only change in that was I that I used the more recent BOOST_SYMBOL_EXPORT/IMPORT macros to make things more readable. Since the windows tests seem to work well, I'm feel comfortable in concluding that this change hasn't had any ill effects.
I'm guessing that are some subtle differences in the rules between the two platforms. The gcc documentation on the subject is suspiciously complicated compare to the windows explanation.
The original page I wrote for the feature is at http://www.nedprod.com/programs/gccvisibility.html. It may have useful detail missing in other guides. There are subtle differences, mainly because declspec is part of the type whereas attributes are not. If you follow my guide in your conversion, it'll work. I think that's only how Boost implements visibility support because I vaguely remember Dave asking me for a favour to do the Boost support for him.
I could restore the previous of the jamfile which comments out the visibility=hidden switch. But I feel that I'm pretty close to getting it right and I think that excluding extraneous stuff from the shared library objects make for a better product. So I'll spend a little more time on it before I give up.
fvisibility-inlines-hidden is an alternative. It'll always work with no source changes needed. I can't remember if fvisibility >= fvisibility-inlines-hidden, I would have thought so.
PS - one post mentioned the possibility of assigning a visibility attribute to a whole namespace. This looks interesting but I never saw it anywhere. It's also unclear whether or not it's portable
It isn't. MSVC has nothing like it. There is also a #pragma visibility. I remember that being quite fun to implement, unlike the fvisibility which was a PITA. GCC source code for the C++ compiler is awful. The preprocessor's, on the other hand, was a lovely piece of coding. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
AMDG On 04/01/2015 01:05 PM, Niall Douglas wrote:
On 1 Apr 2015 at 8:06, Robert Ramey wrote:
Everything looked good. Then I pushed the change to git hub and watched the development results - and they are starting to show failures. So that is how I got to where I am.
Force a purge in your Jamfile using the SHELL command. Push that. You need to purge on the test machines, not your own.
This will do absolutely nothing. Testers use a clean build unless they explicitly specify --incremental, which is marked on the test summary pages. There's only one on develop.
One quick way of verifying this is to add Travis support. It's always a clean build no matter what.
In Christ, Steven Watanabe
On Tuesday 31 March 2015 18:48:09 Robert Ramey wrote:
I made a few changes to simplify code in the serialization library. This entailed eliminating support for borland compilers, workarounds for compilers which fail to support partial specialization of template function and some general clean up. In the course of this effort, I had occasion to simplify the code which supports Auto linking - and by extension visibility. Things seemed to go pretty well. Feeling frisky, I added the switch -fvisibility=hidden to the gcc compile of library. Now applications won't link for lack of certain symbols. Well, they link and run fin on my machine here at home- but fail in the test matrix.
http://www.boost.org/development/tests/develop/developer/output/Debian-Sid-b oost-bin-v2-libs-serialization-test-test_array_binary_archive-test-gcc-4-9-2 -debug-address-model-64-architecture-x86.html
Funny thing is: doesn't seem to be a problem on my machine doesn't seem to occur with all exported symbols - only select ones - often but not always desctructors
I can switch Jamfile back so it doesn't specify -fvisibility=hidden, but it seems that I'm really close to being able to generate a smaller, cleaner DLL which I would prefer to do.
Any constructive suggestions would be appreciated.
I suspect base classes may be restricting visibility of your classes. From the docs[1]: A class must not have greater visibility than its non-static data member types and bases, and class members default to the visibility of their class. For example, basic_oarchive is marked with BOOST_ARCHIVE_OR_WARCHIVE_DECL but noncopyable and helper_collection which it derives from are not, and as such have hidden visibility. [1] https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Attributes.html#Functi...
On 1 Apr 2015 at 11:56, Andrey Semashev wrote:
I suspect base classes may be restricting visibility of your classes. >From the docs[1]:
A class must not have greater visibility than its non-static data member types and bases, and class members default to the visibility of their class.
For example, basic_oarchive is marked with BOOST_ARCHIVE_OR_WARCHIVE_DECL but noncopyable and helper_collection which it derives from are not, and as such have hidden visibility.
[1] https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Attributes.html#Functi...
That GCC doc is poorly worded. Of course a class can have greater visibility than its base classes or its member variables. It's just such dependencies must be both defined and declared in full to the TU needing them. If you think it through, if this weren't the case then no STL container type would ever work because none of those are marked with default visibility. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 1 Apr 2015 at 16:15, Andrey Semashev wrote:
If you think it through, if this weren't the case then no STL container type would ever work because none of those are marked with default visibility.
libstdc++ marks the whole namespace std with default visibility.
Indeed it does. That came a LOT later, and is only realistically possible because of the extent to which libstdc++ goes to maintain ABI. Originally libstdc++ had no markup at all, as most template libraries still don't. It still works as I said. Moreover, base classes don't need declspec(dllexport) on Windows under the exact same conditions as on GCC. That was a very deliberate choice to have the two match semantics as closely as was possible. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 31 Mar 2015 at 18:48, Robert Ramey wrote:
I made a few changes to simplify code in the serialization library. This entailed eliminating support for borland compilers, workarounds for compilers which fail to support partial specialization of template function and some general clean up. In the course of this effort, I had occasion to simplify the code which supports Auto linking - and by extension visibility. Things seemed to go pretty well. Feeling frisky, I added the switch -fvisibility=hidden to the gcc compile of library. Now applications won't link for lack of certain symbols. Well, they link and run fin on my machine here at home- but fail in the test matrix.
Firstly purge all intermediate build files. Just a single hidden visibility in any linked objects taints visibility for all linked objects. Secondly, yours looks to be a base class visibility problem. Either make sure base classes are defined rather than declared in all TUs, or mark base classes with export visibility. Remember just one failure to correctly mark a symbol as default visibility in any linked object ruins the show. I assume you're using the usual trick of defining BOOST_SERIALIZATION_SOURCE when compiling the source code such that the right import/export is configured i.e. the opposite to a header include by third party libs? Note you must be careful in this, because incorrect mixing BOOST_SERIALIZATION_SOURCE compilands with any without BOOST_SERIALIZATION_SOURCE ruins the show. In other words, everything going into an ELF shared object must *always* have the same export visibility, and everything outside that ELF shared object must *always* have the opposite visibility setting. For some given ABI, of course. Again, blame ELF and the limited world view of those who provide its tooling for this mess. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
I've managed to track this down to the auto-archive/visibility macros. To do this I had to troll through a long chain of posts on the subject from 2010. I'm still resolving a few details. One that that would help in future cases would be if the documentation at http://www.boost.org/development/separate_compilation.html could be updated. Right now it uses the "old" macros and doesn't mention visibility at all. It needs to be refactored somewhat to describe both auto-linking and visibility in such a way that the concepts to get so confused that the read loses track. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/questions-regarding-GCC-visibility-tp4673... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (5)
-
Andrey Semashev -
Niall Douglas -
Rob Stewart -
Robert Ramey -
Steven Watanabe