Boost.Build check to see if cxxflags flag is supported?

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

Boost.Build check to see if cxxflags flag is supported?

Boost - Dev mailing list
I'm looking for an example for how I could check to see if "-fPIC" is
supported for the compiler as part of project requirements.

In some recent PRs that include building a static library which then gets
included in a shared library, code needs to be built with "-fPIC" on
supported platforms/toolsets.  There is some code in gcc.jam to do this if
the overall link mode is shared (note: this code is not in clang.jam!), but
in this case the overall link mode is static, and a Jamfile wraps the
result in a shared library, so the directives in gcc.jam are not applied.

So at the top level Jamfile, I want to add a project requirement that
basically says, "if the compiler supports <cxxflags>-fPIC then use it".

Thanks,

Jim

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

Re: Boost.Build check to see if cxxflags flag is supported?

Boost - Dev mailing list
AMDG

On 11/07/2018 09:09 AM, James E. King III via Boost wrote:

> I'm looking for an example for how I could check to see if "-fPIC" is
> supported for the compiler as part of project requirements.
>
> In some recent PRs that include building a static library which then gets
> included in a shared library, code needs to be built with "-fPIC" on
> supported platforms/toolsets.  There is some code in gcc.jam to do this if
> the overall link mode is shared (note: this code is not in clang.jam!), but
> in this case the overall link mode is static, and a Jamfile wraps the
> result in a shared library, so the directives in gcc.jam are not applied.
>
> So at the top level Jamfile, I want to add a project requirement that
> basically says, "if the compiler supports <cxxflags>-fPIC then use it".
>

import flags ;
project
 : requirements
   [ check-has-flag <cxxflags>-fPIC : <cxxflags>-fPIC ]
 ;

Note 1: The documentation for this is only in
`b2 --help flags.check-has-flag`.  It isn't
integrated into the html docs yet.

Note 2: This is pretty new, so if you run into
any problems, please let me know.

Note 3: It might be more reliable to separate
the object files out and set <link>shared on them:
 obj x.o : x.cpp : <link>shared ;
 ...
 lib l : x.o y.o ... ;
(This will only work if the library is one
that is specifically built for the test, not
if it's a generic Boost library.)

In Christ,
Steven Watanabe

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

Re: Boost.Build check to see if cxxflags flag is supported?

Boost - Dev mailing list
Steven Watanabe wrote:
...

> import flags ;
> project
>  : requirements
>    [ check-has-flag <cxxflags>-fPIC : <cxxflags>-fPIC ]
>  ;
>
> Note 1: The documentation for this is only in
> `b2 --help flags.check-has-flag`.  It isn't
> integrated into the html docs yet.
>
> Note 2: This is pretty new, so if you run into
> any problems, please let me know.
>
> Note 3: It might be more reliable to separate
> the object files out and set <link>shared on them:
>  obj x.o : x.cpp : <link>shared ;
>  ...
>  lib l : x.o y.o ... ;
> (This will only work if the library is one
> that is specifically built for the test, not
> if it's a generic Boost library.)

Note 4:

This should probably be a feature, like <position-independent>on, which
toolsets translate to -fPIC as appropriate.


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

Re: Boost.Build check to see if cxxflags flag is supported?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> Note 4:
>
> This should probably be a feature, like <position-independent>on, which
> toolsets translate to -fPIC as appropriate.

... which will fix the case where a shared library uses a static library,
but -fPIC is not applied to the static library.


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

Re: Boost.Build check to see if cxxflags flag is supported?

Boost - Dev mailing list
> > Note 4:
> >
> > This should probably be a feature, like <position-independent>on, which
> > toolsets translate to -fPIC as appropriate.
>
> ... which will fix the case where a shared library uses a static library,
> but -fPIC is not applied to the static library.

Lively discussion of this issue (among other things) at
https://github.com/boostorg/serialization/pull/131.


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

Re: Boost.Build check to see if cxxflags flag is supported?

Boost - Dev mailing list
On Thu, 8 Nov 2018 at 20:30, Peter Dimov via Boost <[hidden email]>
wrote:

> Lively discussion of this issue (among other things) at
> https://github.com/boostorg/serialization/pull/131.
>

It looks like this discussion is heading towards a common understanding of
the issue(s) involved [and at least partial resolution]. I would like to
request for someone involved in that discussion to write a tl;dr of that
discussion, as it seems to touch upon a number of issues that are poorly
understood [also by long-time cpp-war-heroes] in general. /r/cpp might also
be a good place for this and [comments] could shed more light on this.

degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*

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

Re: Boost.Build check to see if cxxflags flag is supported?

Boost - Dev mailing list

Am 09.11.18 um 06:50 schrieb degski via Boost:
> I would like to
> request for someone involved in that discussion to write a tl;dr of that
> discussion, as it seems to touch upon a number of issues that are poorly
> understood [also by long-time cpp-war-heroes] in general. /r/cpp might also
> be a good place for this and [comments] could shed more light on this.

As the original author of the PR(s) I'll do this. Note that everything
below is already explained in detail in the description of the PRs and
initial issue:

- https://github.com/boostorg/serialization/pull/111,
https://github.com/boostorg/serialization/pull/128,
https://github.com/boostorg/serialization/pull/129,
https://github.com/boostorg/serialization/pull/131 
https://github.com/boostorg/serialization/issues/105

There is also my question on SO:
https://stackoverflow.com/questions/50064617/order-of-destruction-for-static-function-members-in-shared-libraries

To summarize:

There are 2 issues:

1. Wrong destruction order in shared libraries
2. Bug in Boost.Serialization (`singleton::is_destroyed`)

on 1.: As per the C++ standard the destructors are called in reverse
order of how the constructors finished. This is even true for static
initialization (pre-main) and destruction (post-main) of global static
instances which we have here.
This means if type `Foo` accesses a type `Registry` in its constructor
it is guaranteed that `Registry` will be constructed before `Foo` and
destroyed after.
Boost.Serialization makes use of this fact and lets `Foo` register
itself in `Registry` in the ctor of `Foo` and unregister in the
destructor of `Foo`.
Now there is the case of shared libraries (see also
https://github.com/boostorg/serialization/pull/131#discussion_r231498983):
Assume 2 shared libraries build against static Boost, so each of them
has separate instances of `Registry`, which is also ok.
Now lib1 uses a type `Foo` which gets registered in lib1-`Registry` and
lib2 uses a type `Bar` which gets registered in lib2-`Registry`. During
unload/destruction `Foo` is destroyed first as before and
lib1-`Registry` afterwards. But because shared library behaviour is
implementation defined we now run into the following situation on Linux
(not on OSX or Windows): With the destruction of lib1-`Registry` the
runtime also destroys lib2-`Registry`, probably because they are of the
same type. One can only guess what happens behind the scenes, but maybe
a name-map is used or so.
The problem: Now lib2-`Registry` is destroyed before `Bar` and when that
accesses the `Registry` you get a use-after-free situation and a corruption.

This can be handled (and was pre Boost 1.65) by a flag `is_destroyed`
which gets set once the singleton destructor is called and checked in
the destructors accessing another singleton. (Basically:
`if(!Registry::is_destroyed()) Registry::unregister(this)`)

but here issue 2 (introduced in 1.65):
The singleton template can be used directly by **not** inheriting from
it. In this case an instance of `T` is returned directly:
https://github.com/boostorg/serialization/blob/boost-1.68.0/include/boost/serialization/singleton.hpp#L122
BUT: The `is_destroyed` flag is set in the destructor of the singleton
template:
https://github.com/boostorg/serialization/blob/boost-1.68.0/include/boost/serialization/singleton.hpp#L157
As `T` is not inherited from `singleton<T>` this destructor
`~singleton<T>` is never called (because it is never constructed either)
and hence the flag is never set. See
https://github.com/boostorg/serialization/pull/131#discussion_r232088304
This is different when `T` is inherited from `singleton<T>` in which
case the construction of `T` will lead to the construction of
`singleton<T>` and also destruction which is why **in this case**
`is_destroyed` works correctly.
Due to this the issue 1. does not get caught and leads to the crash.


The question on this thread was now on how to include the "crash test"
into BJam:
- We need to build 2 shared libraries
- Link them into static boost

As Boost is build statically BJam does not add `-fPIC` to its compile
flags but as it is linked into shared libraries later this fails as
addresses are fixed already. Although BJam has the information (link
boost library into a shared library) it does not "backpropagate" this
into the build of boost. See
https://github.com/boostorg/serialization/pull/131#discussion_r231964634,
https://github.com/boostorg/serialization/pull/131#issuecomment-437236135


Thanks to Peter Dimovs help we got Robert convinced to include my fix
into the develop branch of Boost.Serialization:
https://github.com/boostorg/serialization/commit/f297d80d6ef55ac66525320d0477c17806aa57cd.
I now hope the tests get included to so it doesn't break in the future.




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

smime.p7s (6K) Download Attachment