support for gcc hidden visibility in shared libraries
Hello, Many (almost all?) linked boost libraries don't work as shared libraries when compiled with the -fvisibility=hidden switch on gcc version>=4. I am wondering whether there is interest in making them work under these circumstances, as it might not be too hard to do, and there seems to be some benefit to it. To my limited understanding, making a symbol visible in a shared library using, say, __attribute__ ((visibility("default"))) on gcc, is analogous to using __declspec(dllexport) on windows. Many boost libraries already use macros that apply __declspec(dllexport) on windows - so these macros could set to expand to __attribute__ ((visibility("default"))) on gcc. Even better, a boost-wide macro could be added to the config headers. More information on this can be found here: http://gcc.gnu.org/wiki/Visibility Just to note, I have very limited understanding of compiling/linking and I might not have a full grasp of everything involved here. Also, my only reason for thinking that -fvisibility=hidden should be supported is that for a long time now, I haven't been able to use boost shared libraries on my os x platform, and only now I realized that the reason for this is that I had stuck -fvisibility=hidden in my user-config.jam a long time ago to suppress some warnings. Nonetheless, it seems like there are benefits to supporting it that go beyond preventing people like me from accidentally shooting themselves in the foot. Kind regards, Stjepan
On Thu, Dec 4, 2008 at 10:39 PM, Stjepan Rajko <stjepan.rajko@gmail.com> wrote:
Hello,
Many (almost all?) linked boost libraries don't work as shared libraries when compiled with the -fvisibility=hidden switch on gcc version>=4. I am wondering whether there is interest in making them work under these circumstances, as it might not be too hard to do, and there seems to be some benefit to it.
To my limited understanding, making a symbol visible in a shared library using, say, __attribute__ ((visibility("default"))) on gcc, is analogous to using __declspec(dllexport) on windows. Many boost libraries already use macros that apply __declspec(dllexport) on windows - so these macros could set to expand to __attribute__ ((visibility("default"))) on gcc. Even better, a boost-wide macro could be added to the config headers.
More information on this can be found here: http://gcc.gnu.org/wiki/Visibility
Just to note, I have very limited understanding of compiling/linking and I might not have a full grasp of everything involved here. Also, my only reason for thinking that -fvisibility=hidden should be supported is that for a long time now, I haven't been able to use boost shared libraries on my os x platform, and only now I realized that the reason for this is that I had stuck -fvisibility=hidden in my user-config.jam a long time ago to suppress some warnings. Nonetheless, it seems like there are benefits to supporting it that go beyond preventing people like me from accidentally shooting themselves in the foot.
Kind regards,
Stjepan
Hi, Stjepan. There was thread on this topic some time ago, see: http://thread.gmane.org/gmane.comp.lib.boost.devel/177304 I had even booked trac ticket and attached a patch (that provide gcc visibility facilities ) to it, see: https://svn.boost.org/trac/boost/ticket/2114 I would really love to see such functionality in boost, but it was silence from the moment of ticket creation (~5 months ago) so I've became silent too ;). Regards P.S. Comments on patch will be really appreciated
On Fri, Dec 5, 2008 at 5:23 AM, Alexander Arhipenko <arhipjan@gmail.com> wrote:
On Thu, Dec 4, 2008 at 10:39 PM, Stjepan Rajko <stjepan.rajko@gmail.com> wrote:
Many (almost all?) linked boost libraries don't work as shared libraries when compiled with the -fvisibility=hidden switch on gcc version>=4. I am wondering whether there is interest in making them work under these circumstances, as it might not be too hard to do, and there seems to be some benefit to it.
[snip]
Hi, Stjepan.
There was thread on this topic some time ago, see: http://thread.gmane.org/gmane.comp.lib.boost.devel/177304
Ah, cool.
I had even booked trac ticket and attached a patch (that provide gcc visibility facilities ) to it, see: https://svn.boost.org/trac/boost/ticket/2114
The ticket has no owner - perhaps that is the problem? To quote David Abrahams from the thread above: On Fri, Jul 11, 2008 at 5:11 PM, David Abrahams <dave <at> boostpro.com> wrote:
patches tend to be more impactful when attached to Trac tickets: http://svn.boost.org ;-)
Perhaps Dave would like to take over the patch and make his statement tend to be more true? ;-)
I would really love to see such functionality in boost, but it was silence from the moment of ticket creation (~5 months ago) so I've became silent too ;).
Me too. That ticket would have saved me 5 months of being baffled as to why shared boost libraries don't work on one of my systems.
Regards
P.S. Comments on patch will be really appreciated
I think it's great, and I appreciate the extra bold step of actually changing the compilation of affected libraries to build with hidden visibility (had I made the patch, which I probably never would have gotten to, I would have stopped short of that because of being afraid of breaking something, but you probably know a lot more about all this than me). Three comments: * the darwin toolset is affected the same way as gcc * will the added -fvisibility=hidden cause a problem with gcc<4? * I would prefer the slightly more descriptive macro names discussed in the thread (I think BOOST_SYMBOL_EXPORT is my favorite) Best, Stjepan
On Fri, Dec 5, 2008 at 3:56 PM, Stjepan Rajko <stjepan.rajko@gmail.com> wrote:
[snip]
The ticket has no owner - perhaps that is the problem? To quote David Abrahams from the thread above:
On Fri, Jul 11, 2008 at 5:11 PM, David Abrahams <dave <at> boostpro.com> wrote:
patches tend to be more impactful when attached to Trac tickets: http://svn.boost.org ;-)
Perhaps Dave would like to take over the patch and make his statement tend to be more true? ;-)
I've assigned ticket to David Abrahams. 2 Dave: hope this won't make you angry J
[snip]
Three comments: * the darwin toolset is affected the same way as gcc
Is __GNUC__ macro defined when using darwin?
* will the added -fvisibility=hidden cause a problem with gcc<4?
Actually I didn't tested gcc of versions lower than 4. My expectation is that gcc will only eliminate warnings about unknown compiler flag. BTW, the better approach for passing '-fvisibility=hidden' will be creation of some kind of alias (or rule?) for this (in order not to duplicate code in jamfiles). I mean something like this: alias hide_symbols : : : : <toolset>gcc:<cxxflags>"-fvisibility=hidden" ; #... lib a : [ glob *.cpp ] : <link>shared:<dependency>hide_symbols ; We're actively using boost.build, but I couldn't say that I'm boost.build expert. Maybe boost.build guys could help on this.
* I would prefer the slightly more descriptive macro names discussed in the thread (I think BOOST_SYMBOL_EXPORT is my favorite)
Agree Regards
On Fri, Dec 5, 2008 at 8:57 AM, Alexander Arhipenko <arhipjan@gmail.com> wrote:
I've assigned ticket to David Abrahams. 2 Dave: hope this won't make you angry J
Other candidates might be John Maddock or Beman Dawes, as they are listed as authors of Boost.Config
[snip]
Three comments: * the darwin toolset is affected the same way as gcc
Is __GNUC__ macro defined when using darwin?
Yes, but it's <toolset>darwin rather than <toolset>gcc. I hope your changes go through. Best, Stjepan
On Fri, Dec 5, 2008 at 8:24 AM, Stjepan Rajko <stjepan.rajko@gmail.com> wrote:
On Fri, Dec 5, 2008 at 8:57 AM, Alexander Arhipenko <arhipjan@gmail.com> wrote:
I've assigned ticket to David Abrahams. 2 Dave: hope this won't make you angry J
Other candidates might be John Maddock or Beman Dawes, as they are listed as authors of Boost.Config
[snip]
Three comments: * the darwin toolset is affected the same way as gcc
Is __GNUC__ macro defined when using darwin?
Yes, but it's <toolset>darwin rather than <toolset>gcc.
I hope your changes go through.
Best,
Stjepan
On darwin platform, you'd experience fewer unpleasant surprises if you aimed for -fvisibility-ms-compat, instead of 'hidden'. - Mat
on Fri Dec 05 2008, "Alexander Arhipenko" <arhipjan-AT-gmail.com> wrote:
On Fri, Dec 5, 2008 at 3:56 PM, Stjepan Rajko <stjepan.rajko@gmail.com> wrote:
[snip]
The ticket has no owner - perhaps that is the problem? To quote David Abrahams from the thread above:
On Fri, Jul 11, 2008 at 5:11 PM, David Abrahams <dave <at> boostpro.com> wrote:
patches tend to be more impactful when attached to Trac tickets: http://svn.boost.org ;-)
Perhaps Dave would like to take over the patch and make his statement tend to be more true? ;-)
I've assigned ticket to David Abrahams. 2 Dave: hope this won't make you angry J
What is this thing you've assigned to me? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Feb 6, 2009 at 6:30 AM, David Abrahams <dave@boostpro.com> wrote: [snip]
I've assigned ticket to David Abrahams. 2 Dave: hope this won't make you angry J
What is this thing you've assigned to me?
Hi, Dave. I've assigned to you ticket #2114: https://svn.boost.org/trac/boost/ticket/2114. It contains patches against boost.build and boost that provide ability to build boost (using gcc, darwing toolsets) with hidden symbols visibility, i.e. only specially marked symbols (like BOOST_LIBNAME_DECL) are exported from shared libraries. Regards
Stjepan Rajko wrote:
Hello,
To my limited understanding, making a symbol visible in a shared library using, say, __attribute__ ((visibility("default"))) on gcc, is analogous to using __declspec(dllexport) on windows. Many boost libraries already use macros that apply __declspec(dllexport) on windows - so these macros could set to expand to __attribute__ ((visibility("default"))) on gcc. Even better, a boost-wide macro could be added to the config headers.
Visibility attribute has notable differences compared to dllexport. For example, all type_info's must be made externally visible in order to have dynamic_cast, exceptions and type_info comparison working (one of the most striking affected libraries is Boost.ProgramOptions, since it is built on top of Boost.Any, which uses type_info). Also, it affects ODR adherence across modules. E.g. with default visibility "hidden" an address of the same function or global variable may appear to be different in different modules. This is already the case on Windows, though, so I guess this change should not break anything, but still it should be taken into account. So it doesn't look like a trivial change in settings and macros to me. What's worst, making such a change can trigger problems that are hardly detected by unit tests. Perhaps, we should just mandate the visibility=hidden mode not supported for now. Maybe --fvisibility-ms-compat or --fvisibility-inlines-hidden would be a better choice to support?
Hi,
Visibility attribute has notable differences compared to dllexport. For example, all type_info's must be made externally visible in order to have dynamic_cast, exceptions and type_info comparison working (one of the most striking affected libraries is Boost.ProgramOptions, since it is built on top of Boost.Any, which uses type_info).
Also, it affects ODR adherence across modules. E.g. with default visibility "hidden" an address of the same function or global variable may appear to be different in different modules. This is already the case on Windows, though, so I guess this change should not break anything, but still it should be taken into account.
So it doesn't look like a trivial change in settings and macros to me. What's worst, making such a change can trigger problems that are hardly detected by unit tests. Perhaps, we should just mandate the visibility=hidden mode not supported for now. Maybe --fvisibility-ms-compat or --fvisibility-inlines-hidden would be a better choice to support?
I've run into problems with the latter where RTTI would break if all intermediate base classes with virtual destructors did not explicitly define one, e.g.: class EXPORT Base { public: ... virtual ~Base(); ... }; class EXPORT Intermediate : public Base { ... // No explicitly defined virtual destructor. }; class EXPORT Derived : public Intermediate { public: ... virtual ~Derived(); ... }; A dynamic_cast<> from Base to Derived would fail unless the ~Intermediate() destructor was explicitly defined, presumably out-of-line. The last time I experimented with gcc visibility support was a couple of years ago. Perhaps this subtle issue has been addressed or at least improved since then. HTH, -Ossama
On Fri, Dec 5, 2008 at 12:12 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
[snip problems with -fvisibility=hidden]
Thanks for the clarifications. (perhaps this is related to what Mat Marcus was hinting about?)
So it doesn't look like a trivial change in settings and macros to me. What's worst, making such a change can trigger problems that are hardly detected by unit tests. Perhaps, we should just mandate the visibility=hidden mode not supported for now. Maybe --fvisibility-ms-compat or --fvisibility-inlines-hidden would be a better choice to support?
Sounds good to me, like I said my understanding of this is limited. It looks like the list of possible changes, in the order of potential breakage danger are: 1. add BOOST_SYMBOL_EXPORT / IMPORT config macros [this breaks nothing] 2. modify existing boost libraries that use similar macros of their own to use the boost.config macros [if the functionality of the new macros is a superset of the old macros, shouldn't break anything] 3. modify the default boost build to use -fvisibility-ms-compat or --fvisibility-inlines-hidden [low risk?] 4. modify the default boost build to use -fvisibility-hidden [high risk?] The patch by Alexander Arhipenko does 1,2, and 4. Perhaps we can at least start with 1, or 1 and 2? Stjepan
Stjepan Rajko wrote:
So it doesn't look like a trivial change in settings and macros to me. What's worst, making such a change can trigger problems that are hardly detected by unit tests. Perhaps, we should just mandate the visibility=hidden mode not supported for now. Maybe --fvisibility-ms-compat or --fvisibility-inlines-hidden would be a better choice to support?
Sounds good to me, like I said my understanding of this is limited. It looks like the list of possible changes, in the order of potential breakage danger are:
1. add BOOST_SYMBOL_EXPORT / IMPORT config macros [this breaks nothing] 2. modify existing boost libraries that use similar macros of their own to use the boost.config macros [if the functionality of the new macros is a superset of the old macros, shouldn't break anything] 3. modify the default boost build to use -fvisibility-ms-compat or --fvisibility-inlines-hidden [low risk?] 4. modify the default boost build to use -fvisibility-hidden [high risk?]
The patch by Alexander Arhipenko does 1,2, and 4. Perhaps we can at least start with 1, or 1 and 2?
If we are targeting to support -fvisibility=hidden in the end, we should provide two sets of macros for symbol exporting. One will have the semantics near to dllexport on Windows and the second will only have the impact when -fvisibility=hidden is in action. This is needed, for example, for header-only exception classes. Such classes do not need dllexport on Windows, but they do need default visibility on Linux. Personally, I'd rather not support -fvisibility=hidden at all, since, IMO, this mode is too dangerous and doesn't give much compared to -fvisibility-ms-compat. I think, the patch from Alexander should be modified to use -fvisibility-ms-compat on GCC 4.3 and up and -fvisibility-inlines-hidden on GCC 4.1 to 4.3. It should not restrict visibility at all on GCC prior to 4.1. This way we will make use of this feature while being on the safe side.
On Sat, Dec 6, 2008 at 4:37 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
If we are targeting to support -fvisibility=hidden in the end, we should provide two sets of macros for symbol exporting. One will have the semantics near to dllexport on Windows and the second will only have the impact when -fvisibility=hidden is in action. This is needed, for example, for header-only exception classes. Such classes do not need dllexport on Windows, but they do need default visibility on Linux.
Personally, I'd rather not support -fvisibility=hidden at all, since, IMO, this mode is too dangerous and doesn't give much compared to -fvisibility-ms-compat. I think, the patch from Alexander should be modified to use -fvisibility-ms-compat on GCC 4.3 and up and -fvisibility-inlines-hidden on GCC 4.1 to 4.3. It should not restrict visibility at all on GCC prior to 4.1. This way we will make use of this feature while being on the safe side.
I guess there are three issues at hand: 1) which scenarios are supported by boost.config macros 2) which scenarios are supported by individual boost libraries 3) which scenario is used as the default build for boost libraries There is little harm in supporting both scenarios (hidden / ms-compat) as far as 1. goes. Alexander's patch already provides macros for the ms-compat case. As far as 2 goes, it would seem reasonable to make each library that can be built as shared at least support ms-compat, and more if the author wants to. The patch from Alexander should already make all affected libraries support ms-compat (the tests he reported failing with e.g., serialization, were tested with hidden, but might pass with ms-compat). As far as 3 goes, now that I understand the issue a little bit more, it does seem like visibility-hidden is *not* the correct choice. The two reasonable choices are: * make the default build use default visibility, because that is the default behavior for the platform. * make the default build use -fvisibility-ms-compat (or at least -fvisibility-inlines-hidden, as appropriate), to make behavior as consistent as possible between the different platforms Best, Stjepan
Stjepan Rajko wrote:
On Sat, Dec 6, 2008 at 4:37 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Personally, I'd rather not support -fvisibility=hidden at all, since, IMO, this mode is too dangerous and doesn't give much compared to -fvisibility-ms-compat. I think, the patch from Alexander should be modified to use -fvisibility-ms-compat on GCC 4.3 and up and -fvisibility-inlines-hidden on GCC 4.1 to 4.3. It should not restrict visibility at all on GCC prior to 4.1. This way we will make use of this feature while being on the safe side.
I guess there are three issues at hand: 1) which scenarios are supported by boost.config macros 2) which scenarios are supported by individual boost libraries 3) which scenario is used as the default build for boost libraries
There is little harm in supporting both scenarios (hidden / ms-compat) as far as 1. goes. Alexander's patch already provides macros for the ms-compat case. As far as 2 goes, it would seem reasonable to make each library that can be built as shared at least support ms-compat, and more if the author wants to. The patch from Alexander should already make all affected libraries support ms-compat (the tests he reported failing with e.g., serialization, were tested with hidden, but might pass with ms-compat).
Agreed.
As far as 3 goes, now that I understand the issue a little bit more, it does seem like visibility-hidden is *not* the correct choice. The two reasonable choices are:
* make the default build use default visibility, because that is the default behavior for the platform. * make the default build use -fvisibility-ms-compat (or at least -fvisibility-inlines-hidden, as appropriate), to make behavior as consistent as possible between the different platforms
We could support both by introducing a build switch to control visibility. AFAIK, the common practice for other build toolsets is to keep the default build settings as close to compiler defaults as possible, so the default visibility mode should be the default (argh.. too many defaults in this sentence!). The restricted visibility (be that ms-compat or inlines-hidden) could be enabled with the build switch.
Guys, while reading through your fruitful comments, I've became to the following conclusions: 1. We should preserve default behavior of each toolset when building boost, e.g., for gcc compilation should be performed with visibility=default 2. We should give the ability to users: a) simplify build of custom libraries by providing macros such as BOOST_SYMBOL_EXPORT etc b) build needed boost library with custom visibility (hidden, ms-compat etc). All this ideas are implemented in attached patches. The first patch is for boost-build. It provides new composite feature 'hide-symbols' with available options: on, off, ms-compat, inlines-hidden. So, if I would like to build filesystem with hidden visibility, I can do the followings: * In boost root directory type "bjam /boost/filesystem hide-symbols=on" * In my library's Jamfile: alias filesystem : /boost/filesystem : <hide-symbols>on ; 'hide-symbols' feature should work only for gcc and darwin toolsets. For the others it does nothing. Unfortunately I had no ability to test darwin. It worth mentioning that I'm not a boost.build expert, so this patch supposed to be rather *ugly* and should be carefully reviewed by some boost.build guy. The second patch affects all the boost configuration files with BOOST_XXX_DECL macroses: __declspec(dllexport)/(dllimort) are simply replaced with macroses BOOST_SYBMOL_EXPORT/IMPORT. As you may see, attached patches preserve default behavior of boost build procedure. Unit tests. I've performed unit testing for affected libraries (with gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42) ). All of them (except serialization) was built with hidden visibility. It was 2 failures in program_options (as Andrey predicted ;) ) in BOOST_CHECK_THROW: exception wasn't caught (variable_map_test_dll, unicode_test_dll). All the others run smoothly (unless I missed something). Exceptions. This worries me a lot, since all the exceptions that wasn't *properly exported* will never be caught. Saying *properly exported* I mean: they always have default visibility or have been exported from shared library and have at least one key function, i.e. "non-pure virtual function that is not inline at the point of class definition" To reproduce this issue, you can try to build attached sample project and run ./install/fee_client /some/invalid/path: boost::filesystem_error and boost::system_error won't be caught. (Note, dependent boost libraries should be build with default visibility). Regards P.S. Again, comments and questions will be really apreciated
On Thu, Dec 11, 2008 at 3:54 PM, Alexander Arhipenko <arhipjan@gmail.com> wrote:
Guys, while reading through your fruitful comments, I've became to the following conclusions:
1. We should preserve default behavior of each toolset when building boost, e.g., for gcc compilation should be performed with visibility=default 2. We should give the ability to users: a) simplify build of custom libraries by providing macros such as BOOST_SYMBOL_EXPORT etc b) build needed boost library with custom visibility (hidden, ms-compat etc).
All this ideas are implemented in attached patches.
The first patch is for boost-build. It provides new composite feature 'hide-symbols' with available options: on, off, ms-compat, inlines-hidden. So, if I would like to build filesystem with hidden visibility, I can do the followings: * In boost root directory type "bjam /boost/filesystem hide-symbols=on" * In my library's Jamfile: alias filesystem : /boost/filesystem : <hide-symbols>on ;
'hide-symbols' feature should work only for gcc and darwin toolsets. For the others it does nothing. Unfortunately I had no ability to test darwin.
It worth mentioning that I'm not a boost.build expert, so this patch supposed to be rather *ugly* and should be carefully reviewed by some boost.build guy.
The second patch affects all the boost configuration files with BOOST_XXX_DECL macroses: __declspec(dllexport)/(dllimort) are simply replaced with macroses BOOST_SYBMOL_EXPORT/IMPORT.
As you may see, attached patches preserve default behavior of boost build procedure.
Unit tests. I've performed unit testing for affected libraries (with gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42) ). All of them (except serialization) was built with hidden visibility. It was 2 failures in program_options (as Andrey predicted ;) ) in BOOST_CHECK_THROW: exception wasn't caught (variable_map_test_dll, unicode_test_dll). All the others run smoothly (unless I missed something).
Exceptions. This worries me a lot, since all the exceptions that wasn't *properly exported* will never be caught. Saying *properly exported* I mean: they always have default visibility or have been exported from shared library and have at least one key function, i.e. "non-pure virtual function that is not inline at the point of class definition"
To reproduce this issue, you can try to build attached sample project and run ./install/fee_client /some/invalid/path: boost::filesystem_error and boost::system_error won't be caught. (Note, dependent boost libraries should be build with default visibility).
Regards
P.S. Again, comments and questions will be really apreciated
Any feedback? Regards
Alexander Arhipenko wrote:
On Thu, Dec 11, 2008 at 3:54 PM, Alexander Arhipenko <arhipjan@gmail.com> wrote:
Guys, while reading through your fruitful comments, I've became to the following conclusions:
1. We should preserve default behavior of each toolset when building boost, e.g., for gcc compilation should be performed with visibility=default 2. We should give the ability to users: a) simplify build of custom libraries by providing macros such as BOOST_SYMBOL_EXPORT etc b) build needed boost library with custom visibility (hidden, ms-compat etc).
All this ideas are implemented in attached patches.
The first patch is for boost-build. It provides new composite feature 'hide-symbols' with available options: on, off, ms-compat, inlines-hidden. So, if I would like to build filesystem with hidden visibility, I can do the followings: * In boost root directory type "bjam /boost/filesystem hide-symbols=on" * In my library's Jamfile: alias filesystem : /boost/filesystem : <hide-symbols>on ;
'hide-symbols' feature should work only for gcc and darwin toolsets. For the others it does nothing. Unfortunately I had no ability to test darwin.
It worth mentioning that I'm not a boost.build expert, so this patch supposed to be rather *ugly* and should be carefully reviewed by some boost.build guy.
The second patch affects all the boost configuration files with BOOST_XXX_DECL macroses: __declspec(dllexport)/(dllimort) are simply replaced with macroses BOOST_SYBMOL_EXPORT/IMPORT.
As you may see, attached patches preserve default behavior of boost build procedure.
Unit tests. I've performed unit testing for affected libraries (with gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42) ). All of them (except serialization) was built with hidden visibility. It was 2 failures in program_options (as Andrey predicted ;) ) in BOOST_CHECK_THROW: exception wasn't caught (variable_map_test_dll, unicode_test_dll). All the others run smoothly (unless I missed something).
Exceptions. This worries me a lot, since all the exceptions that wasn't *properly exported* will never be caught. Saying *properly exported* I mean: they always have default visibility or have been exported from shared library and have at least one key function, i.e. "non-pure virtual function that is not inline at the point of class definition"
To reproduce this issue, you can try to build attached sample project and run ./install/fee_client /some/invalid/path: boost::filesystem_error and boost::system_error won't be caught. (Note, dependent boost libraries should be build with default visibility).
Regards
P.S. Again, comments and questions will be really apreciated
Any feedback?
I intended to take a closer look later, but it seems my time is running too fast. In general, I'd be inclined to have a somewhat more general switch, like restrict-visibility=on/off, with "off" being the default. The "on" would mean different things depending on the compiler. The point is that it (a) simplifies configuration and (b) allows to keep build settings consistent through different compiler and Boost versions. Another point is that I don't think we should add support for "hidden" visibility in the build configuration until we are sure it is supported by the code. The tests already highlighted problems and I am not sure there aren't other issues not covered by tests. Maybe a total code review is needed to state that we support this mode.
participants (6)
-
Alexander Arhipenko -
Andrey Semashev -
David Abrahams -
Mat Marcus -
Othman, Ossama -
Stjepan Rajko