questions regarding visibility and b2
I've got a few questions about the "visibility" changes for boost. My understanding is that "visibility" for gcc and clang are "sort of the same thing" as dll import and export are for windows. Now we've made "visibility" the "default". But this seems kind of weird. This has been made a b2 feature. In order to run tests, this feature is applied to the b2 command line. What's weird is that it's applied to the tests/executables and propogated down to libraries which are built. I actually don't know what "visibility" means in the context of building and executable. If I want to use visibility=global then on the library build, it needs to be applied to everything. It's very weird and doesn't seem in line with the windows solution. Heretofore, I've applied visibility to the library build "by hand" by adding the appropriate command line switches to the right places. I'm aware that this is not the b2 way. But the b2 way doesn't seem to make sense to me. On the bright side, changing default visibility didn't seem to have any effect on the serialization library other than on one test. Unfortunately, turning this confused a pending issue and made it even more contentious than it already is/was. FWIW - this is not so much the fault of b2 or anyone in particular. The use of DLLS/shared libraries is the triumph of development over design by vendors, each of whom do their own thing and have never been able to get it together. By now this has created enough technical debt that it will take years to straighten out if people actually start to address it, which no one seems interest in doing. Anyway, the b2 approach is pretty confusing and probably wrong. I'm also guessing that, as one would predict, a change like this is going to provoke subtle failures in lots of small corners which will take quite a while to discover. I'm not sure how to address this. Robert Ramey
AMDG On 10/27/2018 11:29 AM, Robert Ramey via Boost wrote:
I've got a few questions about the "visibility" changes for boost.
My understanding is that "visibility" for gcc and clang are "sort of the same thing" as dll import and export are for windows.
Now we've made "visibility" the "default".
But this seems kind of weird. This has been made a b2 feature. In order to run tests, this feature is applied to the b2 command line. What's weird is that it's applied to the tests/executables and propogated down to libraries which are built. I actually don't know what "visibility" means in the context of building and executable.
It means the same thing that it means for a shared library. It's possible for a shared library to import symbols from the main executable. (This usually happens for dynamically loaded extensions.) visibility controls which symbols are exported.
If I want to use visibility=global then on the library build, it needs to be applied to everything. It's very weird and doesn't seem in line with the windows solution.
<local-visibility> only applies to a specific target. In a Jamfile, you should use this property instead of <visibility>. <visibility> is propagated and is the correct switch for use on the command line.
Heretofore, I've applied visibility to the library build "by hand" by adding the appropriate command line switches to the right places. <snip>
In Christ, Steven Watanabe
On 10/27/18 10:45 AM, Steven Watanabe via Boost wrote:
AMDG
On 10/27/2018 11:29 AM, Robert Ramey via Boost wrote:
I've got a few questions about the "visibility" changes for boost.
My understanding is that "visibility" for gcc and clang are "sort of the same thing" as dll import and export are for windows.
Now we've made "visibility" the "default".
But this seems kind of weird. This has been made a b2 feature. In order to run tests, this feature is applied to the b2 command line. What's weird is that it's applied to the tests/executables and propogated down to libraries which are built. I actually don't know what "visibility" means in the context of building and executable.
It means the same thing that it means for a shared library. It's possible for a shared library to import symbols from the main executable. (This usually happens for dynamically loaded extensions.) visibility controls which symbols are exported.
Hmmm - this is itself very weird. How do we know that something likes this actually works. Does is work with windows exe? I've never seen anything like this explained. Robert Ramey
Am 27.10.2018 um 21:19 schrieb Robert Ramey via Boost:
On 10/27/18 10:45 AM, Steven Watanabe via Boost wrote:
It's possible for a shared library to import symbols from the main executable... Visibility controls which symbols are exported.
Does is work with windows exe?
Yes Ciao Dani
On 10/27/18 12:19 PM, Robert Ramey via Boost wrote:
On 10/27/18 10:45 AM, Steven Watanabe via Boost wrote:
AMDG
On 10/27/2018 11:29 AM, Robert Ramey via Boost wrote:
I've got a few questions about the "visibility" changes for boost.
My understanding is that "visibility" for gcc and clang are "sort of the same thing" as dll import and export are for windows.
Now we've made "visibility" the "default".
But this seems kind of weird. This has been made a b2 feature. In order to run tests, this feature is applied to the b2 command line. What's weird is that it's applied to the tests/executables and propogated down to libraries which are built. I actually don't know what "visibility" means in the context of building and executable.
It means the same thing that it means for a shared library. It's possible for a shared library to import symbols from the main executable. (This usually happens for dynamically loaded extensions.) visibility controls which symbols are exported.
Hmmm - this is itself very weird. How do we know that something likes this actually works. Does is work with windows exe? I've never seen anything like this explained.
And would't it imply that any program compiled which gcc and uses a shared library is a huge security risk?
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 27.10.18 19:29, Robert Ramey via Boost wrote:
I've got a few questions about the "visibility" changes for boost.
My understanding is that "visibility" for gcc and clang are "sort of the same thing" as dll import and export are for windows.
I also thought the same, but there are differences. You may read more about this here: https://github.com/boostorg/boost/pull/190#issuecomment-423766391 In particular for boost.test, I ended up with 2 singletons (funny) as the implementation of the singleton was visible to the client code: https://github.com/boostorg/test/blob/4df5b095eaa967f5e2687978bd3d9467b758f2... This alone was enough to instanciate a singleton in the client code in addition to the one in the boost.test code. Hope this helps, Raffi
participants (4)
-
Daniela Engert -
Raffi Enficiaud -
Robert Ramey -
Steven Watanabe