Boost logo

Boost-Build :

Subject: Re: [Boost-build] [EXTERNAL] cflags not being inherited
From: Paulo Márcio Figueiredo Alves (pauloalves1986_at_[hidden])
Date: 2014-02-20 09:56:39

Thank you for the tips, /boost//headers is very useful and I was looking
forward to something like that.

The problem is my shared libraries are not used like:
exe foo : foo_shared : <threading>multi ;

I use them with dlopen and LoadLibrary, and it drivers me to another
chalenge, create the simplest
build working on Windows, Linux and MacOS. On Windows I am not able to
create a DLL with this:

*lib foo_shared : foo_static : <link>shared : :
<library>/boost//thread/<link>static ;*

because gives me that:

libfoo_static.lib(foo_static.obj) : error LNK2019: unresolved external
symbol "class boost::system::error_category const & __cdecl
boost::system::system_category(void)" (?system_category_at_system@boost@
@YAABVerror_category_at_12@XZ) referenced in function "public: __thiscall
boost::thread_exception::thread_exception(int,char const *)"
libfoo_static.lib(foo_static.obj) : error LNK2019: unresolved external
symbol "class boost::system::error_category const & __cdecl
boost::system::generic_category(void)" (?generic_category_at_system@boost@
@YAABVerror_category_at_12@XZ) referenced in function "void __cdecl
boost::system::`dynamic initializer for 'errno_ecat''(void)"
libfoo_static.lib(foo_static.obj) : error LNK2019: unresolved external
symbol "public: __thiscall boost::thread::thread(void)" (??0thread_at_boost
@@QAE_at_XZ) referenced in function "int __cdecl foo_static(void)"
libfoo_static.lib(foo_static.obj) : error LNK2019: unresolved external
symbol "public: void __thiscall boost::thread::detach(void)" (?detach_at_thread
@boost@@QAEXXZ) referenced in function "public: __thiscall
boost::thread::~thread(void)" (??1thread_at_boost@@QAE_at_XZ)
bin\msvc-12.0\debug\foo_shared.dll : fatal error LNK1120: 4 unresolved

so I have to use:

*lib foo_shared : foo_static : <link>shared
<library>/boost//thread/<link>static : :
<library>/boost//thread/<link>static ;*

or use *<target-os>windows:<library>/boost//thread/<link>static *and solve
Windows and Linux
in an ugly way. I just don't know the best approach, and I think
<cxxflags>-fPIC should be
inherited regardless anything else. With this flags not being inherited, I
have other problems
like using <cxxflags>-std=c++11 and Boost.Filesystem generates "undefined
reference" under Linux.

What you think? Is there any workaround, maybe force inheritance?

Thank you

On Wed, Feb 19, 2014 at 7:59 PM, Thomas Suckow <thomas.suckow_at_[hidden]>wrote:

> On 02/19/2014 11:33 AM, Paulo Márcio Figueiredo Alves wrote:
>> I have made a simple test to show the problem (attached file). If you do
>> not use Boost.Thread, the problem does not occur.
>> Adjust boost path (line 1) and call b2 -a, you'll see "recompile with
>> -fPIC". Choose one of the commented choices
>> for target foo_static and you will see that there is no way to make it
>> work, unless you call b2 -a cxxflags=-fPIC.
>> Is it a bug? Is there any workaround? Am I doing something wrong?
> It would appear that the override of <link>static is preventing
> boost-build from knowing it needs to use -fPIC.
> That said, it bugs me thinking that the boost libraries are being linked
> into more than one of your shared libraries.
> In your library, since random is header-only, I would use:
> : <use>/boost//headers <implicit-dependency>/boost//headers ;
> AFAIK, this is the most correct syntax. I've been trying to figure out the
> best syntax since modular-boost changes some things.
> This is the best I could come up with:
> lib foo_static : : <link>static <cxxflags>-fPIC
> <use>/boost//headers <implicit-dependency>/boost//headers ;
> lib foo_shared : foo_static : <link>shared : :
> <library>/boost//thread/<link>static ;
> exe foo : foo_shared : <threading>multi ;
> I am kind of disappointed in this solution :-/
> -
> Thomas
> _______________________________________________
> Unsubscribe & other changes:
> mailman/listinfo.cgi/boost-build

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at