questions regarding visibility and b2

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

questions regarding visibility and b2

Boost - Dev mailing list
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: questions regarding visibility and b2

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: questions regarding visibility and b2

Boost - Dev mailing list
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: questions regarding visibility and b2

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: questions regarding visibility and b2

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: questions regarding visibility and b2

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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/4df5b095eaa967f5e2687978bd3d9467b758f28e/include/boost/test/utils/trivial_singleton.hpp#L37

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost