Comments (13)
If you are wanting to hide all internal usage of Boost, and you are:
- Building a single shared library, and not a static library.
- Using Boost as a static library, not as shared libraries.
- Not using Boost types in your own library's interface (at all; not even in "private" parts of public header files). (This may also require you to use explicit visibility for your own library's symbols too.)
- Catching all Boost exceptions at your interface boundary and converting them to some other (visible) exception type.
Then it is probably safe (and correct) to disable Boost symbol visibility across the board. Violating any one of those four constraints would break things, however.
from config.
Use linker scripts.
from config.
See #441 for a patch
from config.
Confirmed, but this is an issue with throw_exception and should be reported here: https://github.com/boostorg/throw_exception. That header should be using BOOST_SYMBOL_VISIBLE rather than the push/pop's. I would guess that their workaround pre-dates the introduction of BOOST_SYMBOL_VISIBLE.
from config.
I've reported it there and proposed a small patch to replace the push/pops with BOOST_SYMBOL_VISIBLE.
However, that only seems to be half the solution, since BOOST_SYMBOL_VISIBLE is always set to attribute((visibility("default"))) in config/compiler/gcc.hpp if GNUC >= 4, regardless of whether the boost build system is building a shared library or not.
In the end I need the ability to build my boost-using shared library with -fvisibility=hidden and -fvisibility=hidden-inlines, without individual symbols from Boost forcing themselves out of my interface.
I guess somehow or other, that implies adding an extra condition before setting BOOST_SYMBOL_VISIBLE to whatever the compiler needs.
A possibility could be a BOOST_INTERFACE_VISIBLE macro that either Boost itself can set when Boost is building a shared library, or that the user can set if she uses boost classes as part of the interface of her own shared library. What do you think?
from config.
Ah my bad, we have an issue here, because there are 2 conflicting use cases:
- Using boost - we want exceptions to be visible types, otherwise we can't catch them.
- Hiding boost as an internal dependency - where we want all boost symbols to be hidden.
I'm not sure that we've ever really supported the second case - except as a sort of accident by having code that's not marked up.
I'll raise this on the mailing list, it's probably better to try and fix boost-wide (if we can) rather than each library doing it's own thing.
from config.
Any feedback on this?
from config.
I have an idea, but I'm working on another bug report right now.... nag me if I'm not back to you shortly...
from config.
My suggestion was going to be a macro - say BOOST_DISABLE_VISIBLE_SYMBOLS - which when set by the user would result in the BOOST_SYMBOL_* macros being set to nothing. That would then allow you to hide everything. I have a suspicion that some things (exception classes and some of the serialization lib) will not then work correctly, but I'm not sure?
from config.
I don't think this is a good idea. This may break exceptions and RTTI support. Boost.Log relies on this, for example. Other libraries, probably, too (Boost.Any comes to mind).
One example where making all symbols hidden may make sense is when a user builds a monolithic executable that does not use any other shared libraries, or uses them without passing any Boost-related types, including exceptions. Those cases can be covered by linker scripts, there's no need to change Boost for that.
The particular issue with Boost.ASIO though should be reported to upstream ASIO. I see no reason why it should mark all of its symbols visible (see here and here). But it may need to mark so exceptions, selectively. This is not a Boost.Config issue and changing Boost.Config will not fix Boost.ASIO and it will break other libraries.
from config.
I meet all four criteria above. Question is how to force all the symbols private?
from config.
I came accross exactly the same problem, where our dynamic library is one of huge amount of custom libraries in multi plug-in environment. Disabling ASIO symbols with macro switch partially helped, as all symbols in header like boost system still use BOOST_SYMBOL_VISIBLE and this caused to crash in my case by throwing an exception from asio. I guess this case is quite uncommon, as in my example there are 100 dynamic libs which work in independent way, and are not interacting with each other at all. That being said I think it would be very helpfull if there would be any way to simply diable BOOST_SYMBOL_VISIBLE by overriding it to nothing during compilation.
from config.
Use linker scripts.
that only works on platforms which supports those. What's wrong with just adding a BOOST_HIDE_ALL_SYMBOLS
macro which would define BOOST_SYMBOL_EXPORT
and BOOST_SYMBOL_VISIBLE
to the relevant platform attribute for that ?
in addition, doing this at the linker stage prevents compiler optimizations that could be done based on symbol visibility.
from config.
Related Issues (20)
- Macro misspellings in libcpp.hpp
- Missing BOOST_NO_CXX11_HDR_SCOPED_ALLOCATOR
- Autolink not working in VS2022 vs 17.0.6 HOT 2
- No BOOST_NO_CXX11_ALIGNOF HOT 4
- NVIDIA C++ compiler -cuda option triggers incompatible redefiniton of BOOST_COMPILER
- Support for IAR compiler HOT 1
- "Unknown compiler version" for Visual Studio 16 2019 HOT 2
- BOOST_HAS_INT128 not defined on clang-cl HOT 4
- Delete merged/stale branches HOT 1
- Configuration doesn't work correctly with clang on Linux HOT 5
- [MSVC][std:c++latest] Boost\libs\config run tests failed due to error C2666: 'boost_no_cxx11_unified_initialization_syntax::IdString::operator ==': overloaded functions have similar conversions HOT 3
- Missing define BOOST_NO_CXX11_NULLPTR on OSX with libstdc++ HOT 2
- New error for CLR projects which have no SFINAE HOT 2
- CMake - "lib" prefix bug in implibs of MSVC HOT 3
- BOOST_HAS_BUILTIN/BOOST_HAS_INCLUDE
- missing version macros
- missing header macros for C++23
- Outdated defect macros for Haiku HOT 1
- VS 2022 v17.10
- Missing features of C++/CLI seems to be flagged erroneously HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from config.